Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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?

> 
> 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> 
>>> wrote:
>>> 
>>> 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
>>>> schedule.
>>>> 
>>>> 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.
> 
>> --Morgan 
>> _____________________________________________________________________
_
>
>> 
____
> 
> 
> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>> 
> 
> ______________________________________________________________________
____
>
> 
OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVgZcEAAoJEC5aWaUY1u57x48H/AoKa+BniRQ/9TFUAmeHb6JL
KYtB0uAdXr1LUuY2n3vcMfyU03wayhh4syJ9R/8szBgt4yvkHBh+ZL7QdLHvS4bP
FzF6RKIo0Xy1kMYlagEDIANPx+BLidHBBRcw7dVxJuGI1zhoWm6bSOBYcTFKgFrx
U5PU3s2G6CL+rmbXZZjN/wfGCqYKFH7QWf3MnXixmhxn6ymSbbxjleJKFYaksTYR
F0fN/6JIntjk94I6D9tPm9Gll7691EKIyrFhZDosFohUa+EZ3oUSn66tdwkViIEy
MR9OlQB1RuJ33pIojBpXB3niKeXhLsWZOjRlAfjMZIIkqFPQ9u4ZKDxDxn/Q/C4=
=Df5z
-----END PGP SIGNATURE-----