[Development] RFC: What constitutes a "non-destabilising" bug-fix?

[Thiago Macieira]

On sábado, 8 de dezembro de 2012 09.53.44, Alan Alpert wrote:
> This thing about the non-destabilizing bug fixes is just the release
> team being cautious because we don't have a release branch yet.
> Theoretically I'd have thought the release branch should have started
> for RC1 and then the release team would cherry-pick fixes into that
> branch. But if that's not happening then we just have the same work
> flow as in 4.x when there was only one master: be cautious with
> commits around release time. The only reason this might be perceived
> as a regression is that we actually have another branch that won't get
> into the release, allowing development to continue like we had always
> dreamed of.
> 
> So it seems we're currently only half-way over into our new branching
> paradigm and that will be confusing until we shift fully. Unless I got
> the new paradigm wrong, in which case it's confusing now  .

No, you didn't.

I discussed this with Lars and Tuukka yesterday before leaving for the 
airport. We discussed whether we should branch now at RC1, wait until RC2 or 
even longer. There are good arguments in both directions:

 - if we don't branch now, we risk destabilising changes going in, changes 
that should be kept back.
 - what's more, if we don't branch now, there's nowhere to put important bug 
fixes that just need a little more testing (i.e., the ones for 5.0.1)

 - however, if we do branch now, we create work for the release team for 
cherry-picking the important fixes or redirecting to the release branch.

So we discussed a judgement call: to us, it looked like we'll need a lot of 
necessary fixes on top of RC1 -- some of which we already know, which is why 
we're certain there will be an RC2. If we branch now, we create a lot of 
additional work. The risk of a regressing change being accepted is worth the 
gain in workflow.

We'll create the releases branch for the RC2 then.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121208/6e734a10/attachment.sig>