httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Richards <p...@netcraft.co.uk>
Subject Re: NEXTSTEP bug fixes (fwd)
Date Tue, 29 Aug 1995 18:21:27 GMT
In reply to Robert S. Thau who said
> 
>   We're going to look bad releasing code with known bugs *and* known
>   fixes.
> 
> Funny.  No one seemed to mind that, certainly not *you*, when 0.8.8 had
> been the current release for nigh on three weeks, and I was *desperate*
> to get something out the door which included bug fixes, some of which we
> had had in hand for almost all of that time, which were at least as
> serious as this.

Geez, getting more and more like freeBSD-core every day :-)

> 
> In the meantime, there are seventeen patches on the current ballot as it
> stands.  That number pushes the bounds of what is manageable as it is, and
> if we put the vote off for another day, there will be another one, and then
> another the day after that, and then another...

I think internal releases are becoming necessary.

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. There's two issues to resolve

1) Public releases need to include all patches that fix known bugs,
   releasing code with bugs in that some kind user already submitted
   a fix for is bad PR. Public release also need to be in reasonably
   good condition, having to release bug fixes immediately after
   a release makes you look bad since people assume you haven't
   tested the thing properly.

2) There needs to be a reference source so when we talk about patches
   we know what they're against. As the number of patches grows this
   becomes difficult and the individual patches start to conflict with
   each other.


Solution:

	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.

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.

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.

-- 
  Paul Richards, Bluebird Computer Systems. FreeBSD core team member. 
  Internet: paul@FreeBSD.org, http://www.freebsd.org/~paul
  Phone: 0370 462071 (Mobile), +44 1222 457651 (home)

Mime
View raw message