Re: stable branch release policy [was Re: Possible bug in intersect]

[Jaroslav Hajek]

On Thu, Apr 16, 2009 at 1:09 AM, John W. Eaton <address@hidden> wrote:
> On 12-Apr-2009, Jaroslav Hajek wrote:
>
> | I think the correct policy would be *regressions only*, as has been
> | suggested by John, but I don't think that's what most users expect.
> | That would likely require more frequent stable branches.
>
> I'd like to have this as well, but to make it work, I think we will
> need to have some additional structure in the way we work with the
> main development tree.  I'd be happy to use something like the stages
> used in GCC development.  I can't remember the details and can't check
> at the moment, but the idea is to have a feature freeze and reduce the
> number of important regressions to zero some time before a release.

The problem with the "feature freeze" state is that it, IMHO, should
not make the development cease.
If we enter the "feature freeze" state, no bugs seem to occur that are
*in my scope* of interest (which may still mean there are bugs and
thus the freeze may last for a long time), I would like to continue
development of other features (perhaps for next release), and I would
like to do so in a public repo, so that others may clone and build
without annoying digging patches from mails. Also, I sometimes want to
access the repo from multiple machines.
As I explained numerous times, continuing a parallel development
without allowing merges is painful, because you need to repeatedly
rebase your patches (or fold them), and sometimes even repeatedly fix
conflicts.
Taking partially inspiration from Mercurial (which however has more
active developer community),
I propose the following:

1. The savannah archive will become the "stable" repository.
2. We create an "experimental" (or better name?) repository, probably
using Thomas Weber's hosting.
3. Merges between experimental and main repo are *allowed* (in
general, we shall always allow merges only with a limited number of
public repositories).
4. Bugfixes will primarily be applied to the "stable" repository.
"experimental" will be frequently merged with "stable" (by anyone
using it) to get all the fixes and to make merging easier.
5. New features, performance improvements (except important
regressions) etc will be primarily developed in the "experimental"
repo. "stable" will be occassionally merged with "experimental" to get
new features.

This will make users more aware of code that is going to be released
soon - the savannah archive, allowing bugs to be caught earlier. I am
under the impression that nobody really cared about the
"release-3-0-x" repository until I started to create release
candidates, which contributed to those bugs in 3.0.4.

It will also enable interested people to conveniently try new
improvements abd features that are developed, by building from the
"experimental" repo. I think TW already said it's no problem to let
multiple people access a repo within his hosting.

What is sacrificed is the strictly linear chain of patches, but I
think that mercurial is well suited to cope with merges.

comments?

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz