Open Stack

On 17 June 2015 at 17:19, Thierry Carrez <thierry at openstack.org> wrote:
> Ihar Hrachyshka wrote:
>> On 06/17/2015 05:40 PM, Douglas Mendizábal wrote:
>>> I tend to agree with Thomas that plan D is not ideal.  For one, it
>>> prevents changes to the stable branch that span multiple CRs, since
>>> a two patch change would generate two tags and there would be no
>>> clear indication that the first patch should not be released on its
>>> own.
>>
>> If we will end up with a half-broken product due to merging a patch
>> without another one, then those patches should be squashed. Also, I
>> wonder how they will pass gate if something is broken. Do you suggest
>> that test coverage is incomplete?
>
> Also remember we are talking about *stable branches* here. The only
> acceptable things there are bugfix backports and CVE fixes. So:
>
> - there is no case of partially-merged features that span multiple CRs
> - in the rare case of a bugfix needing multiple commits, those should be
> squashed in the stable branch
> - if the fix is so huge that it can't be merged as a single patch, it's
> probably not desirable in the stable branch
>
> The stable branch should always be usable and releaseable. If it's not,
> you're doing it wrong.
>

Just to add to this, we have a decent demonstrable history of
squashing commits together that have been required to land
concurrently.  We need to do this when the Gate is wedged, and
requires two or more concurrent backports to unwedge.

Such as: https://review.openstack.org/#/c/163378/

As Ihar points out, the test coverage mandates that we do this.. which
nicely helps us provide some assurance that the branch is constantly
releasable.

--
Kind Regards,
Dave Walker