[Development] Branches and time based releases

[Ziller Eike]

On Feb 25, 2014, at 6:40 PM, Thiago Macieira <thiago.macieira at intel.com> wrote:

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

Maybe they did not follow “some wiki page”, but
http://qt-project.org/wiki/Building_Qt_5_from_Git ?
Because that is exactly what is written there, and that page is really our reference page on how to build Qt5 from git.
It also explicitly states “git checkout stable”, btw.

> 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
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B