Project structure: Unterschied zwischen den Versionen
(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: Clarify tagging, especially that 0install only lists released and local modules while the wiki should list and tag all.) |
||
Zeile 23: | Zeile 23: | ||
** Tagging: Somehow a connection must be created between Wiki and repositories. And such eco modules listings are one possiblity for achieving that. | ** Tagging: 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. | + | So now the projects can be tagged properly using the Wiki categories. (Tagging the documentation/guidance in accordance with the modules which is done using a cross platform package manager [[e.g. 0install]]. This is slightly redundant but necessary because the wiki lists ''not yet released'' projects and may serve as an overview to many people while searching for ''released'' projects should be done using the cross platform package manager. |
− | |||
==Forum== | ==Forum== |
Version vom 2. Januar 2017, 22:56 Uhr
A project may be structured as followed:
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
- As functionality modules collection/guide.
- 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
- 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.
- Tagging: 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 documentation/guidance in accordance with the modules which is done using a cross platform package manager e.g. 0install. This is slightly redundant but necessary because the wiki lists not yet released projects and may serve as an overview to many people 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).
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. This inconsistency is targetted.