[Development] Branches and time based releases

Thiago Macieira thiago.macieira at intel.com
Tue Feb 25 23:57:00 CET 2014


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:


> 
> > > > 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, [...]
> 
> during the lockdown we could simply direct-push the bump. the risk that
> something goes wrong with that at this point is virtually non-existing.
> but anyway ... irrelevant.
> 
> > > > 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.
> 
> > > > 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.
> 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).
> 
> > 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.
> 
> funny thing you are saying that, because for the "normal" (not
> release-bound) research workflow, choosing the picked version would be
> the worse outcome.
> 
> i think this allows only one conclusion: merged cherry-picks (and
> reverts) are bad, and should be avoided if at all possible.
> 
> 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).
> 
> > > > 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.
> 
> > 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.
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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




More information about the Development mailing list