Re: stable vs. experimental archive

[Jaroslav Hajek]

On Tue, Apr 21, 2009 at 10:27 PM, John W. Eaton <address@hidden> wrote:
> 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.

OK, I'll ask. I hoped you will do it, given that you're the admin. But
maybe that's not a real reason.

> | 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
>

Agreed. I take 2. back, it seems not to solve the problem I wanted to solve.

> | 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.
>

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.


> 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.

No problem, but no need to have them on savannah, I think.

> 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.

Agreed.

> 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.

> 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?

I think that some changes are rebased on pull (see hg rebase and pull
--rebase). It's roughly the equivalent of converting new changeset to
mq, then qpush and qfin them in turn. Still, rebasing large changeset
sequences can be painful, I think we should allow merging at least
stable & main, and perhaps (in the future) other fixed set of repos
(if we decide to create something like
"crew").

> 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.

Yes.

> 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
>

OK. I have no problem with that; still, I think that it would be nice
to have the two primary (main and stable) archives on savannah. I'll
ask whether it's possible.


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