[Development] Branches and time based releases

[Oswald Buddenhagen]

On Tue, Feb 25, 2014 at 09:40:36AM -0800, Thiago Macieira wrote:
> Em ter 25 fev 2014, às 11:33:00, Oswald Buddenhagen escreveu:
> > > I.e., nothing changes. I propose this branch stay named "dev", for clarity
> > > of purpose, not "master".
> > 
> > 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.
> 
> They should instead start with a branch called "dev". That means there's no 
> renaming necessary later on.
> 
yes.
but as matthew says, it's counterproductive to start with.

> > > 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.
> > 
> > [...] so even in the optimal case, branching would be *still* cleaner than
> > downmerging.
> 
> If it passes reliably within half an hour, no lockdown is necessary. The 
> lockdown is only necessary today so the people doing the merging don't have to 
> tear their hair out to keep track of two moving targets.
> 
eh?
the merging goes from stable to dev, then a fast-forward to stable.
from before the start of the merge, through the integration in dev, to the
push, stable must be frozen. and the actual start would be delayed if an
integration was already going on on stable. so we are still talking
about an hour lockdown time on stable.

> > 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.
> 
> I'm fine with that, as long as I can check out the tag and get the actual 
> contents of the release. Very often, when looking at bugs or other issues, 
> I'll do git show v5.x.y:src/corelib/foo/bar.cpp and see if the issue was 
> already there.
> 
you don't need a merged back tag for that.

an actually useful case is git describe --contains.

> But I think you're suggesting something like this:
> 
> A--B--C--D--> 5.3
>     \--E--F
> 
no, i'm suggesting this:

 A--B--C--D--E--F--> 5.3
     \--C'--F'  ^ shadow/v5.2
            ^ v5.2

> If F is tagged v5.3.1, then B is tagged "branchpoint-5.3.1". That means D gets 
> described as "branchpoint-5.3.1-2-gXXXXXX".
> 
well, that's certainly cleaner than my proposal (much less arbitrary
result).
but then, to get this, on can simply use git merge-base.

> Maybe it could be tagged "branchpoint-5.3.2". Maybe instead C should be the 
> "Bump version" commit and be tagged.
> 
we could even guarantee that the version bump is the first commit - we are
during source branch lockdown at the time anyway.
but tagging that commit seems unnecessarily complex anyway.

> I dislike duplicating the number of tags in the repository. It will
> create confusion.
>
we can give them a prefix, like forks/v5.2.0. still twice as many
tags, but not really confusing.

> So I would prefer the merge back, since the duplication of commits
> doesn't cause confusion, regardless of the number of them.
> 
when looking at a simple git log (or even worse a bit blame if you are
unlucky), merged cherry-picks are always confusing, even if properly
marked. the only worse thing is cherry-picks mixed with reverts.

> > 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.
> 
> And I would argue the opposite.
> 
> A reasonable developer is not what you get in the #qt channel.
>
this is not an audience to optimize *our* repositories for.
make a wiki page Building-Qt5-From-Git-For-Users and hand that out
whenever somebody botches a git build, without further words.