stable vs. experimental archive

[John W. Eaton]

On 21-Apr-2009, Jaroslav Hajek wrote:

| 1. create a secondary "experimental" repo on Savannah (if this can be done)

I don't think this is currently possible on savannah, but you could
ask the admins there if they can make it work.

| 2. create an "experimental" branch in the savannah repo (and maybe
| rename the "default" branch to "stable")

I'd prefer to avoid branches.  It seems simpler to just use seprate
archives.  FWIW, this seems to be what the Mercurial developers do:

  http://www.selenic.com/mercurial/wiki/index.cgi/DeveloperRepos

| 3. host the "experimental" repo elsewhere (TW's)
| X. forget about the stable & experimental proposal, use a different
| development/maintenance model
| 
| could you please share your opinions/votes? if anyone votes for X.,
| please describe your idea.
| 
| I think 1. is clearly winner if it can be done. 2 and 3 are
| compromises. My vote is 2 if 1 is not possible.

What about working in a way that is similar to what the Mercurial
developers do?

They have two primary archives, "main" and "stable":

  The main repository, bleeding edge, solely managed by mpm who often
  pulls from other repositories.

  The stable repository, solely managed by mpm, contains official
  releases with safe and important fixes applied, always a subset of
  the main repository.

  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.

In addition to the two main archives, there are other public archives
managed by groups and individuals that are used for experimenting and
testing out other crazy ideas.  These arechives tend to have more
internal merging and branching.

Note that the two main archives for Mercurial development are solely
managed by one person.  I'm not sure that is best for us, but we could
share the management of the stable and main archives among several
people.

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.

Also note that in the main archive, the changes are more or less
linear.  There are not a lot of spaghetti links in the merges.  How
does that work if the changes are pulled from other archives?  Or are
they really imported patches for which conflicts that require merging
are handled before committing to the main archive?

There is still the problem of divergence between the main and stable
archives.  I think the only solution to that is to make more frequent
releases.

As for where these are hosted, I don't really care, provided that the
public archives are on systems that are likely to be up and on the
net.  The experimental archives for Mercurial (for example) are not
all hosted on the same system but there are links to them on a single
web page, so they are easy to find.

jwe