maintainence change proposal

[David Lee]

On Fri, 26 Nov 1999 tridge at linuxcare.com wrote:

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

Thanks for following this up, Tridge.  Appreciated!

It is worth noting that I have already received several (probably about
10) private requests for the "inherit mode" patch, which indicates:

(a) The importance of trying to get patch assessment and incorporation (or
rejection!) streamlined; 

(b) The dangers of failing to streamline: a patch gets handed out to lots
of individuals.  When/if it does get included in the distribution, certain
changes (behavioural or interface) might be agreed, and those poor
individuals who have the earlier, privately-distributed, patch are then
faced with a transition problem.  And how are such changes from
private-patch to included-function to be publicised to them? 

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

Can you clarify:  isn't this basically what already happens?  (With the
possible exception of "not [a team member] ... 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. 

Against what version?  For ourselves:

1. We are a production site (19,000 users, over 1,000 PCs) and would not
be anywhere near the CVS tree.  We keep reasonably up-to-date with
official releases, but with care.  For instance before going to 2.0.4, I
followed the unfolding story of a problem in it: when we moved, it was
straight to the "b" ("2.0.4b").  Likewise, we never did anything with
2.0.5 releases because of a known timestamp problem.  Somewhat
exceptionally, I did put the "pre3" version of 2.0.6 into service,
specifically because it included one of our own requested patches
("preexec close") and it was only right that we should expose ourselves to
this slight risk for the benefit of the wider Samba community.

2. A patch might itself require changing from release to release. 
Specifically, both my "inherit mode" and "veritas quotas" patches
fail to carry over from 2.0.4b to 2.0.6 because the source files
themselves changed.

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

Case: "inherit mode" has been discussed, quite extensively, back in
September.  The patch was included.  What would happen next?

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

Counter-productive?  The offer of T-shirts might generate more workload!

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

How about a Web-based "test patches" area?  If front-ended with a brief
and simple (and it must be brief and simple!) form, then at least a count
could be kept of requests for a particular patch.  (Example:  I would
upload my "inherit mode" patch there, and direct anyone who wanted it to
that place.)

Thanks, Tridge, for trying to address this area.  Best wishes with your
endeavours.


-- 

:  David Lee                                I.T. Service          :
:  Systems Programmer                       Computer Centre       :
:                                           University of Durham  :
:  http://www.dur.ac.uk/~dcl0tdl            South Road            :
:                                           Durham                :
:  Phone: +44 191 374 2882                  U.K.                  :