Open Stack

> 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