Re: [openstack-dev] [Nova] Tracking Kilo priorities

2014-12-04 Thread Alessandro Pilotti
Hi Michael,

 On 25 Nov 2014, at 02:35, Michael Still mi...@stillhq.com wrote:
 
 On Tue, Nov 25, 2014 at 11:23 AM, Alessandro Pilotti
 apilo...@cloudbasesolutions.com wrote:
 Hi Michael,
 
 On 25 Nov 2014, at 01:57, Michael Still mi...@stillhq.com wrote:
 
 First off, sorry for the slow reply. I was on vacation last week.
 
 The project priority list was produced as part of the design summit,
 and reflects nova's need to pay down technical debt in order to keep
 meeting our users needs. So, whilst driver changes are important, they
 doesn't belong on that etherpad.
 
 That said, I think the best way to help us keep up with our code
 review requirements is to be an active reviewer. I know we say this a
 lot, but many cores optimize for patches which have already been
 reviewed and +1'ed by a non-core. So... Code review even with a +1
 makes a real difference to us being able to keep up.
 
 
 Thanks for your reply, we actually do quite a lot of cross reviews, with the
 general rule being that every patch produced by one of the Hyper-V team 
 members
 needs to be reviewed by at least another two.
 
 The main issue is that reviews get lost at every rebase and keeping track of
 this becomes not trivial when there are a lot of open patches under review,
 mostly interdependent. It's not easy to keep people motivated to do this, but
 we do our best!
 
 This is good news, and I will admit that I don't track the review
 throughput of sub teams in nova.
 
 I feel like focusing on the start of each review chain is useful here.
 If you have the first two reviews in a chain with a couple of +1s on
 them already, then I think that's a reasonable set of reviews to bring
 up at a nova meeting.

For today’s Nova metting, I’d like to propose:

https://review.openstack.org/#/c/129235/
https://review.openstack.org/#/c/136484/

If possible, one of the other patches waiting since a couple of months is:
https://review.openstack.org/#/c/131734/

Thanks,

Alessandro

 I sometimes see a +2 or two on reviews now at
 the beginning of a chain, and that's wasted effort.
 
 Michael
 
 -- 
 Rackspace Australia

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova] Tracking Kilo priorities

2014-12-04 Thread Michael Still
Cool -- I have added these to the agenda.

Michael

On Fri, Dec 5, 2014 at 7:27 AM, Alessandro Pilotti
apilo...@cloudbasesolutions.com wrote:
 Hi Michael,

 On 25 Nov 2014, at 02:35, Michael Still mi...@stillhq.com wrote:

 On Tue, Nov 25, 2014 at 11:23 AM, Alessandro Pilotti
 apilo...@cloudbasesolutions.com wrote:
 Hi Michael,

 On 25 Nov 2014, at 01:57, Michael Still mi...@stillhq.com wrote:

 First off, sorry for the slow reply. I was on vacation last week.

 The project priority list was produced as part of the design summit,
 and reflects nova's need to pay down technical debt in order to keep
 meeting our users needs. So, whilst driver changes are important, they
 doesn't belong on that etherpad.

 That said, I think the best way to help us keep up with our code
 review requirements is to be an active reviewer. I know we say this a
 lot, but many cores optimize for patches which have already been
 reviewed and +1'ed by a non-core. So... Code review even with a +1
 makes a real difference to us being able to keep up.


 Thanks for your reply, we actually do quite a lot of cross reviews, with the
 general rule being that every patch produced by one of the Hyper-V team 
 members
 needs to be reviewed by at least another two.

 The main issue is that reviews get lost at every rebase and keeping track of
 this becomes not trivial when there are a lot of open patches under review,
 mostly interdependent. It's not easy to keep people motivated to do this, 
 but
 we do our best!

 This is good news, and I will admit that I don't track the review
 throughput of sub teams in nova.

 I feel like focusing on the start of each review chain is useful here.
 If you have the first two reviews in a chain with a couple of +1s on
 them already, then I think that's a reasonable set of reviews to bring
 up at a nova meeting.

 For today’s Nova metting, I’d like to propose:

 https://review.openstack.org/#/c/129235/
 https://review.openstack.org/#/c/136484/

 If possible, one of the other patches waiting since a couple of months is:
 https://review.openstack.org/#/c/131734/

 Thanks,

 Alessandro

 I sometimes see a +2 or two on reviews now at
 the beginning of a chain, and that's wasted effort.

 Michael

 --
 Rackspace Australia




-- 
Rackspace Australia

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova] Tracking Kilo priorities

2014-11-24 Thread Michael Still
First off, sorry for the slow reply. I was on vacation last week.

The project priority list was produced as part of the design summit,
and reflects nova's need to pay down technical debt in order to keep
meeting our users needs. So, whilst driver changes are important, they
doesn't belong on that etherpad.

That said, I think the best way to help us keep up with our code
review requirements is to be an active reviewer. I know we say this a
lot, but many cores optimize for patches which have already been
reviewed and +1'ed by a non-core. So... Code review even with a +1
makes a real difference to us being able to keep up.

If you feel a change has been blocking on review for too long and is
important, then please do raise it in the Open Discussion section of
the nova meeting.

Michael

On Sat, Nov 22, 2014 at 2:02 AM, Alessandro Pilotti
apilo...@cloudbasesolutions.com wrote:
 Hi,

 Not seeing any driver (Hyper-V, VMWare, etc) related priority in this etherpad
 worries me a bit.


 My concern is mostly related to the fact that we have in Nova a significative
 number of driver related blueprints code already under review for Kilo and we
 are already drifting into the old familiar “Nova rebase hell” at the very
 beginning of the cycle. :-)

 The Nova core team is obviously doing everything possible to make everybody
 happy, I surely have no complains in the amount of effort put into the
 reviewing machine, but the total effort required seems simply hopelessly
 overwhelming for a single centralized team and lower priority features / bugs
 will suffer.

 Looking at the pending reviews count, a significative non trivial amount of 
 the
 patches is related to the drivers (see stats below) but since driver 
 blueprints
 and bugs are very rarely prioritized, I suspect that we might end up with
 another upstream release with inadeguate support for most hypervisors beside
 the “blessed” libvirt / KVM, resulting in a lot of blueprints and bug fixes
 postponed to the next release.

 The last discussion on this ML [1] on splitting the divers from Nova had a lot
 of consensus, no more than two months ago. I wonder why wasn’t this discussed
 further, for example at the design summit?

 In Hyper-V we averted this crisis by simply focusing on the downstream stable
 branches (e.g. [2] for Juno), where we reached the quality, stability and
 feature levels that we wanted [3], leaving the upstream driver code as a 
 simple
 “take it or leave it” best effort code that we surely don’t advise any of our
 users to even bother with. Every single line of code that we produce and merge
 downstream is obviously also sent upstream for review and eventually merged
 there as well, but we don’t necessarily worry anymore about the fact that it
 takes months for this to happen, even if we still put a lot of effort into it.

 At this stage, since the drivers are a completely partitioned and independent
 subset of Nova, the real umbilical cord that prevents a driver maintainer team
 to simply leave the Nova project and continue on StackForge is the third party
 CI system support, which with all its limitations it's still an amazing
 achievement.
 In particular third party CIs are extremely important from a hypervisor
 perspective to make sure that Nova changes don't cause regressions in the
 drivers (more than the other way around). This means that realistically, for a
 driver, leaving Nova and even going back through the Stackforge purgatory is
 simply not an option, unless there is a highly unrealistical consensus in 
 still
 mantaining a voting CI in Nova for what would become an external driver
 resulting from a schism.

 Please consider this just as a constructive discussion for the greater good of
 the whole OpenStack community [4] :-)

 Thanks,

 Alessandro


 Quick stats showing open reviews (please forgive the simplifications):

 All Nova (master):  657

 All nova/virt:  208

 nova/virt/hyperv:   31
 nova/virt/libvirt:  80
 nova/virt/vmwareapi:63
 nova/virt/xenapi:   28

 Values have been obtained with the following very basic query, not considering
 overlapping patches, unit tests, etc:

 gerrymander changes -p openstack/nova $PATH --status open --branch master -m 
 json \
 python -c import sys; import json; print 
 len(json.load(sys.stdin)[0]['table']['content'])


 [1] Last Nova drivers split discussion: 
 http://lists.openstack.org/pipermail/openstack-dev/2014-September/044872.html
 [2] Stable Hyper-V downstream Juno branch: 
 https://github.com/cloudbase/nova/tree/2014.1.2-cloudbase-release
 [3] Extensive downstream Hyper-V Tempest tests: 
 http://www.cloudbase.it/openstack-on-hyper-v-release-testing/
 [4] http://whatsthepont.files.wordpress.com/2012/02/20120212-223344.jpg




 On 20 Nov 2014, at 11:17, Michael Still mi...@stillhq.com wrote:

 Hi,

 as discussed at the summit, we want to do a better job of tracking the
 progress of work on our priorities for Kilo. To that end, we have
 agreed to 

Re: [openstack-dev] [Nova] Tracking Kilo priorities

2014-11-24 Thread Alessandro Pilotti
Hi Michael, 

 On 25 Nov 2014, at 01:57, Michael Still mi...@stillhq.com wrote:
 
 First off, sorry for the slow reply. I was on vacation last week.
 
 The project priority list was produced as part of the design summit,
 and reflects nova's need to pay down technical debt in order to keep
 meeting our users needs. So, whilst driver changes are important, they
 doesn't belong on that etherpad.
 
 That said, I think the best way to help us keep up with our code
 review requirements is to be an active reviewer. I know we say this a
 lot, but many cores optimize for patches which have already been
 reviewed and +1'ed by a non-core. So... Code review even with a +1
 makes a real difference to us being able to keep up.
 

Thanks for your reply, we actually do quite a lot of cross reviews, with the
general rule being that every patch produced by one of the Hyper-V team members
needs to be reviewed by at least another two.

The main issue is that reviews get lost at every rebase and keeping track of
this becomes not trivial when there are a lot of open patches under review,
mostly interdependent. It's not easy to keep people motivated to do this, but
we do our best!

Alessandro


 If you feel a change has been blocking on review for too long and is
 important, then please do raise it in the Open Discussion section of
 the nova meeting.
 
 Michael
 
 On Sat, Nov 22, 2014 at 2:02 AM, Alessandro Pilotti
 apilo...@cloudbasesolutions.com wrote:
 Hi,
 
 Not seeing any driver (Hyper-V, VMWare, etc) related priority in this 
 etherpad
 worries me a bit.
 
 
 My concern is mostly related to the fact that we have in Nova a significative
 number of driver related blueprints code already under review for Kilo and we
 are already drifting into the old familiar “Nova rebase hell” at the very
 beginning of the cycle. :-)
 
 The Nova core team is obviously doing everything possible to make everybody
 happy, I surely have no complains in the amount of effort put into the
 reviewing machine, but the total effort required seems simply hopelessly
 overwhelming for a single centralized team and lower priority features / bugs
 will suffer.
 
 Looking at the pending reviews count, a significative non trivial amount of 
 the
 patches is related to the drivers (see stats below) but since driver 
 blueprints
 and bugs are very rarely prioritized, I suspect that we might end up with
 another upstream release with inadeguate support for most hypervisors beside
 the “blessed” libvirt / KVM, resulting in a lot of blueprints and bug fixes
 postponed to the next release.
 
 The last discussion on this ML [1] on splitting the divers from Nova had a 
 lot
 of consensus, no more than two months ago. I wonder why wasn’t this discussed
 further, for example at the design summit?
 
 In Hyper-V we averted this crisis by simply focusing on the downstream stable
 branches (e.g. [2] for Juno), where we reached the quality, stability and
 feature levels that we wanted [3], leaving the upstream driver code as a 
 simple
 “take it or leave it” best effort code that we surely don’t advise any of our
 users to even bother with. Every single line of code that we produce and 
 merge
 downstream is obviously also sent upstream for review and eventually merged
 there as well, but we don’t necessarily worry anymore about the fact that it
 takes months for this to happen, even if we still put a lot of effort into 
 it.
 
 At this stage, since the drivers are a completely partitioned and independent
 subset of Nova, the real umbilical cord that prevents a driver maintainer 
 team
 to simply leave the Nova project and continue on StackForge is the third 
 party
 CI system support, which with all its limitations it's still an amazing
 achievement.
 In particular third party CIs are extremely important from a hypervisor
 perspective to make sure that Nova changes don't cause regressions in the
 drivers (more than the other way around). This means that realistically, for 
 a
 driver, leaving Nova and even going back through the Stackforge purgatory is
 simply not an option, unless there is a highly unrealistical consensus in 
 still
 mantaining a voting CI in Nova for what would become an external driver
 resulting from a schism.
 
 Please consider this just as a constructive discussion for the greater good 
 of
 the whole OpenStack community [4] :-)
 
 Thanks,
 
 Alessandro
 
 
 Quick stats showing open reviews (please forgive the simplifications):
 
 All Nova (master):  657
 
 All nova/virt:  208
 
 nova/virt/hyperv:   31
 nova/virt/libvirt:  80
 nova/virt/vmwareapi:63
 nova/virt/xenapi:   28
 
 Values have been obtained with the following very basic query, not 
 considering
 overlapping patches, unit tests, etc:
 
 gerrymander changes -p openstack/nova $PATH --status open --branch master -m 
 json \
 python -c import sys; import json; print 
 len(json.load(sys.stdin)[0]['table']['content'])
 
 
 [1] Last Nova drivers split discussion: 
 

Re: [openstack-dev] [Nova] Tracking Kilo priorities

2014-11-24 Thread Michael Still
On Tue, Nov 25, 2014 at 11:23 AM, Alessandro Pilotti
apilo...@cloudbasesolutions.com wrote:
 Hi Michael,

 On 25 Nov 2014, at 01:57, Michael Still mi...@stillhq.com wrote:

 First off, sorry for the slow reply. I was on vacation last week.

 The project priority list was produced as part of the design summit,
 and reflects nova's need to pay down technical debt in order to keep
 meeting our users needs. So, whilst driver changes are important, they
 doesn't belong on that etherpad.

 That said, I think the best way to help us keep up with our code
 review requirements is to be an active reviewer. I know we say this a
 lot, but many cores optimize for patches which have already been
 reviewed and +1'ed by a non-core. So... Code review even with a +1
 makes a real difference to us being able to keep up.


 Thanks for your reply, we actually do quite a lot of cross reviews, with the
 general rule being that every patch produced by one of the Hyper-V team 
 members
 needs to be reviewed by at least another two.

 The main issue is that reviews get lost at every rebase and keeping track of
 this becomes not trivial when there are a lot of open patches under review,
 mostly interdependent. It's not easy to keep people motivated to do this, but
 we do our best!

This is good news, and I will admit that I don't track the review
throughput of sub teams in nova.

I feel like focusing on the start of each review chain is useful here.
If you have the first two reviews in a chain with a couple of +1s on
them already, then I think that's a reasonable set of reviews to bring
up at a nova meeting. I sometimes see a +2 or two on reviews now at
the beginning of a chain, and that's wasted effort.

Michael

-- 
Rackspace Australia

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova] Tracking Kilo priorities

2014-11-24 Thread Alessandro Pilotti


 On 25 Nov 2014, at 02:35, Michael Still mi...@stillhq.com wrote:
 
 On Tue, Nov 25, 2014 at 11:23 AM, Alessandro Pilotti
 apilo...@cloudbasesolutions.com wrote:
 Hi Michael,
 
 On 25 Nov 2014, at 01:57, Michael Still mi...@stillhq.com wrote:
 
 First off, sorry for the slow reply. I was on vacation last week.
 
 The project priority list was produced as part of the design summit,
 and reflects nova's need to pay down technical debt in order to keep
 meeting our users needs. So, whilst driver changes are important, they
 doesn't belong on that etherpad.
 
 That said, I think the best way to help us keep up with our code
 review requirements is to be an active reviewer. I know we say this a
 lot, but many cores optimize for patches which have already been
 reviewed and +1'ed by a non-core. So... Code review even with a +1
 makes a real difference to us being able to keep up.
 
 
 Thanks for your reply, we actually do quite a lot of cross reviews, with the
 general rule being that every patch produced by one of the Hyper-V team 
 members
 needs to be reviewed by at least another two.
 
 The main issue is that reviews get lost at every rebase and keeping track of
 this becomes not trivial when there are a lot of open patches under review,
 mostly interdependent. It's not easy to keep people motivated to do this, but
 we do our best!
 
 This is good news, and I will admit that I don't track the review
 throughput of sub teams in nova.
 
 I feel like focusing on the start of each review chain is useful here.
 If you have the first two reviews in a chain with a couple of +1s on
 them already, then I think that's a reasonable set of reviews to bring
 up at a nova meeting. I sometimes see a +2 or two on reviews now at
 the beginning of a chain, and that's wasted effort.
 

Great, later today we have our Hyper-V team meeting, so we’ll re-apply any
missing review and I'll get back to you with the top priorities.
P.S.: danpb and johnthetubaguy have been really helpful on the Nova core side.

Thanks,

Alessandro


 Michael
 
 -- 
 Rackspace Australia

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova] Tracking Kilo priorities

2014-11-21 Thread Alessandro Pilotti
Hi,

Not seeing any driver (Hyper-V, VMWare, etc) related priority in this etherpad
worries me a bit.


My concern is mostly related to the fact that we have in Nova a significative
number of driver related blueprints code already under review for Kilo and we
are already drifting into the old familiar “Nova rebase hell” at the very
beginning of the cycle. :-)

The Nova core team is obviously doing everything possible to make everybody
happy, I surely have no complains in the amount of effort put into the
reviewing machine, but the total effort required seems simply hopelessly
overwhelming for a single centralized team and lower priority features / bugs
will suffer. 

Looking at the pending reviews count, a significative non trivial amount of the
patches is related to the drivers (see stats below) but since driver blueprints
and bugs are very rarely prioritized, I suspect that we might end up with
another upstream release with inadeguate support for most hypervisors beside
the “blessed” libvirt / KVM, resulting in a lot of blueprints and bug fixes
postponed to the next release.

The last discussion on this ML [1] on splitting the divers from Nova had a lot
of consensus, no more than two months ago. I wonder why wasn’t this discussed
further, for example at the design summit?

In Hyper-V we averted this crisis by simply focusing on the downstream stable
branches (e.g. [2] for Juno), where we reached the quality, stability and
feature levels that we wanted [3], leaving the upstream driver code as a simple
“take it or leave it” best effort code that we surely don’t advise any of our
users to even bother with. Every single line of code that we produce and merge
downstream is obviously also sent upstream for review and eventually merged
there as well, but we don’t necessarily worry anymore about the fact that it
takes months for this to happen, even if we still put a lot of effort into it.

At this stage, since the drivers are a completely partitioned and independent
subset of Nova, the real umbilical cord that prevents a driver maintainer team
to simply leave the Nova project and continue on StackForge is the third party
CI system support, which with all its limitations it's still an amazing
achievement. 
In particular third party CIs are extremely important from a hypervisor
perspective to make sure that Nova changes don't cause regressions in the
drivers (more than the other way around). This means that realistically, for a
driver, leaving Nova and even going back through the Stackforge purgatory is
simply not an option, unless there is a highly unrealistical consensus in still
mantaining a voting CI in Nova for what would become an external driver
resulting from a schism.

Please consider this just as a constructive discussion for the greater good of
the whole OpenStack community [4] :-)

Thanks,

Alessandro


Quick stats showing open reviews (please forgive the simplifications):

All Nova (master):  657

All nova/virt:  208

nova/virt/hyperv:   31
nova/virt/libvirt:  80
nova/virt/vmwareapi:63
nova/virt/xenapi:   28

Values have been obtained with the following very basic query, not considering
overlapping patches, unit tests, etc:

gerrymander changes -p openstack/nova $PATH --status open --branch master -m 
json \ 
python -c import sys; import json; print 
len(json.load(sys.stdin)[0]['table']['content'])


[1] Last Nova drivers split discussion: 
http://lists.openstack.org/pipermail/openstack-dev/2014-September/044872.html
[2] Stable Hyper-V downstream Juno branch: 
https://github.com/cloudbase/nova/tree/2014.1.2-cloudbase-release
[3] Extensive downstream Hyper-V Tempest tests: 
http://www.cloudbase.it/openstack-on-hyper-v-release-testing/
[4] http://whatsthepont.files.wordpress.com/2012/02/20120212-223344.jpg




 On 20 Nov 2014, at 11:17, Michael Still mi...@stillhq.com wrote:
 
 Hi,
 
 as discussed at the summit, we want to do a better job of tracking the
 progress of work on our priorities for Kilo. To that end, we have
 agreed to discuss the current state of these at each nova meeting.
 
 I have created this etherpad:
 
   https://etherpad.openstack.org/p/kilo-nova-priorities-tracking
 
 If you are the owner of a priority, please ensure it lists the reviews
 you currently require before the meeting tomorrow. If you could limit
 your entry to less than five reviews, that would be good.
 
 Thanks,
 Michael
 
 -- 
 Rackspace Australia
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova] Tracking Kilo priorities

2014-11-20 Thread Sylvain Bauza


Le 20/11/2014 10:17, Michael Still a écrit :

Hi,

as discussed at the summit, we want to do a better job of tracking the
progress of work on our priorities for Kilo. To that end, we have
agreed to discuss the current state of these at each nova meeting.

I have created this etherpad:

 https://etherpad.openstack.org/p/kilo-nova-priorities-tracking

If you are the owner of a priority, please ensure it lists the reviews
you currently require before the meeting tomorrow. If you could limit
your entry to less than five reviews, that would be good.

Thanks,
Michael



I'm anticipating a little bit, but as next week it will be Thanksgiving 
for our US peers, do you envisage any other exceptional timeslot for 
reviewing priorities ?


As the meetings are alternating, that means that people in EU timezones 
aren't able to attend weekly meetings until Dec 11th, which is one week 
before Kilo-1 milestone.


Thanks,
-Sylvain

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova] Tracking Kilo priorities

2014-11-20 Thread Flavio Percoco

On 20/11/14 20:17 +1100, Michael Still wrote:

Hi,

as discussed at the summit, we want to do a better job of tracking the
progress of work on our priorities for Kilo. To that end, we have
agreed to discuss the current state of these at each nova meeting.

I have created this etherpad:

   https://etherpad.openstack.org/p/kilo-nova-priorities-tracking

If you are the owner of a priority, please ensure it lists the reviews
you currently require before the meeting tomorrow. If you could limit
your entry to less than five reviews, that would be good.


Should the glanceclient and glance_store adoption be listed there?

I've a spec[0] for glanceclient and I'll work on the glance_store one
now.

[0] https://review.openstack.org/#/c/133485/

Flavio

--
@flaper87
Flavio Percoco


pgpmPWgBJiwpY.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova] Tracking Kilo priorities

2014-11-20 Thread John Garbutt
On 20 November 2014 09:32, Flavio Percoco fla...@redhat.com wrote:
 On 20/11/14 20:17 +1100, Michael Still wrote:

 Hi,

 as discussed at the summit, we want to do a better job of tracking the
 progress of work on our priorities for Kilo. To that end, we have
 agreed to discuss the current state of these at each nova meeting.

 I have created this etherpad:

https://etherpad.openstack.org/p/kilo-nova-priorities-tracking

 If you are the owner of a priority, please ensure it lists the reviews
 you currently require before the meeting tomorrow. If you could limit
 your entry to less than five reviews, that would be good.


 Should the glanceclient and glance_store adoption be listed there?

 I've a spec[0] for glanceclient and I'll work on the glance_store one
 now.

 [0] https://review.openstack.org/#/c/133485/

My memory of the conversation was, its important, but its not on the
top priority list:
https://etherpad.openstack.org/p/kilo-nova-priorities

Cheers,
John

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova] Tracking Kilo priorities

2014-11-20 Thread John Garbutt
On 20 November 2014 09:25, Sylvain Bauza sba...@redhat.com wrote:

 Le 20/11/2014 10:17, Michael Still a écrit :

 Hi,

 as discussed at the summit, we want to do a better job of tracking the
 progress of work on our priorities for Kilo. To that end, we have
 agreed to discuss the current state of these at each nova meeting.

 I have created this etherpad:

  https://etherpad.openstack.org/p/kilo-nova-priorities-tracking

 If you are the owner of a priority, please ensure it lists the reviews
 you currently require before the meeting tomorrow. If you could limit
 your entry to less than five reviews, that would be good.

 Thanks,
 Michael


 I'm anticipating a little bit, but as next week it will be Thanksgiving for
 our US peers, do you envisage any other exceptional timeslot for reviewing
 priorities ?

 As the meetings are alternating, that means that people in EU timezones
 aren't able to attend weekly meetings until Dec 11th, which is one week
 before Kilo-1 milestone.

I assume this is in reference to the Kilo-1 deadline for kilo
nova-specs to be merged?

I do hope to track the specs for all the priorities very closely.
Adding your spec reviews into the above etherpad would help me find
them.

Certainly anything on the list gets priority, so I would expect most
spec deadline exceptions to be related to items on that high priority
list.

Thanks,
John

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova] Tracking Kilo priorities

2014-11-20 Thread Sylvain Bauza


Le 20/11/2014 11:15, John Garbutt a écrit :

On 20 November 2014 09:25, Sylvain Bauza sba...@redhat.com wrote:

Le 20/11/2014 10:17, Michael Still a écrit :

Hi,

as discussed at the summit, we want to do a better job of tracking the
progress of work on our priorities for Kilo. To that end, we have
agreed to discuss the current state of these at each nova meeting.

I have created this etherpad:

  https://etherpad.openstack.org/p/kilo-nova-priorities-tracking

If you are the owner of a priority, please ensure it lists the reviews
you currently require before the meeting tomorrow. If you could limit
your entry to less than five reviews, that would be good.

Thanks,
Michael


I'm anticipating a little bit, but as next week it will be Thanksgiving for
our US peers, do you envisage any other exceptional timeslot for reviewing
priorities ?

As the meetings are alternating, that means that people in EU timezones
aren't able to attend weekly meetings until Dec 11th, which is one week
before Kilo-1 milestone.

I assume this is in reference to the Kilo-1 deadline for kilo
nova-specs to be merged?


Agreed, I was unclear.


I do hope to track the specs for all the priorities very closely.
Adding your spec reviews into the above etherpad would help me find
them.


Already had 2 reviews related to specs, but as Michael gently said, I 
don't want to provide all the specs related to the scheduler effort as 
there are 9 in parallel. We're tracking our effort on a separate 
wikipage in https://wiki.openstack.org/wiki/Gantt/kilo#Tasks




Certainly anything on the list gets priority, so I would expect most
spec deadline exceptions to be related to items on that high priority
list.


I truly appreciate this.

-Sylvain

Thanks,
John

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev