Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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.

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.

- - 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
> 
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVgZTgAAoJEB7Z2EQgmLX7qhkP/RwB4sJU2nXeAe4M27VXT/9t
tPD3j0njOMuL6T5g41D/aXIcEvvk1RqjJOg+VdXq7Os3t0AAHNkKng85qGKp+Our
xMOSGBtFjqQycDDVEFrltYCkhmDdmsVw4SWd0zmJ2MHzn+R014lZL5SdsHjhWmRr
c3NfZH0Cxm9ujfMbdjsZoF3i6noZsotUZLy5Tu5iW/Kp46syNDfA47Fxya15T54a
LyA3Qqw/C/1Nov89IyS0AA4nv5BzmWGh8+t6rZnC2NQUPVGVnvnpr5KOIadbwqEh
BtLQWaeXDlbJPovCpHnZ9CUwtIZRdYUXoXgdYJVFcBMmDM0NrIWX4+YlJ5rCgdeC
lVkH9HhUfrBSpgh59sh+A7CwvE8J/Q+eUjNe7BeZcqmPA7NWw/EKA9ERys4Z9XBW
kuicx336wF15b7KHVGLwSTPe++r09pTvahd5KInDUOL+1jOqq0kItjr96W19Qgkx
1asHfTt8KvGTPcyWIml75P45Zza3AV5x2SrwdmqTdnKAJdLSppwV6zmj+2ptHBRV
WTX3/S7IwdEM+JOFx984WB9P55XYyiN2PUO7ZovabhdgHplD2UH1da7fIpjIVx8F
lSQk2d8F+TdllUwvfjZs2U2GWxW3NyetmRV7fB4e1fl/t+G4o1TziCMDtV2MMp0m
diEvi++IMybME/cUf4ns
=+2Gi
-----END PGP SIGNATURE-----