Mars Drafting Library - Official community driven library

[HaraldZealot via Digitalmars-d]

>
> Possible initial prerequisites:
> - User awareness about the usage consequences
> - Library placed at https://github.com/D-Programming-Language/
> - Only well recognized community members have pull rights
> - design decision made on the best known sw engineering 
> patterns used in D
> - New module should be functional with D/Phobos standards 
> applied
> - API and implementation allowed to change any time in order to 
> make a progress
> - no external dependencies beside OS services
> - "draft" as the root module name e.g. "module draft.gui"
>
> Advantages:
> - community driven process which ensures the lowest level of 
> controversy
> - fast path for modules like GUI to be standardized
>
> Disadvantages:
> - additional effort for the sw release process
>
> Ready to be destroyed ;)
>
> Piotrek

Approximately a half year ago I have similar idea and suggestion.

This is my idea:
* make new feature in dub, that it can place some libraries in 
common namespace.

For example CyberShadow's ae will be placed in something like 
advancex.image, or logger (lucky it is in std.experimental 
already, but as alternative history) is placed in stdx.logger. 
But they are not part of phobos in that time but usual dub 
package on dub registry.

* create namespaces "advance" (or any other) for useful but not 
so common components (e.g. proposal windowing, image processing 
an so on), "bind" for Deimos. Phobos is "std" already :). And 
also create their experimental counterpart like "advancex", 
"bindx" and "stdx". (It can be other name but I prefer one worded 
"stdx" than two worded "std.experimental" in other level of 
hierarchy").

* make new feature in dub and dub register that counts download, 
likes and bugs. When some package receives essential feedback it 
can be started pull request process.

* all packages in special namespaces can't be orphan. 
Experimental version must have at least one active maintainer. 
More approved namespace require two responsible maintainer one of 
which at least someone from trusted user. If package became 
orphan it will be dropped out.

In this manner we can create stair like development. To place 
simple package in dub registry you have the same condition as for 
now. If you want place it in experimental namespace you must 
complete some easy condition (more complicated in case of "stdx" 
and perhaps "bindx"), and you package must go through full review 
process in case of phobos.

You can see on archlinux as example of such package management.


For now I drive two interesting project, but I also try to find 
forces for this one.