[Development] Branches and time based releases

[Oswald Buddenhagen]

On Tue, Feb 25, 2014 at 03:15:58PM -0800, Thiago Macieira wrote:
> Em ter 25 fev 2014, às 22:06:44, Oswald Buddenhagen escreveu:
> > > >  A--B--C--D--E--F--> 5.3
> > > >      \--C'--F'  ^ shadow/v5.2
> > > >             ^ v5.2
> > > [...]
> 
> So let's agree not to implement this one?
>
ack

> > 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:
> 
right, the use cases for describing HEAD and older commits are typically
quite different.
to make it work with unmerged tags, it would have to automatically find
the merge-bases with the branches leading to all tags, producing
something like v5.3--100-70-g1234fee.
anyway ...

> > > > we can give them a prefix, like forks/v5.2.0. still twice as many
> > > > tags, but not really confusing.
> > > 
> > 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:
> 
> We're talking about an 84% increase in the number of tags
>
as the complexity is not a linear function of the tag count, that
doesn't count.

> and an addition to workflow that wouldn't otherwise be needed.
> 
that's a more relevant consideration, but it is not directly related to
the number of tags.

anyway ...

> > 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?
> 
it's not always that easy. i typically end up looking at surrounding
commits, sometimes need to jump branches (because the commits are
duplicated), etc., and end up thoroughly confused.

> Right, I think the duplication is the core issue here.
>
exactly

> If we have proper re- targetting from Gerrit 2.8, this should not be
> an issue for releases.
> 
yes. i wouldn't like to make that a precondition, though.

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

to sum up: we agree with lars' proposal, except on this point. lars,
feel like changing your mind?

the next question would be how we proceed with implementing the change.
i guess branching off 5.3 from stable and merging stable for the time
being would be the best approach. retroactively creating the other
branches (including dismantling release) is less important.
the question is how quickly QA can set up the CI to match the new
requirements (and ensure that future branching won't be a major PITA).
we obviously shouldn't endanger the 5.3 release cycle, but *some*
release is always in preparation, so just holding off doesn't buy us
anything.

> > > 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.
> 
we have already established that this is not how most people work. you
can do that only because you have a pretty good overview of what is
happening in your module, and your work is mostly orthogonal to
everything else going on.
also, suggesting that the branch that the initial clone checks out will
really determine what branch a thoughtful contributor targets is ...
kinda far-fetched.

> > > 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.
> 
you will always have that in some way, no matter what initial branch
you "force" on the people. it really doesn't get easier than having a
canned response in form of an authoritative link.

> 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.
> 
i so totally do not care about the out-of-the-box experience of git
clones for *users* who don't even bother talking with anyone. they are
not the target audience of this infrastructure, and optimizing for them
is totally pointless.
when i ask somebody to try a recent revision from git (typically in a
bug report), i always name the branch as well, as that's the only way to
be reasonably safe, irrespective of defaults.