-----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 <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 > >> > > ______________________________________________________________________ ____ > > 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 > -----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----- __________________________________________________________________________ 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
