WANTED: submitted module manager(s)

[Remco Lubbers]

On Wed, 25 May 2005 20:18:30 +0200, Zbigniew £uszpiñski said:

>  > 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 - 

this also goes for the testing part! We will have make sure that we not
testing the same thing 25 times, while leaving other keyfeatures/setups
untested, thus bumping versions that still cause problems on the
enduser's part...

>  however this can be done via mailinglist.

hmmm, for me (I've been using Lunar for 2+ years now) it still is not
clear how and where to report bugs/requests efficiently. Might be
usefull to have either a separate tool for the complete route of
submission, testing and modification. If everything is recorded
centralized it is very conveniant to have an overview of what has been
going on and people (devs & testers don't need to spend time just to
figure out what the status is).

I think it would be a good idea to add a status-feature to the moonbase
modules, so that we need only one repository for all modules. Users
(and testers) can set their preferred state through lunar. I think
three states would be suffient: stable, beta and alpha. This would make
it very easy for all to have a look at newer versions without having to
worry that it'll take a lot of time to roll-back to a previous/stable
version. If someone (tester or otherwise) wants to check out a
beta-module a simple 
'lin --status=beta <module>' would be enough, eventhough the default
status (in lunar) is set to stable. It the (beta-)module does not
compile correctly or does not work as expected a simple 'lin <module>'
would (re)install the stable version.

This is how things work in pear and I really like the efficiency!
<example>
root at server1 ~ # pear list
Installed packages:
===================
Package 	     Version State
Archive_Tar	     1.1     stable
Auth_SASL	     1.0.1   stable
Console_Getopt	     1.2     stable
DB		     1.7.6   stable
Date		     1.4.3   stable
File		     1.2.0   stable
Fileinfo	     0.3     beta
HTML_Template_IT     1.1     stable
HTTP_Request	     1.2.4   stable
Log		     1.8.7   stable
Mail		     1.1.4   stable
Mail_Mime	     1.3.0   stable
Net_SMTP	     1.2.6   stable
Net_Socket	     1.0.6   stable
Net_URL 	     1.0.14  stable
Net_UserAgent_Detect 2.0.1   stable
PEAR		     1.3.5   stable
VFS		     0.0.5   beta
XML_RPC 	     1.2.2   stable
memcache	     1.4     stable

root at server1 ~ # pear config-get preferred_state
beta
</example>

The only thing I haven't work out yet is how to report findings so that
it can be viewed by everybody interested without too much hassle.
Developing stuff here, we use CVS for that, but it's a small team and
just a few apps...

>  > 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

agreed! Devs shouldn't be bothered with testing too much. I'd rather
have them spend that time on documenting what they have done and why
ans respond promply on errors/problems found by the users/testers.

>  > 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. 

As long as it isn't too complicated for non-devs. IMO you'll scare off
users/testers if it's too complex to get a module-to-be-tested
installed/removed.

Remco