[Development] Branches and time based releases

[Thiago Macieira]

Em ter 25 fev 2014, às 20:09:41, Oswald Buddenhagen escreveu:
> > 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.

Again, the main issue is passing the CI. If the CI is working reliably and we 
can get stuff done quickly, it doesn't matter that there are more changes.

The merges of the stable branch into the development branch will continue to 
happen periodically. Nothing changes there.

The big question is what happens at feature freeze. If the merging of dev into 
stable were quick and painless, we wouldn't be having this discussion. So my 
point is: we're working around the root problem because we can't fix the root 
problem right now.

I'm no longer disputing the use of branches, after Lars made his decision. I 
just wanted to be clear on what we're actually doing. Let's move on.

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

Right, you don't, but there are certain workflows that will still suffer.

> an actually useful case is git describe --contains.

That's a very good example of a workflow that gets broken.

Another one is trying to blame changes: suppose I do git blame on a file in my 
current branch and I find it's on change C. Then I do git tag --contains C to 
figure out which versions may be affected. This result will offer results from 
partially wrong to completely unusable, depending on which scheme we use.

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

Sorry, this one has a fatal flaw: if F gets tagged, like you show, then it 
would imply that E is also is in that release, which your graph shows it 
isn't.

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

If it isn't merged, yes. But then when I do git describe on the 5.5 branch, it 
will tell me it's v5.2.1 + 10000 commits.

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

Not to mention that it sometimes fails to integrate, like a long-time failing 
test (https://codereview.qt-project.org/78642) or a CI failure 
(https://codereview.qt-project.org/78629).

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

The number of tags creates the confusion, IMHO. You can't argue that having 
them twice is more complex than having them once, all else being equal.

> > 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 don't agree. The git log is more complex, indeed, since it shows the 
duplication, but each duplicated commit has the SHA-1 of the original commit 
so you know what it meant. What's more, it won't show on git blame: blame will 
choose one of the two sides of the merge and display it.

If it chooses the one from the mainline, unfortunately, it will still break my 
workflow above.

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

I'm sorry, but it needs to be.

We can expect contributing developers to be reasonable and execute a few more 
commands to get to the branch they want to be in. Plus, as I said, I truly 
believe that even our devs should land on the currently stable branch at first, 
not the development one.

The non-contributing developers, however, are the vast majority. Writing wiki 
pages isn't enough because people don't find them. It's amazing how many things 
are answered by a simple Google search, yet people don't do them.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center