Open Stack

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 <clay.gerrard at gmail.com> 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 <amotoki at gmail.com> 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 <emilien at redhat.com>:
>> > adding [all] for more visibility... See comments inline:
>> >
>> > On Tue, Mar 21, 2017 at 2:02 PM, Emilien Macchi <emilien at redhat.com>
>> > wrote:
>> >> On Mon, Mar 13, 2017 at 12:29 PM, Alan Pevec <apevec at gmail.com> wrote:
>> >>> 2017-03-09 14:58 GMT+01:00 Jeremy Stanley <fungi at yuggoth.org>:
>> >>>> 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:
>> >>> OpenStack-dev-request at lists.openstack.org?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:
>> > OpenStack-dev-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Davanum Srinivas :: https://twitter.com/dims