Re: Future squid development

On 4 Oct 2000, at 20:33, Henrik Nordstrom <hno@hem.passagen.se> wrote:

> Having new feature developments based on the latest STABLE will be a
> quite big burden when there is time to merge this with other
> developments, and quite often there are dependencies between two
> developments, making this even harder.

 perhaps. We might warn people that extensive changes should be done
 to HEAD, only isolated features are accepted.

> What you propose works well if the change is a isolated feature that
> a) No other developments depends on
> b) Does not depend on any other developments

 This is quite typical, btw. people who create extensive changes to
 squid most probably don't have problem with maintaining their work.

> But still, if you want it to be based on the latest STABLE release until
> we are close to the next STABLE version then there will be a major work
> in merging these together.

 I still don't quite get how current STABLE is maintained. I understand
 it that all patches are committed to HEAD, and then CVS does some magic
 and pushes the changes down to STABLE, if some CVS revs match.
 Or are all patches manually pushed down to the STABLE?
 In any case, there is some filtering or selection going on what goes
 down to STABLE and what is left out. Question is, is this selection
 (semi)automatic or totally manual?

> > In two words, I propose branching from HEAD a parallel tree to STABLE,
> > that gets same bugfixes that STABLE receives, but also receives some
> > of new features that HEAD receives, but not all, only those that do
> > not need extensive stability-proof record. That way, this FEATURE tree
> > stays based on latest STABLE, includes some new features committed to
> > HEAD, and shouldn't become a headache to merge with HEAD - its based
> > on HEAD, only a subset of it. Does that make sense?
>
> You cannot base something on a subset of another branch, only the other
> way around: a subset can be the base for the larger work.

 Now you got me again ;) I don't understand this sentence ;)
 What I meant is that FEAT tree would accept bugfix patches committed
 to STABLE/HEAD, some independant feature patches, but will reject
 changes unsuitable for inclusion in STABLE/FEAT.

> > What this gives to people, is a branch that is untouched by DEVEL
> > branch merges, yet includes small changes to STABLE that people find
> > useful. And it allows to keep STABLE totally untouched by new feaures.
>
> Sure. Then find someone (you?) who accepts taking the role of
> maintaining what goes into this branch and when.

 well yes, me being loudest yeller it would be honest, yet I'm not sure
 if I'm suitable for that.

> > The only assumption is that HEAD accepts patches against STABLE or
> > this new FEAT tree. Is this possible?
>
> Yes, sometimes, but not for very long. Quite soon there will be changes
> in HEAD which makes it incompatible with FEAT/STABLE, making it a major
> burden to apply the patches to all trees.

 This is understandable. I wonder, how currently new feature submitted
 by users are handled. Most probably users patch STABLE and patch may
 be incompatible with HEAD. Are these patches handled manually, or left
 aside?

> What might be manageable is if someone takes the role of maintaining
> this FEAT release and backport changes from HEAD.

 is this how STABLE is maintained now?

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 Delfi Online
 Tel: 6501 731, Fax: 6501 708
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Thu Oct 05 2000 - 11:16:08 MDT