[Development] Branches and time based releases

[Thiago Macieira]

Em ter 25 fev 2014, às 11:33:00, Oswald Buddenhagen escreveu:
> > I.e., nothing changes. I propose this branch stay named "dev", for clarity
> > of purpose, not "master".
> 
> i don't think the clarity buys us much. like the rest of the branch
> naming stuff, it is really a minor detail for the average contributor.
> otoh, the deviation from the default leads to *every* project so far
> having to rename their master branch upon promotion to being an official
> part of qt.

They should instead start with a branch called "dev". That means there's no 
renaming necessary later on.

It equally solves the problem.

> > I still feel we're solving the wrong problem. Or, we can say we're
> > working around the problem because really solving it is not within our
> > means right now.
> 
> even if we could optimize CI to the point where a forward-merge would
> reliably go through in half an hour (which i think is a realistic target
> when we actually concentrate on that, but we likely won't get there
> within the next months), we still have a) that half-hour lockdown which
> is weird in itself and b) the administrative overhead of implementing
> the lockdown (fiddling with gerrit permissions).
> so even in the optimal case, branching would be *still* cleaner than
> downmerging.

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.

If Δt tends to 0, Δchanges also tends to zero, which means it's effectively 
frozen in time.

Also, we don't need to pass within half an hour. We just need to pass on the 
first try.

> probably not unexpectedly, i don't like that.
> thiago insists on the forward merge, and all other things being equal,
> the number of commits wouldn't go down, so we would arrive at a
> significant number of duplicated commits.

I really insist that the tag is part of the past history.

> note that there is an alternative to the forward merge that thiago at
> least didn't reject outright last time i proposed it: create a shadow
> tag on the stable branch which marks the last commit that went into a
> particular release (but obviously also already contains commits that
> were not released at that time). that would make the cherry-pick
> solution more palatable.

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.

But I think you're suggesting something like this:

A--B--C--D--> 5.3
    \--E--F

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

Maybe it could be tagged "branchpoint-5.3.2". Maybe instead C should be the 
"Bump version" commit and be tagged.

I dislike duplicating the number of tags in the repository. It will create 
confusion. So I would prefer the merge back, since the duplication of commits 
doesn't cause confusion, regardless of the number of them.

> > release. The fact that we're changing the names of the branches does not
> > invalidate the reason why we chose HEAD to point to "stable" back in 2011:
> > people should be presented with the most currently relevant yet stable
> > release available when they clone the repository. And given 2½ years of
> > experience on this, I can confidently say that this is also the this is
> > the branch that most of our developers spend time on.
> 
> 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. There are lots 
of people checking out Git repositories and building their own Qt, without 
really understanding what they're doing. In the past two weeks or so, I've 
caught a lot of non-contributors building with -developer-build without 
understanding what it did, just because they found that in some wiki page.

> > That means when we create 5.x from dev, someone needs to go and update
> > all the Gerrit and Gitorious repositories' HEAD.
> 
> only if you volunteer to either do that yourself, or write (and
> maintain) a http client script that reliably does it for us.

I'm not the one proposing the branch name change. The people proposing that 
should take into account the work required to keep this working in their 
proposal and plan accordingly.

Now, if all they require is a script making a few HTTP REST calls, I can help.

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