[openstack-dev] [all] [stable] No longer doing stable point releases
ihrachys at redhat.com
Wed Jun 17 15:49:24 UTC 2015
-----BEGIN PGP SIGNED MESSAGE-----
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
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?
> My preference would be for "Plan C" where the PTL would push a new
> 2015.1.XXX tag when an important fix (or fixes) lands in a stable
> branch .
> I also disagree with Morgan that packagers are better informed to
> make the determination of when to release. PTLs should be aware of
> all changes landing in the stable branches, and should be able to
> push a tag immediately after an important fix lands. Asking the
> packagers to make the determination means that they would have to
> be aware of every patch landing in every project, which I think is
> a lot to ask.
I wouldn't expect e.g. neutron PTL to know every since patch in stable
branches. If anyone, you better put the burden onto corresponding
- -stable-maint team.
> - Douglas Mendizábal
> On 6/17/15 9:55 AM, Morgan Fainberg wrote:
>>> On Jun 16, 2015, at 14:56, Thomas Goirand <zigo at debian.org>
>>> On 06/16/2015 12:06 PM, Thierry Carrez wrote:
>>>>>> It also removes the stupid encouragement to use all
>>>>>> components from the same date. With everything tagged at
>>>>>> the same date, you kinda send the message that those
>>>>>> various things should be used together. With everything
>>>>>> tagged separately, you send te message that you can mix
>>>>>> and match components from stable/* as you see fit. I
>>>>>> mean, it's totally valid to use stable branch components
>>>>>> from various points in time together, since they are all
>>>>>> supposed to work.
>>>>> Though there's now zero guidance at what should be the
>>>>> speed of releasing server packages to our users.
>>>> I really think it should be a distribution decision. You
>>>> could release all commits, release every 2 months, release
>>>> after each CVE, release as-needed when a bug in Debian BTS is
>>>> fixed. I don't see what "guidance" upstream should give,
>>>> apart from enabling all models. Currently we make most models
>>>> more difficult than they should be, to promote an arbitrary
>>>> time-based model. With plan D, we enable all models.
>>> Let me put this in another way: with the plan D, I'll be lost,
>>> and wont ever know when to release a new stable version in
>>> Debian. I don't know better than anyone else. If we had each
>>> upstream project saying individually: "Ok, now we gathered
>>> enough bugfixes so that it's important to get it in downstream
>>> distributions", I'd happily follow this kind of guidance. But
>>> the plan is to just commit bugfixes, and hope that downstream
>>> distros (ie: me in this case) just catch when a new release
>>> worse the effort.
>>>> As pointed elsewhere, plan D assumes we move to generating
>>>> release notes for each commit. So you won't lose track of
>>>> what is fixed in each version. If anything, that will give
>>>> you proper release notes for CVE-fix commits, something you
>>>> didn't have before, since we wouldn't cut a proper point
>>>> release after a CVE fix but on a pre-determined time-based
>>>> Overall, I think even your process stands to benefit from
>>>> the proposed evolution.
>>> I just hope so. If any core / PTL is reading me in this thread,
>>> I would strongly encourage you guys to get in touch and ping
>>> me when you think some commits in the stable release should be
>>> uploaded to Debian. A quick message on IRC can be enough.
>> For what it is worth, I trust the downstream distributions to
>> make this call. I expect that any/all stable patches accepted in
>> a model where release notes are generated per-commit (Plan D)
>> this ends up looking like the Redhat model where patches are
>> bundled in.
>> In general we should have care in accepting a stable patch. But
>> as the PTL (and more generally as a core) asking me to determine
>> when there is "enough patches to generate a release" is far too
>> distribution/packager specific and subjective. I do not expect
>> to be reaching out to each and every one to say "hey did you
>> release?" This, in my opinion is not a reasonable ask. I do not
>> know what justifies "time for a release" for Debian or Redhat or
>> Suse or Gentoo ... Etc. Please do not expect the PTLs and Cores
>> to become experts on each and every one of these. I expect the
>> packager to be making the subjective call in the non-time-based
>> model outlined.
> OpenStack Development Mailing List (not for usage questions)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
OpenStack Development Mailing List (not for usage questions)
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----
More information about the OpenStack-dev