Clay, So the moral of the story is to "pay attention to what's happening around you"? or something else?
Thanks, Dims On Wed, Apr 5, 2017 at 12:55 PM, Clay Gerrard <[email protected]> wrote: > I hate this stuff. > > Not just pbr (tho I do have a long history of being kicked in the nuts by > pbr for no good reason I can ascertain). But when suddenly some process > OpenStack invented I've never *heard of in two years* breaks - and overnight > me and 100's of other folks have to stop what their doing to read up on some > esoteric thing they never bought into. > > https://blueprints.launchpad.net/pbr/+spec/pbr-semver > https://review.openstack.org/#/c/108270/ > > "My use-case is to pretend every commit is a release. And since I can't > expect you're going to manage something as complicated as your projects > *version* in between releases (obvs.). Only possible solution is a new > esoteric procedure no one as ever heard of baked into your commit messages." > > What could go wrong? > > This in all my package build infrastructure *so hard*: > > # Shut up, pbr, we know what we're doing > export PBR_VERSION="$DOWNSTREAM_VERSION" > > As long as that doesn't break - I should probably just +2 the thing and go > back to keeping my mouth shut. But ... why after 2 years of blissful > ignorance do I have to suddenly care about this nonsense? I'm grepping git > logs from Nova, Cinder, Keystone, Swift - what am I missing - who's using > this!? > > Please forgive my obviously frustrated tone - I do understand form the spec > and reviews that folks have over time put a lot of thought into this and I'm > not going to fully understand it in an hour of cursory glance. Which is... > kinda of why I'm frustrated. This stuff is maddness and it's in my way. > > -Clay > > On Wed, Apr 5, 2017 at 9:08 AM, Akihiro Motoki <[email protected]> wrote: >> >> I see Emilien proposed a number of patches to individual projects with >> "Sem-Ver: api-break" in the commit message. >> As far as I understand the pbr documentation [1] correctly (see the >> forth paragraph in the section) which is pointed by Emilien, >> the change looks reasonable. >> >> Honestly it would be great if we have a green signal for the similar >> change as a community >> as not all developers are familiar with this kind of changes. >> >> Can all developers get the green signal for the similar change? >> >> Akihiro >> >> [1] https://docs.openstack.org/developer/pbr/#version >> >> >> 2017-04-05 10:36 GMT+09:00 Emilien Macchi <[email protected]>: >> > adding [all] for more visibility... See comments inline: >> > >> > On Tue, Mar 21, 2017 at 2:02 PM, Emilien Macchi <[email protected]> >> > wrote: >> >> On Mon, Mar 13, 2017 at 12:29 PM, Alan Pevec <[email protected]> wrote: >> >>> 2017-03-09 14:58 GMT+01:00 Jeremy Stanley <[email protected]>: >> >>>> In the past we addressed this by automatically merging the release >> >>>> tag back into master, but we stopped doing that a cycle ago because >> >>>> it complicated release note generation. >> >>> >> >>> Also this was including RC >= 2 and final tags so as soon as the first >> >>> stable maintenance version was released, master was again lower >> >>> version. >> >> >> >> topic sounds staled. >> >> Alan, do we have an ETA on the RDO workaround? >> > >> > Without progress on RDO tooling and the difficulty of implementing it, >> > I went ahead and proposed a semver bump for some projects: >> > >> > https://review.openstack.org/#/q/topic:sem-ver/pike >> > >> > Except for Swift where I don't know if they'll bump X, I proposed to >> > bump Y. >> > For all other projects, I bumped X as they did from Newton to Ocata. >> > (where version is X.Y.Z). >> > >> > Please give any feedback on the reviews if you prefer another kind of >> > bump. >> > Thanks for reviewing that asap, so TripleO CI can test upgrades from >> > Ocata to Pike soon. >> > >> > Thanks, >> > >> >> Thanks, >> >> >> >>> Cheers, >> >>> Alan >> >>> >> >>> >> >>> __________________________________________________________________________ >> >>> OpenStack Development Mailing List (not for usage questions) >> >>> Unsubscribe: >> >>> [email protected]?subject:unsubscribe >> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> >> >> >> -- >> >> Emilien Macchi >> > >> > >> > >> > -- >> > Emilien Macchi >> > >> > >> > __________________________________________________________________________ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: >> > [email protected]?subject:unsubscribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
