On 2/12/2015 6:55 PM, Michael Still wrote:
This was discussed in the nova meeting this morning. In that meeting
we declared ourselves unwedged and ready to do a release, and I said
I'd do that today.
On reflection, I want to recant just a little -- I think its a bad
idea for me to do a release on a Friday. So, I'll do this early next
week instead.
Michael
On Wed, Feb 11, 2015 at 8:51 AM, Joe Gordon <joe.gord...@gmail.com> wrote:
On Mon, Feb 9, 2015 at 7:55 PM, Michael Still <mi...@stillhq.com> wrote:
The previous policy is that we do a release "when requested" or when a
critical bug fix merges. I don't see any critical fixes awaiting
release, but I am not opposed to a release.
The reason I didn't do this yesterday is that Joe wanted some time to
pin the stable requirements, which I believe he is still working on.
Let's give him some time unless this is urgent.
So to move this forward, lets just pin novaclient on stable branches. so the
longer term pin all the reqs isn't blocking this.
Icehouse already has a cap, so we just need to wait for the juno cap to
land:
https://review.openstack.org/154680
Michael
On Tue, Feb 10, 2015 at 2:45 PM, melanie witt <melwi...@gmail.com> wrote:
On Feb 6, 2015, at 8:17, Matt Riedemann <mrie...@linux.vnet.ibm.com>
wrote:
We haven't done a release of python-novaclient in awhile (2.20.0 was
released on 2014-9-20 before the Juno release).
It looks like there are some important feature adds and bug fixes on
master so we should do a release, specifically to pick up the change for
keystone v3 support [1].
So can this be done now or should this wait until closer to the Kilo
release (library releases are cheap so I don't see why we'd wait).
Thanks for bringing this up -- there are indeed a lot of important
features and fixes on master.
I agree we should do a release as soon as possible, and I don't think
there's any reason to wait until closer to Kilo.
melanie (melwitt)
__________________________________________________________________________
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
--
Rackspace Australia
__________________________________________________________________________
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
This was ready to go as of Monday. Can we really only have the PTL do
this release? As far as I know, any core on python-novaclient should be
able to do this if they have a GPG key to launchpad, then they just need
to push the tagged release per [1]. There is some launchpad bug cleanup
and blueprint stuff to handle which is done in scripts somewhere [2], so
maybe that's what holds this up?
[1] http://docs.openstack.org/infra/manual/drivers.html#tagging-a-release
[2] https://wiki.openstack.org/wiki/ReleaseTeam/How_To_Release
--
Thanks,
Matt Riedemann
__________________________________________________________________________
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
