Re: [RFC] 3.1 branching

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Tue, 23 Sep 2008 23:30:37 -0600

On Wed, 2008-09-24 at 14:34 +1200, Amos Jeffries wrote:

> > Do we go from trunk to PRE or from trunk to DEVEL? I do not think trunk
> > code is stable enough to be called PRE at this point, so I was expecting
> > DEVEL. Personally, I would just call it 3.1.0 and categorize it as
> > "development" on the web site until we can move it into the stable
> > category (after a few 3.1.x releases).
>
> Before conn-pinning came up as an option I was thinking PRE. But it and
> the other things destabilize enough to warrant a DEVEL period at least.
> I'll decide after branching whether to release DEVEL, immediately or wait.

Please email RFCs before making the final decision about the labels and
releases. Until we get to a stable stage, the labeling and timing of the
releases should be discussed as it can benefit from what others have
seen in their tests.

For example, IMO, the trunk was/is not PRE-ready even after the recent
fixes and before conn-pinning.

In general, I think we should virtually always do at least one
development release before a PRE. Jumping from trunk to PRE is much more
likely to discredit the branch than a development-to-PRE delay.

PRE, to me, means "we think it is stable, what do you think?".
A development release, to me, means "we are done adding features, please
help us with testing and polishing". And yes, I know that the
definitions at http://www.squid-cache.org/Versions/ are somewhat
different. IIRC, I failed to convince others that mine are better :-)

> Concentration on the branch blockers then we can split and put the new
> stuff and enhancements in trunk away from the hardening 3.1.x.

> > Other important problems:
> > http://www.squid-cache.org/bugs/show_bug.cgi?id=2459
> > http://www.squid-cache.org/bugs/show_bug.cgi?id=2460
> >
> > I have asked somebody to work on these for the next 10 days, but I do
> > not know if they will be able to fix them. I can work on them after
> > eCAP.
>
> If they need a mentor I can probably assist in auditing 2459.

Thank you, I will keep that in mind!

> > Also, it would be nice to review and commit TCP_RESET propagation patch:
> > http://www.squid-cache.org/bugs/show_bug.cgi?id=2042
> >
>
> Well, this is what the branch is for, so we can commit these 'nice' things
> to trunk for 3.2 from 30Sept on and start their testing as well without
> affecting the stability of 3.1.

I meant that it would be nice to include RESET propagation in v3.1 not
v3.2 :-). Not a big deal though.

> The non-major but important bugs can be fixed during DEVEL and PRE
> cycles. Branching is about features not bugs.

Agreed, except I do not think we should have any known important bugs
when doing the first PRE (if we do PRE at all).

Thank you,

Alex.
Received on Wed Sep 24 2008 - 05:30:43 MDT

This archive was generated by hypermail 2.2.0 : Wed Sep 24 2008 - 12:00:06 MDT