[Development] Branches and time based releases

[Oswald Buddenhagen]

On Mon, Feb 24, 2014 at 02:22:49PM -0800, Thiago Macieira wrote:
> Em seg 24 fev 2014, às 21:11:47, Knoll Lars escreveu:
> > * We have one dev branch for all new development
> 
> I.e., nothing changes. I propose this branch stay named "dev", for clarity of 
> purpose, not "master".
> 
i don't think the clarity buys us much. like the rest of the branch
naming stuff, it is really a minor detail for the average contributor.
otoh, the deviation from the default leads to *every* project so far
having to rename their master branch upon promotion to being an official
part of qt.
so i would actually vote for switching back to the master name (though
keep merging dev for a while, so we don't have to re-target hundreds of
changes again). this isn't a very strong preference, though.

> > * After creating the branch for a new minor release we do a forward merge
> > from the previous branch before creating the alpha. The advantage here is
> > that the forward merge is something we know how to handle (it’s done on a
> > rather regular basis), and we then know we have all changes from the
> > previous patch level release in the new release.
> 
> My objection here is that the merging is not the problem. We still need to get 
> changes through the CI and *that* is currently the problem.
> 
it remains a problem for the release (though still smaller than now). we
solve the problem for the development (no need to lock down the "new"
branch for days).

> I still feel we're solving the wrong problem. Or, we can say we're
> working around the problem because really solving it is not within our
> means right now.
> 
even if we could optimize CI to the point where a forward-merge would
reliably go through in half an hour (which i think is a realistic target
when we actually concentrate on that, but we likely won't get there
within the next months), we still have a) that half-hour lockdown which
is weird in itself and b) the administrative overhead of implementing
the lockdown (fiddling with gerrit permissions).
so even in the optimal case, branching would be *still* cleaner than
downmerging.

> > * To create the actual patch level releases (5.x.y), I would propose that
> > we create a short-lived branch from 5.x. That branch gets tested, but no
> > patches get directly committed to it (as opposed to the release branch we
> > have today). Instead I would propose that the release team creates a list
> > of P0 bugs that still have to be fixed before we can fix 5.x.y. Fixes for
> > these bugs get pushed to 5.x and cherry-picked to 5.x.y by the release
> > team. Like that we can control in a better way what goes into the final
> > release and no developer has to deal with a release branch. It should also
> > reduce the risk that other changes go in that again break qt5.git CI or
> > have other negative side effects.
> 
probably not unexpectedly, i don't like that.
thiago insists on the forward merge, and all other things being equal,
the number of commits wouldn't go down, so we would arrive at a
significant number of duplicated commits.

the crucial point is policy enforcement, i.e., the release team being
much stricter about what gets staged. but we have a problem here: the
fact that we repeatedly were about to release alpha quality software
(and sometimes did) makes it pretty much unavoidable that numerous
changes are being made until the last moment.

when that is fixed, the number of commits goes down to a point where it
doesn't matter whether we are cherry picking (only few duplicate
commits) or continue to push directly to the release branch (few people
are concerned with it anyway). all things being equal, i'd still prefer
fewer cherry-picks, i.e., the latter.

note that there is an alternative to the forward merge that thiago at
least didn't reject outright last time i proposed it: create a shadow
tag on the stable branch which marks the last commit that went into a
particular release (but obviously also already contains commits that
were not released at that time). that would make the cherry-pick
solution more palatable.

>  * The Git repository's HEAD continues to point to the current "stable" 
> release. The fact that we're changing the names of the branches does not 
> invalidate the reason why we chose HEAD to point to "stable" back in 2011: 
> people should be presented with the most currently relevant yet stable release 
> available when they clone the repository. And given 2½ years of experience on 
> this, I can confidently say that this is also the this is the branch that most 
> of our developers spend time on.
> 
i would argue that this is one of the branch-related things that really
don't matter for the vast majority of contributors. a reasonable
developer makes a conscious decision about his target branch rather than
cloning and just hacking away.

> That means when we create 5.x from dev, someone needs to go and update
> all the Gerrit and Gitorious repositories' HEAD.
> 
only if you volunteer to either do that yourself, or write (and
maintain) a http client script that reliably does it for us.

> > (In addition gerrit 2.8 will then finally solve this by allowing
> > to retarget a change)
> 
> Any ETA on when we can expect 2.8?
> 
ismo would have to comment on that. given the bug sean pointed out, we
may need to forward-port again before we deploy (or we find the fix and
cherry-pick it into 2.7).

> Though, to be honest, as long as 5.x is not closed, we can and should always 
> just push bugfixes to 5.x, even if 5.y (y > x) is already open.
> 
yes, with increasingly stricter requirements, obviously.