maintainence change proposal

[tridge at linuxcare.com]

> Still what is the preferred route for the Samba team - discussions in
> samba-technical mailing list AND/OR submissions to samba-bugs mailing list.

Peter, I'm glad you brought this up.

We have a fundamental problem that we get far more patches and bug
reports submitted than we have time to deal with. This means that if
he patch isn't "obviously correct" after a short read it tends to go
into the "deal with later" pile and that pile moves very slowly, if at
all.

To give you an idea of the scale of the problem, I only answer about 1
in 20 emails that I receive. I just don't have time for more than
that. We have received well over 20k messages to samba-bugs. Several
team members have been working valiently to help with the load but
we're still not keeping up.

One thing I'm thinking of doing is getting rid of samba-bugs at samba.org
and replacing it with samba-patches at samba.org which would go into a
public JitterBug, rather than the private one we use now. The reason
we can't just open up the current system is that too many people send
in bug reports containing sensitive info (sniffs with passwords, IPs,
user names etc). I would set samba-bugs at samba.org to send an autoeply
that explains the new system.

The new system would work as follows:

1) users send bug reports and help requests to the mailing lists. Most
   people would use samba at samba.org and more technical in-depth stuff
   would go to samba-technical at samba.org

2) someone (perhaps a team member, but often not) would either answer
   the question, point out an FAQ entry or work up a patch.

3) fully tested and documented patches would go to
   samba-patches at samba.org for a team member to apply. Everyone can
   view the patch queue at any time via the web interface. If the
   message to samba-patches doesn't contain a patch it will be
   dumped. Patches must be in unidiff format and must include a brief
   explanation, any relevant doc updates, autoconf changes etc. If the
   patch doesn't apply cleanly it is rejected. Rejected patches are
   put in a "rejected" JitterBug folder so they can be looked at by
   anyone who wants to resubmit after fixing the problems. 

4) larger changes would need to be discussed first on
   samba-technical. If nobody objects then send a patch to
   samba-patches.

5) Rusty has suggested a web based "patch scoreboard" where people get
   points for submitting clean patches. That gives a bit of
   satisfaction so all that work at least gets you a entry on
   samba.org. Maybe we can send out t-shirts to the top contributors
   every few months?

The current system isn't working too well and I hope the above will be
better. It should make much better use of our time and let us progress
faster. What do you think?

Cheers, Tridge