httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Robert S. Thau)
Subject Re: NEXTSTEP bug fixes (fwd)
Date Tue, 29 Aug 1995 19:55:28 GMT
   From: Paul Richards <>
   Date: Tue, 29 Aug 1995 19:21:27 +0100 (BST)

   There are too many patches pending so that the current version of
   the code is a bit hit and miss because people are applying some patches
   and not others as they try things out.



	   Very simple really. Patches are voted on and incorporated
	   more frequently. If a new src tree is rolled weekly then
	   the number of outstanding patches will stay manageable.
	   Patches that are dubious, like the current BSD patches,
	   aren't applied to the new src tree but are held over until
	   the issue can be resolved.  These weekly src tree's are
	   not public releases, they're for the developers to sync up
	   all the patches flying around. When a week ends and there
	   are no patches, or it's just generally felt things are in
	   good shape, make that week's snapshot public.

Unfortunately, in this instance, weekly doesn't seem to be often
*enough* --- having seventeen patches clearly stresses this process to
the breaking point, if not past.  (Yes, it has been exactly one week
since the past vote).

However, votes more often than that are logistically infeasible.
(Really).  This is a problem.

   Long term solution:

	   Stick it in cvs and allow trusted developers to add the
	   patches as they come in. If they turn out to be bad they
	   can simply be taken out again. Run sup so that the developers
	   can keep their local copies in sync with the master tree. This
	   is basically what all the "large" public domain projects do,
	   such as FreeBSD, NetBSD, XFree86 (not exactly but similar), etc.
	   People can work on their local copies adding really raw and new
	   ideas and still pull in the day to day patches and when they feel
	   their experimental local trees are ready they can diff against
	   the current tree and submit their changes.

This is more or less what I was doing with the 0.8 releases up to
0.8.9, at two or three spins a week, except that I wasn't "trusting"
anyone else.  For the most part, it seemed to me at least to go all
right, but there were two sorts of problems:

1) I did, every so often, screw up, as in the case of the "simple fix"
   to Cliff's friend's cache-interaction bug which turned out to be
   neither.  I think I pulled all of these (with the exception of the
   case of the trailing slashes, where drtr claims to have a better
   fix than the one I tossed in, which I've asked him twice to resend
   without success), but there was a considerable degree of friction
   associated with some of these incidents.

   However, some degree of human error is present in any such process
   --- to find these errors quickly, people need to be able to find
   out what changed (the reason why I was keeping detailed change
   logs), and also to be willing to accept that the trusted members,
   being human, can and will screw up every once in a while even when
   acting in good faith.

2) We did get into catfights about my refusal to include some patch,
   or some idea.  These were, of course, things that I could have
   vetoed in a full vote anyway (and generally would have), but even
   so, this led to lots of complaints that I, or that the process,
   wasn't sufficiently democratic.

   Perhaps a defined procedure for calling for a vote on a specific
   issue (under the full voting rules, including a veto for *all*
   interested parties) would have helped clarify matters here...

One final issue with such a process --- who do you trust becomes a
serious question.  Even among the fairly active project members, there
are some people who I wouldn't mind hacking the code base without my
review, and others for whom I really do want to scrutinize their code
line by line before it goes in.  (I suspect some of those don't trust

Maybe there's no way out.

   I think the first solution is necessary now, the second is the only way to
   deal with the longer term problem of running a popular project which
   Apache is rapidly becoming. We used the "collect patches and try our
   best" scheme for 386BSD and things got into a real mess when the user
   base grew from 10's to 100's to 1000's because the number of patches
   submitted became unmanageable and they always conflicted with each other.

Ahem... there is this thing called Linux...


View raw message