Christopher,

Does this

"So the plan for assignment of microversion api numbers is the same as
what we currently do for db migration changes - take the next one
knowing that you may need to rebase if someone else merges before you"

mean that I should put 2.2 in my review for now instead of 2.4?

Other suggestion would be to pack several simultaneously incoming changes into one microversion. Maybe spawn them once a week, or once a couple of weeks, or even with longer period, depending on the amount of incoming changes. For example, wouldn't it be convenient for clients to acquire all of the accumulated changes in one microversion (2.2 as I understand) without needing to understand which one came with what number? To clarify, I'm suggesting to pass reviews for all of the hanging API changes against 2.2 version.

Best regards,
  Alex Levine

On 3/4/15 11:44 AM, Christopher Yeoh wrote:
On Tue, 03 Mar 2015 10:28:34 -0500
Sean Dague <s...@dague.net> wrote:

On 03/03/2015 10:24 AM, Claudiu Belu wrote:
Hello.

I've talked with Christopher Yeoh yesterday and I've asked him
about the microversions and when will they be able to merge. He
said that for now, this commit had to get in before any other
microversions: https://review.openstack.org/#/c/159767/

He also said that he'll double check everything, and if everything
is fine, the first microversions should be getting in soon after.

Best regards,

Claudiu Belu
I just merged that one this morning, so hopefully we can dislodge.

So just before we merged the the keypairs microversion change someone
enabled response schema tests which showed some further problems. They
have now all been fixed but https://review.openstack.org/#/c/161112/
which needs just one more +2. After that the first api change which uses
microversions https://review.openstack.org/#/c/140313/ can merge (has
3 +2's just needs the v2.1 fix first.

________________________________________
From: Alexandre Levine [alev...@cloudscaling.com]
Sent: Tuesday, March 03, 2015 4:22 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] what's the merge plan for
current proposed microversions?

Bump.

I'd really appreciate some answers to the question Sean asked. I
still have the 2.4 in my review (the very one Sean mentioned) but
it seems that it might not be the case.

Best regards,
    Alex Levine

On 3/2/15 2:30 PM, Sean Dague wrote:
This change for the additional attributes for ec2 looks like it's
basically ready to go, except it has the wrong microversion on it
(as they anticipated the other changes landing ahead of them) -
https://review.openstack.org/#/c/155853

What's the plan for merging the outstanding microversions? I
believe we're all conceptually approved on all them, and it's an
important part of actually moving forward on the new API. It seems
like we're in a bit of a holding pattern on all of them right now,
and I'd like to make sure we start merging them this week so that
they have breathing space before the freeze.

So the plan for assignment of microversion api numbers is the same as
what we currently do for db migration changes - take the next one
knowing that you may need to rebase if someone else merges before you.
Other suggestions welcome but will have to follow the requirement that
they always merge in version order.



       -Sean


__________________________________________________________________________
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


__________________________________________________________________________
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

Reply via email to