Re: Future squid development

On 4 Oct 2000, at 8:05, Adrian Chadd <adrian@creative.net.au> wrote:

> > > HEAD is always the current development version of the Squid which is
> > > meant to be the next Squid version someday.
> >
> > ie, currently 2.4devel? or is it 2.3stable-latest?
>
> Ok. I think you need a picture here.
>
> HEAD
> |
> 2.4DEVEL4
> |
> 2.4DEVEL3
> |
> 2.4DEVEL2
> |
> 2.3STABLE -- 2.3STABLE1 -- 2.3STABLE3 -- ..
> |
> 2.2STABLE -- 2.2STABLE1 -- 2.2STABLE2 -- ..
> |
 
 Yes, this is very nice. And this is quite what I've been assuming.
 
 As a comparison, what I proposed is this:
 |
 2.5HEAD
 |
 2.4HEAD-PRE --> 2.4STABLE -- 2.4STABLE1 -- ..
 | \
 2.4HEAD \<-merge-\
 | \
 2.4DEVEL4 \
 | \
 2.4DEVEL3 \
 | \
 2.4DEVEL2 \
 | \
 |-- 2.3FEAT -- 2.3FEAT1 .. 2.3FEAT-X
 |
 2.3STABLE -- 2.3STABLE1 -- 2.3STABLE3 -- ..
 |

 If non-dev people create a feature they need, they want to see it appear
 in the next FEATURE release that is based on good old STABLE and is not
 touched with any radical changes. If they can't easily commit their changes
 to developers, they either have to maintain their patches on their own or
 enter HEAD development. If neither is inconvenient to them, they stick with
 their old STABLE with their patches and will not submit their changes to
 developers at all.

 Dont view this proposal as request for new standard. Better view it as a
 try to be nice to users who casually patch their boxes for good. View it
 as a users-corner. For users it is a pain to maintain their patches, also
 add patches from other people. I think that patches, if wrapped up decently
 can be also committed to HEAD at the same time as to FEAT. Its just that
 HEAD is where serious development occurs, and FEAT is where small changes
 occur. STABLE is where no changes occur, only bugfixes.

 IMHO it is also important to have strict and clear version numbering, so
 that people who look at using FEAT versions have a very clear picture of
 what they are about to use. Daily snapshots are very unclear. (I wonder
 how often any snapshot is ever downloaded?)
 For most nondevoted people HEAD or snapshot sounds nowhere even near to
 being stable. Most won't even bother looking at them. But if you wrap up
 a snapshot as "2.3FEAT4 is based directly on 2.3STABLE4 with new features
 added in FEAT tree and bugfixes maintained in STABLE and FEAT. So this is
 as stable release as STABLE tree, unless some new feature added to FEAT
 screws it up", it sounds much better.

> Well, DEVEL has always to me been aimed towards developers and not production
> machines.

 right, this is well understood. And this is one reason why only a handful of
 people are really working on it. The rest are waiting for the next STABLE.

> Thats fine. Noone is going to stop you DEVELOPING on a STABLE branch. Its
> just when you want a feature committed, you're going to have to make it
> work on the DEVEL branch. At least once you've done that, we can commit your
> change to BOTH the latest STABLE branch and HEAD. :-)

 Thats inconvenient for casual coder. If I add a new feature to stable, I
 want to use it from that on, also on next later revs of STABLE. I don't
 really want to start working on HEAD just because I wanted it committed.
 Besides, it doesn't give me much, because next STABLE from HEAD rolls off
 half a year later. And I need that feature on my production box, not testbed.

 Therefore I dream of squid tree that is current STABLE with user-submitted
 features, and that it increments and incorporates bugfixes submitted to
 STABLE each time new STABLE is rolled. I want someone else to maintain
 my patches ;) and integrate with others' fixes. People are lazy. People
 want to see fast return on investment ;), and if they don't they loose
 interest quickly. Thats life. Very few users ever subscribe to squid-dev,
 let alone look into CVS tree or download a HEAD.

 I wish to make it easier for such users, more fun, and I think this could
 increase usage of such realeases on production boxes, meaning we can have
 much more feedback and time to fix bugs. We can test some DEVEL features
 already in STABLE tree by way of FEAT releases, meaning we can get more
 feedback before new STABLE gets out to public.

> You can't branch HEAD from anything.

 why not? http://www.cisco.com/warp/public/620/roadmap.shtml
 Cisco is maintaining 2 trees, for eg. STABLE isn't touched with features,
 only bugfixes. Feature (T) tree is where new features are added, new
 branches spawned from, and completed branches merged into. But it isn't
 HEAD, head is hidden from public, its semistable STABLE with new features
 added, with these features also committed to their internal HEAD. Each
 (T) version is released shortly after STABLE is released, so they increment
 in pairs. Before next major release, they cleanup, integrate with HEAD
 which may have even deep design changes, cutoff unsuccessful branches,
 and release a new featurefreezed STABLE, starting new (T) tree shortly.
 I'm aiming at something similar.

 Well, I understand that I should not call it HEAD what i mean, althought
 its tempting.

> * all hacking happens on HEAD
> * all bugfixes happen on HEAD and relevant STABLE branches
> * When a useful change is made on HEAD and is stable enough, the change is
> made to work in one or more relevant STABLE branches, and committed
> * Throughout the lifetime of a STABLE branch, you roll new STABLE releases
> from it, as more bugfixes and changes are brought forward into it from
> HEAD in the above process.

 Now I'm confused again. ;) if HEAD is 2.4DEVEL + more, then how can you
 easily roll new STABLE's from it? At best you can only try to apply same
 patches to both, HEAD and STABLE, and fix any conflicts by hand. But HEAD
 and STABLE are different things starting from STABLE branch, isn't it?

> > If latest Stable-HEAD isn't stable, people could revert back to
> > previous or STABLE, or take that HEAD and get it fixed.
>
> There's no concept of STABLE-HEAD.

 I know. this is what I'd propose to add.

> This is just a general problem we have right now due to a lack of developers
> (which is slowly being fixed again, yayayay.)

 I hope that if we had such users-oriented tree that is based on STABLE,
 we would see more people participating in developing, and hopefully more
 people would join real HEAD developing eventually.

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 Delfi Online
 Tel: 6501 731, Fax: 6501 708
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Wed Oct 04 2000 - 03:18:00 MDT