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 <amot...@gmail.com
<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
<https://docs.openstack.org/developer/pbr/#version>
2017-04-05 10:36 GMT+09:00 Emilien Macchi <emil...@redhat.com
<mailto:emil...@redhat.com>>:
> adding [all] for more visibility... See comments inline:
>
> On Tue, Mar 21, 2017 at 2:02 PM, Emilien Macchi
<emil...@redhat.com <mailto:emil...@redhat.com>> wrote:
>> On Mon, Mar 13, 2017 at 12:29 PM, Alan Pevec <ape...@gmail.com
<mailto:ape...@gmail.com>> wrote:
>>> 2017-03-09 14:58 GMT+01:00 Jeremy Stanley <fu...@yuggoth.org
<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
<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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>>>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<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
