stable repo

[John W. Eaton]

On 24-Apr-2009, Jaroslav Hajek wrote:

| so, what now? For convenience, I'll summarize my proposal once more:
| We'll essentially have two main development repos of different speed
| that will occassionally be synchronized (by merging, though this can
| still be discussed).
| 
| Bug-fixing will primarily occur in stable repo and releases will be
| forked from it. The stable repo will enter a "feature freeze" state
| when a release is due to happen,
| otherwise it will occassionally pull the new stuff from main.
| Development of new features, improvements etc. will happen in main
| repo, which will be unaffected by "feature freeze".

I'm still trying to figure out how this will work.  The model used by
GCC makes more sense to me.  Releases are made from the main
development version.  When (or just before) a release, a branch is
created for the stable release (say 3.2.0).  Eventually, at the end of
the lifetime for the 3.2.x release series, that branch becomes
inactive.  Development looks like this:

  http://gcc.gnu.org/develop.html#timeline

After a branch, the release series typically don't see many changes
because changes in a release series are only supposed to fix
regressions.

Development in the main archive takes place in stages, as described
here, http://gcc.gnu.org/develop.html, under the heading "Stages".  To
summarize, the three stages are:

  stage 1: anything goes; this is the time to merge large new features
           or do other major restructuring.  In Octave, this would be
           things like rewriting the symbol table to add support for
           classes

  stage 2: only smaller changes and bug fixes

  stage 3: bug fixes or documentation changes only, no new features

The goal is to have each stage last for approximately two months, so
releases can happen every 6 months or so.  We might tweak the
durations somewhat, though aiming for two months for each stage
doesn't seem unreasonable to me.

In addition, development of crazy new features takes place on branches
in the main archive, though for Octave I would propose that we use
separate archives for experimentation, and they could be hosted
anywhere.  Even when the main development tree is in stage 2 or 3,
major developments may still be taking place in other archives.
Changes from those archives can be merged when mainline enters stage 1
again.  Feature freezes don't last too long

What you're describing for the stable archive sounds sort of like the
GCC model, with the "main" archive taking on (more or less) the role
of the experimental branches.

I guess I don't see why we need the main (experimental) archive to be
on savannah, or, if it is hosted there, why we would want to restrict
ourselves to just one experimental archive.

If there is an "anything goes" attitude toward the main archive, then
how does pulling and merging from main to stable help us generate
high-quality stable releases?  I mean, if you pull every change from
main, then aren't you likely to get some half-baked things in the
stable archive that will cause trouble for a release?  I don't see how
this helps us much.  I think the important thing is that we (myself
included) need to be more careful about what we put into the public
archive so that the changes that are added are not too disruptive.
But if you want to improve the quality of the stable archive, you
can't just periodically pull everything from main into stable, can
you?  Or if that is what you plan to do, then we also have to somehow
ensure that changes applied to the main archive are fully baked when
the merge happens.  But that sort of defeats what I think is your
intention for the main archive, because it seems you'd need some sort
of feature freeze in the main archive before you could do a merge.

Sorry if I'm being dense here and missing some point about how you
intend this to work.  My goal is not to make it unnecessarily
difficult for people to contribute changes.  What I'm hoping for is to
find a good way to enable us to make more frequent higher quality
releases.

jwe