[Development] Branches and time based releases

[Oswald Buddenhagen]

On Tue, Feb 25, 2014 at 11:28:46AM -0800, Thiago Macieira wrote:
> 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.
> 
we already established that merging from dev to stable is simply not
working due to revdeps (which are a good thing in principle, see other
thread). that's why it is forward merging + fast-forward downwards. to
ensure the fast-forward, stable would need to be locked.

> 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.
> 
good. i'm also just clarifying that you are still wrong, despite this
being irrelevant now. :P

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

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

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