Re: stable vs. experimental archive

[John W. Eaton]

On 22-Apr-2009, Jaroslav Hajek wrote:

| Given the apparently somewhat less active developer base of Octave, I
| think we can aim for something a bit simpler, and maybe more
| collaborative.
| Let's just have "main" and "stable", with all active developers having
| access to both "main" and "stable".
| 
| When someone fixes a bug, he pushes the fix to "stable". When he/she
| makes a new feature, improvement or whatever, he pushes it to "main".
| If it's highly experimental, he'll develop it in a separate repo, and
| then it will be merged (for big projects) or rebased in main.
| "Main" will often pull from "stable" and merge, to get the bugfixes.
| Anyone is allowed to do it any time.
| Once per time, stable will pull from "main" and merge, to get new
| features once they become somewhat tested and agreed upon. This should
| happen only after discussion.
| 
| >  Bugfixes are pushed to -stable, then pulled and merged to
| >  mainline. No new features are going to stable, mainline is pushed to
| >  stable after each release.
| 
| OK, that matches my model above.

I'm not sure how well this will work in practice for us.  I posted it
as a possibility, without really thinking about it too much.  Some
problems I see with it are things like

  A major change in the main branch (like the symbol table changes I
  applied after 3.0, or the recent switch to a tree-walker
  interpreter) will mean that a bug in those parts of Octave will need
  to be fixed in completely different ways in the two branches.  So
  pulling and merging will not be trivial in those cases.

  Without some discipline in what is added to the main branch, we will
  still be in a state where what is in the main archive can't be
  released.

I think I would prefer the following structure, which is mostly like
what we have now:

  A set of experimental archives that can be used for doing whatever.
  I don't care who hosts these, but we can link to them on a
  developers page on the Octave web site.  Although links for these
  may appear on the Octave web site, these archives are not "official"
  Octave project archives.

  A main development archive.  Releases are made from this archive.
  Periodically, we have feature freezes, which should not last too
  long, but are necessary to stabilize for release.  Changes to this
  archive should only be patches that are relatively safe, or have
  been fairly well tested.  We should try to keep this in a state
  such that releases are possible most any time, or at least with only
  a short feature freeze period.

  A stable branch for the current stable release.  The only changes
  that should be applied are for regressions or documentation errors.
  These branches may be kept as internal branches of the main archive
  instead of being separate archives (if we choose that, then I guess
  I would like to reattach your 3.0.x branch into the main archive on
  savannah).

The main change here is elevating the awareness of other experimental
archives, and using them for the real development work.  It's up to
the people working with those archives to synchronize with main, and
to export patches for the main archive that will apply cleanly.  I
know this will be slightly more work than just pulling from other
archives, but I would really prefer keeping the main archive history
relatively uncluttered, primarily because then it is easier for me to
see that the changes that are going in are ones that we actually want,
that they don't include some extra experimental baggage, and that they
don't have unintended consequences (like wiping out someone's previous
changes).  If I just pull from some other archive, how am I to know
that I'm not picking up some extra garbage along with the changes I
want?

If you think that requiring a relatively clean history is a bad idea,
can you explain why having a cluttered history in the main archive is
a good thing?  I just don't see it.  Faster, wilder development in the
primary public archive is not necessarily a good thing.

| > If we have other archives that are used for experimental features,
| > then I think we have a better chance of keeping the main archive in a
| > state that can be released at almost any time.  But doing that
| > requires some discipline, and not just pulling in random changes from
| > experimental archives as soon as they have been committed.
| 
| Yes. Every main -> stable pull must be announced and discussed.
| stable -> main pulls are allowed any time.

Do stable -> main pulls always make sense?  We tend to have situtions
like the symbol table or interpreter changes that cause the two
branches to diverge.  It seems to me that pulling would not be
appropriate in those cases.

jwe