maintainence change proposal
tridge at linuxcare.com
tridge at linuxcare.com
Thu Nov 25 23:12:30 GMT 1999
> 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
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
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?
More information about the samba-technical