> On Jun 16, 2015, at 14:56, Thomas Goirand <z...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
