Re: Proposed release process/plans - don't branch too soon

[Michael Meeks <michael ximian com>]

Hi Havoc,

On Mon, 2002-06-10 at 20:00, Havoc Pennington wrote:
> In any case, AFAIK right now Michael has been doing:
> 
>  ---------------------------------> HEAD
>    \               \
>     ------2.0.0     --------2.0.1

	Let me just rationalize the above; and explain why I think it is a
serious mistake to branch for 2.2 right now, certainly for the platform
libraries I'm working on. This is mainly because there are a good deal
of bugs / minor features [ like security auditing ], that need to go
into them, and I don't want to be committing to 3 branches.

	The release team froze 2.0.0 for ~2 weeks - in that period, the only
way we could fix critical but non blocker bugs in the stable branch was
by committing to HEAD - [1].

	This pattern will be repeated with 2.0.1 I am sure, and I'm yet further
convinced that by 2.0.1 we'll still have plenty of bugs to fix - as the
real brunt of the user testing hits us.

	So; if we branch for 2.2 too early (to my mind) we will get something
that looks not like this:

>  ---------------------------------> HEAD
>       \ 
>        - 2.0 branch ---------- 2.0.x tag ----- 2.0.x+1 tag ---- 2.0.x+2 tag

	but like this:

>  ---------------------------------> HEAD
>       \ 
>        - 2.0 branch -------------------------------------- ...
                          \                      \
                           --- 2.0.0 branch       --- 2.0.1 branch

	The problem with that being that we then have ~3x as much effort to
merge a critical bug fix in - of which there are many ( as previously
discussed ), and pretty much a nightmare.

	My feeling would be that for most modules, with lots of bug fixing
action; and the need for this hard core code freeze before release -
that we stick with the original approach, at least until the next
release, and encourage people to fix bugs, and implement new features (
such as file selectors ) in 'libfoo'.

> Luis pointed out that there is some controversy over when this "2.0
> branch" begins, what I'd written down is that it begins with 2.0.0,
> and what other people thought is that it begins with 2.0.1.

	Problem is we already branched for 2.0.0 :-)

> The more I think about it the more I think that takes too much
> momentum out of new feature development

	I think that momentum can come back; but as it is a large number of
engineers have to work on stable to fix bugs - this is the brunt of our
effort at the moment - and having to commit to 2 or 3 branches instead
of simply HEAD will make things extremely painful.

	IMHO,

		Michael.

[1] - some people think queueing tons of bugs / patches in bugzilla is a
good workflow, I do not.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot