Re: stable repo

[Jaroslav Hajek]

On Fri, Apr 24, 2009 at 3:16 PM, John W. Eaton <address@hidden> wrote:
> 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.

The main archive is not supposed to contain half-baked things. If you
discover a bug in a new feature, you just fix it in main. If that
feature has already been pulled into stable, you fix it in stable and
pull the fix to main.
Again: basically the only difference between main and stable archive
should be time. Essentially, everything that is in the main archive
should go to stable. The only difference is that the development in
main is continuous and the stable archive helps to quantize that into
releases.


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

Not periodically. Essentially, in "stage 1" as you called it.

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

Why? The main->stable pull will happen when there's enough time to
stabilize the stable archive, i.e. after a release.
We do the pull, and then people should test the stable archive. Since
my policy states that bugfixes for features already in stable branch
should go to stable branch (and then pulled to main), this will
effectively force me to periodically build and test the stable
archive.

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

I think that GCC (or other) models does not necessarily fit best for us.
Let me put myself as an example:
I often develop small performance improvements that are somewhat chained.
I created cellslices function, which I used in turn to optimize vech
and toeplitz. I extended pascal and used that to implement polyscale
and polytrans, which I later merged to polyaffine. I optimized vander,
extended it and used it inside polyfit.
I think others have discovered one or two bugs in this chain, while
testing the development source.
Now, given that we theoretically have a feature freeze, these changes
should have been committed into my own repo, even though they're
mostly simple. Nobody would probably discover any bugs, then. Further,
that would likely make me play preferably with my experimental repo,
vastly decreasing the probability I can find bugs in others'
contributions.
Since I'll use pull & merges, maybe when we're in stage 1, nobody will
merge my changes because I'll be short of time and others won't be
sure about what's in my repo. So, my changes won't make it in, which
in turn will encourage me more to work with my own fork, because it
contains features I want.
I will synchronize with the main branch, but others won't test my
features and find bugs in them.

I agree with Rik: people will be willing to  build & test two repos,
but not seven, even if they're interested in features from those seven
repos. Also, most people are not really heavily skilled with hg, so
it's best if they can get at new features using just pull & make.


cheers


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