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

[Thomas Weber]

On Thu, Apr 16, 2009 at 09:19:14AM +0200, Jaroslav Hajek wrote:
> 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.

That would be possible. 

That said, I don't agree this is good. If the main development happens
in the "experimental" archive, it should be hosted on octave.org or
gnu.org, next to the current archive.

        Thomas