Re: Future squid development

On Mon, Oct 02, 2000, Henrik Nordstrom wrote:
> There is a fair bit of development effors waiting to get into Squid, and
> to ease the development during the next development cycle I'd like to
> propose the following:
>
>
> * All developments are done in separate branches until tested
> (preferably on squid.sourceforge.net, but a separate branch on
> squid-cache.org is OK if you don't agree with this). Only changes which
> have been tested by at least two developers gets committed to HEAD, and
> only after first being presented in both reasoning and patch format on
> squid-dev.

I like this idea. We COULD do all our development on squid-head, but since
a lot of work over the coming months is going to involve ripping quite a
few subsystems to shreds, seperate branches is going to be a LOT saner.

> * Bug fixes must be published at the time of commit, and applied both on
> HEAD and the latest STABLE release (if applicable).

Aha! FreeBSD MFC-style handling. I'd propose waiting a week or two before
putting it back into STABLE, to give the bug fix time to be bug fixed.

> * To the latest STABLE release only bugfixes are allowed, unless a poll
> on squid-dev indicates that there is a consensus on that the change
> should go into STABLE.

Agreed.

> * New STABLE releases are automatically made 4 weeks after the last
> change, even if the change is quite small.

* All new major architectural changes require at least the basics of
  documentation. I'm even willing to take documentation that people give
  me in point form .txt format, and spend the time understanding it to
  write up some DocBook documentation, but we need to improve the programmers
  guide somewhat.

> Any objections to this?

None.

Adrian

-- 
Adrian Chadd			"If a butterfly flaps its wings in China,
<adrian@creative.net.au>	    will a women get naked in Amsterdam?"
				      -- Ashley Penney on Chaos Theory