Project structure: Unterschied zwischen den Versionen

Aus Open Source Ecology - Germany
Zur Navigation springen Zur Suche springen
(Die Seite wurde neu angelegt: „A project may be structured as followed: ==Repository== * Version control of development files. * Distributed development. * Automatic backups (due to exis…“)
 
(→‎Wiki: Remove redundant entry.)
 
(11 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
−
A project may be structured as followed:
+
A project may be structured as follows:
 
   
 
   
  
Zeile 6: Zeile 6:
 
* Version control of development files.
 
* Version control of development files.
 
* Distributed development.
 
* Distributed development.
−
* Automatic backups (due to existing on several systems of distributed developers / users.
+
* Automatic backups (due to existing on several systems of distributed developers / users).
 
* Integration with a versatile [[0install | release and dependency tool]].
 
* Integration with a versatile [[0install | release and dependency tool]].
−
 
  
 
==Wiki==
 
==Wiki==
  
−
* As functionality modules collection/guide.
 
 
* Documentation
 
* Documentation
−
* Guidance, e.g. as a very short outline of useful functionality modules:
+
 
−
Because each module has its own repository and thus if it was then such a collection had to be located in the base repository. The wiki is a better place because such a collection is  
+
* Guidance, e.g. a very short outline of useful functionality modules. The wiki is a better place than base repositories because such a collection is  
 
** subjective,
 
** subjective,
 
** context dependent, e.g. eco focus versus gigantism focus, and
 
** context dependent, e.g. eco focus versus gigantism focus, and
Zeile 21: Zeile 19:
 
** hard coded
 
** hard coded
 
** or a movement may want to link to a certain eco-flavored fork of a base module giving the reader guidance in what repository / release to install.
 
** or a movement may want to link to a certain eco-flavored fork of a base module giving the reader guidance in what repository / release to install.
−
** Tagging: Somehow a connection must be created between Wiki and repositories. And such eco modules listings are one possiblity for achieving that.
+
** Somehow a connection must be created between Wiki and repositories. And such eco modules listings are one possiblity for achieving that.
−
 
 
−
So now the projects can be tagged properly using the Wiki categories.
 
  
 +
* Tagging: The projects' documentation/guidance is tagged using Wiki categories in accordance with the categories listed in the module's feed XML (if using package manager [[0install]] for release distribution). This is slightly redundant but necessary because the wiki lists ''not yet released'' projects and may serve as an overview to many people (mostly developers) while searching for ''released'' projects should be done using the cross platform package manager.
  
 
==Forum==
 
==Forum==
Zeile 32: Zeile 29:
 
* general discussion (while topic specific discussion for reference in commit messages goes into Github issues).
 
* general discussion (while topic specific discussion for reference in commit messages goes into Github issues).
  
−
Repositories exist on [url=http://github.com/worlddevelopment]worlddevelopment github[/url] only if it fits into one of the following categories:
 
−
* club matters
 
−
* selection / collection of repositories (e.g. like the GVCS 50 of the OSE US but consistent, more flexible/forkable and version controlled). This is just a complementation to the Wiki that allows to add, remove all released modules of a category at once. For getting an overview of which projects are in development one should ideally get a good overview via the [url=http://wiki.opensourceecology.de/Spezial:Kategorien]category listing on the Wiki[/url].if every project on the Wiki is tagged extensively. (Currently it is inconsistent and incomplete.)
 
−
 
−
The repositories are collected from any eco github organization or eco individual across the world (as long as it is a hosted project, e.g. Git or 0install or a UNIX distribution package).
 
  
−
It must be admitted that worlddevelopment is not consistently using 0install for dependency handling as of now. Sometimes it is still using Git submodules which is deprecated because it is no dependency handling at all and does not allow to define a compatible version range but only one and exactly one commit.
+
[[Category:organization]]
−
This inconsistency is targetted.
+
[[Category:toolchain]]
 +
[[Category:workflow]]
 +
[[Category:worlddevelopment]]

Aktuelle Version vom 18. Juni 2017, 19:51 Uhr

A project may be structured as follows:


Repository

  • Version control of development files.
  • Distributed development.
  • Automatic backups (due to existing on several systems of distributed developers / users).
  • Integration with a versatile release and dependency tool.

Wiki

  • Documentation
  • Guidance, e.g. a very short outline of useful functionality modules. The wiki is a better place than base repositories because such a collection is
    • subjective,
    • context dependent, e.g. eco focus versus gigantism focus, and
    • prone to incompleteness (new module created without knowing of it)
    • hard coded
    • or a movement may want to link to a certain eco-flavored fork of a base module giving the reader guidance in what repository / release to install.
    • Somehow a connection must be created between Wiki and repositories. And such eco modules listings are one possiblity for achieving that.
  • Tagging: The projects' documentation/guidance is tagged using Wiki categories in accordance with the categories listed in the module's feed XML (if using package manager 0install for release distribution). This is slightly redundant but necessary because the wiki lists not yet released projects and may serve as an overview to many people (mostly developers) while searching for released projects should be done using the cross platform package manager.

Forum

Each wiki links to this forum topic for

  • news / announcements all in one location without having to create a new website for each and every project / module.
  • general discussion (while topic specific discussion for reference in commit messages goes into Github issues).
Abgerufen von „https://wiki.opensourceecology.de/index.php?title=Project_structure&oldid=12926“