[Development] Branches and time based releases

[Knoll Lars]

On 27/02/14 11:28, "Oswald Buddenhagen" <oswald.buddenhagen at digia.com>
wrote:
>
>> > 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?

Ok, let’s try it and see what happens. We can always adjust as we go
forward.

Most other projects do however cherry-pick into their releases (that’s
also what linux distributions do when they add patches to their packages).
I still feel that this would make releasing easier, and I’m not sure the
few duplicated commit would be a real issue in practice. Finding out
whether something is part of a certain release could e.g. just as well be
done on the gerrit tag instead of the git sha1.

>
>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 think we’re through the merge hazzle with stable now, so I’d keep that
branch until 5.3.0. Once we have 5.3.0 out, let’s aim for renaming stable
to 5.3 and move over to that. We should probably also retroactively create
the 5.0 - 5.2 branches so we have something consistent.

Cheers,
Lars

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