Re: [openstack-dev] [all][TripleO][release][deployment] Packaging problems due to branch/release ordering

2017-04-05 Thread Monty Taylor 
The tone of this in inappropriate and not in keeping with our community 
code of conduct:


https://www.openstack.org/legal/community-code-of-conduct/

It is neither friendly, patient, welcoming, considerate or respectful. 
No attempt has been made to collaborate openly on a solution, or to 
understand why there is a disagreement.


There are legitimate issues that can be discussed on this topic, and 
legitimate areas of disagreement that can be explored. I would kindly 
request that in the future you engage with the team to try to understand 
what problem is being solved and if there is any way it could be improved.


I have behaved similarly inappropriately in the past, and it was 
important that I was called out for it.


On 04/05/2017 11:55 AM, Clay Gerrard 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 mailto:amot...@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 mailto:emil...@redhat.com>>:
> adding [all] for more visibility... See comments inline:
>
> On Tue, Mar 21, 2017 at 2:02 PM, Emilien Macchi
mailto:emil...@redhat.com>> wrote:
>> On Mon, Mar 13, 2017 at 12:29 PM, Alan Pevec mailto:ape...@gmail.com>> wrote:
>>> 2017-03-09 14:58 GMT+01:00 Jeremy Stanley mailto:fu...@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-requ...@lists.openstack.org?subject:unsubscribe

>>>

Re: [openstack-dev] [all][TripleO][release][deployment] Packaging problems due to branch/release ordering

2017-04-05 Thread Davanum Srinivas 
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  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  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 :
>> > adding [all] for more visibility... See comments inline:
>> >
>> > On Tue, Mar 21, 2017 at 2:02 PM, Emilien Macchi 
>> > wrote:
>> >> On Mon, Mar 13, 2017 at 12:29 PM, Alan Pevec  wrote:
>> >>> 2017-03-09 14:58 GMT+01:00 Jeremy Stanley :
>>  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-requ...@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-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
>
>
>
> __
> OpenStack Development Mailing List (not for usa

Re: [openstack-dev] [all][TripleO][release][deployment] Packaging problems due to branch/release ordering

2017-04-05 Thread Clay Gerrard 
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  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 :
> > adding [all] for more visibility... See comments inline:
> >
> > On Tue, Mar 21, 2017 at 2:02 PM, Emilien Macchi 
> wrote:
> >> On Mon, Mar 13, 2017 at 12:29 PM, Alan Pevec  wrote:
> >>> 2017-03-09 14:58 GMT+01:00 Jeremy Stanley :
>  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-requ...@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-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
>
__
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

Re: [openstack-dev] [all][TripleO][release][deployment] Packaging problems due to branch/release ordering

2017-04-05 Thread Akihiro Motoki 
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 :
> adding [all] for more visibility... See comments inline:
>
> On Tue, Mar 21, 2017 at 2:02 PM, Emilien Macchi  wrote:
>> On Mon, Mar 13, 2017 at 12:29 PM, Alan Pevec  wrote:
>>> 2017-03-09 14:58 GMT+01:00 Jeremy Stanley :
 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-requ...@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-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

Re: [openstack-dev] [all][TripleO][release][deployment] Packaging problems due to branch/release ordering

2017-04-04 Thread Emilien Macchi 
On Tue, Apr 4, 2017 at 9:36 PM, Emilien Macchi  wrote:
> adding [all] for more visibility... See comments inline:
>
> On Tue, Mar 21, 2017 at 2:02 PM, Emilien Macchi  wrote:
>> On Mon, Mar 13, 2017 at 12:29 PM, Alan Pevec  wrote:
>>> 2017-03-09 14:58 GMT+01:00 Jeremy Stanley :
 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,

I forgot to mention that I didn't update Oslo yet, because I have no
clue which type of bump would be the best now.
Please use this url for review:
https://review.openstack.org/#/q/topic:sem-ver/pike+status:open

Thanks,

>> Thanks,
>>
>>> Cheers,
>>> Alan
>>>
>>> __
>>> 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
>>
>>
>>
>> --
>> Emilien Macchi
>
>
>
> --
> Emilien Macchi



-- 
Emilien Macchi

__
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

Re: [openstack-dev] [all][TripleO][release][deployment] Packaging problems due to branch/release ordering

2017-04-04 Thread Emilien Macchi 
adding [all] for more visibility... See comments inline:

On Tue, Mar 21, 2017 at 2:02 PM, Emilien Macchi  wrote:
> On Mon, Mar 13, 2017 at 12:29 PM, Alan Pevec  wrote:
>> 2017-03-09 14:58 GMT+01:00 Jeremy Stanley :
>>> 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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev