WANTED: submitted module manager(s)

[Zbigniew Łuszpiński]

> Remco Lubbers wrote:
> > How should we go about?
>
> This is my biggest problem as it is right now as well. My idea is to
> relief some of the work that covers all of moonbase (2500) apps into two
> categories:
>
> (1) most important modules that are vital to any lunar installation
> (2) userland applications and pretty much everything that doesn't fall
> under (1)

A list of (1) modules would be good thing. So we could know which modules do 
not touch. We need some way of assigning mechanism to avoid parallel work - 
however this can be done via mailinglist.

> The active developers should already maintain and keep current modules
> in category (1), so this is not the immediate goal of a support-group.
>
> Based on this I can say that we need people who are willing to:
>
> * handle user requests for category (2) modules
> * test version updates and perhaps contact module authors
> * add MAINTAINER lines to category (2) modules
> * submit updated modules in an easy form to assigned developers who can
> merge them into moonbase

The module authors should not add maintainer line by default. This must be 
optional for people who are really aware, serious and understand what 
responsibility does it mean.
Thus module authors interested in further maintaining modules should promise 
that will keep their modules updated, if they can not do this anymore a 
message should be sent to lunar mailinglist. Otherwise maintainer line should 
be removed. (I never thought I say that but keeping modules live is more 
important). If few versions will appear and module will not be still updated, 
author disappeared, the module should go to orphaned subcategory so other 
people can take care.

> Second, I would think that the following would be in order:
>
> * willingness to test all current updates and new category (1) releases
> and report on them to the lunar-dev@ mailinglist
> * sign off on modules and rotate them first within the team before
> submitting them
> * working in a separate svn sandbox shared within the team (provided by
> and accessible by the lunar devs)
> It basically comes down to increasing the amount of time that is spend
> on testing (test-compiling, reading) modules before going to the commit
> stage. We developers also neeed to start changing the way we work too:
> we should read modules closely (use diffs) and NOT spend time compiling
> them. This will help us a lot and definately speeds things up

The changes made by module managers should be sent as *.diff files? Attachment 
or inline?

> Since we moved to subversion, it's possible to allow people to have a
> 'sandbox' tree in your local 'zlocal' next side-by-side the normal
> moonbase. I hope to exploit that feature and allow non-developers to
> have a joint subversion repository that will work over https. We
> developers can then merge modules from that repository back into
> moonbase quickly.
>
> Most of this needs more explaining, but I hope the grand lines are
> clear. We do need some adjustments to accomodate easy
> merging/transferring of modules but that's probably the easiest step.
>
> so? comments? ideas?

Yes. Very wise. I like it :-)
I'm still interested. I think I can handle such task.

> sofar

greets,
zbiggy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://foo-projects.org/mailman/private/lunar-dev/attachments/20050525/067fabe1/attachment.bin