[Development] Branches and time based releases

[Thiago Macieira]

[sorry for resending; I had a race condition between the left hand pressing 
Ctrl+F1 to switch desktops and the right hand pressing Enter to add 
newlines...]

Em ter 25 fev 2014, às 22:06:44, Oswald Buddenhagen escreveu:
> > > > 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.
> 
> correct. that's why the tag would be a shadow, and not the real thing,
> and it would be an error-prone hack. whether it would still make sense
> would depend on the actual use cases we want to cover.

So let's agree not to implement this one? It's one fewer alternative to 
consider.

> > > > 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".
> > > 
> > > 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.
> 
> correct, "forward" describe would become useless. describe --contains
> would still return useful results, though, and i think that's what is
> more useful in practice (i suspect it's not the default only because
> it's more expensive).

It's not the default because it's not the purpose for which git describe was 
invented. It was invented to describe the current commit:

$ git describe --contains HEAD
fatal: cannot describe '4598d2766a2268923bd45f4d22ebb84c31a23326'

It's used in things like this:
 https://github.com/torvalds/subsurface/blob/master/scripts/get-version#L21
 https://github.com/git/git/blob/master/GIT-VERSION-GEN#L15
 https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/scripts/setlocalversion?id=refs/tags/v3.13.5#n50
 https://codereview.qt-project.org/#patch,sidebyside,671,1,src/corelib/global/version_gen

It stands to reason that the current commit in the majority of cases isn't 
part of a tag yet.

> > > > 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.
> 
> if you have the complexity of 1 and you make it more complex by .05 as a
> trade-off for a useful feature, that seems quite reasonable to me.

I don't see it as .05. Assuming we duplicate every tag except the alphas:

$ git tag | wc -l
19
$ git tag | grep -cv alpha
16

We're talking about an 84% increase in the number of tags and an addition to 
workflow that wouldn't otherwise be needed.

> > > > 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.
> 
> the problem is assembling the topological order in the brain, thus
> enabling a reliable judgement which commit is in which release.

Why would you need to do that if git tag --contains gives you that 
information?

For example, yesterday I had to look up which release had the fix for 
https://bugreports.qt-project.org/browse/QTBUG-37049. I did:

1) git log --author=Stephen src/corelib/arch
  and found the commit: d9fb6e6dbb2b322556d581265da2442e3b91a6a3
2) git tag --contains d9fb6e6dbb2b322556d581265da2442e3b91a6a3

which then told me that 5.1.1 contained the fix. I didn't have to rebuild 
anything in my brain.

> almost nobody is able to visualize the precise graph, especially with
> duplicated/reverted commits (it's kinda indexed by summary, at least in
> my head).

Right, I think the duplication is the core issue here. If we have proper re-
targetting from Gerrit 2.8, this should not be an issue for releases.

> i think this allows only one conclusion: merged cherry-picks (and
> reverts) are bad, and should be avoided if at all possible.

Agreed.

> so to come back to the starting point: i think we should continue to
> target the release branch directly. the burden for the developers isn't
> very big (actually, one can even argue that the burden being there is a
> good thing ... it discourages people from pushing for release), and it
> makes the discussion about merging back irrelevant (because then it is
> both harmless and required).

Agreed.

> > > > 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.
> > 
> > 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.
> 
> you didn't give good reasons for that position, though.

Well, you disagreed with them. In my mind, my reasons are pretty good. They 
support my workflow of developing new features while at the same time testing 
the stable release and avoiding brokenness caused by others in dev.

> > 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.
> 
> i don't buy that argument. laziness/stupidity should not be rewarded in an
> environment that is supposed to be productive. if a nice RTFM link is
> not good enough for somebody, they deserve losing time.

You're not considering the time of people trying to help in #qt. Having to 
repeat ourselves over and over again, even if it's to say RTFM or give a link 
to lmgtfy.com, is tiresome.

My argument here is that contributing developers are fewer and aren't usually 
very lazy, so it's ok for them to read a little more, find wikis and, failing 
all of that, get everything explained in #qt-labs; and that non-contributing 
developers, being the majority, waste precious time of the people helping out 
by having to have things explained over and over again.

Also, don't forget about the people who never come to IRC to ask for help. 
There are probably quite a few of those behind company firewalls who clone Qt 
and never tell us about it. I'd like to make sure they get the most stable 
version by default, when they clone. Better out-of-box experience.

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