Re: [openstack-dev] [nova] Kilo Blueprints and Specs
I plan to start prioritising the specs that are in the review queue, not just post approve. We should fast track those that have already been approved, and particularly when code is ready to go. My original plan was to propose a git move from juno to kilo, so its easy to see its just a re-approve. But this change alters that: https://review.openstack.org/#/c/122109/ On 30 September 2014 02:43, Michael Still wrote: > How about we tag these re-proposals with a commit message tag people can > search for when they review? Perhaps "Previously-approved: Juno"? Sure that could work. Ideally also a link to the old juno spec in the references section could help. Referencing it in here (after we tidy that up): http://specs.openstack.org/openstack/nova-specs/ Linking to a WIP patch set in the review comments, might also help. Thanks, John > On Tue, Sep 30, 2014 at 11:06 AM, Joe Gordon wrote: >> >> >> >> On Mon, Sep 29, 2014 at 4:46 PM, Christopher Yeoh >> wrote: >>> >>> On Mon, 29 Sep 2014 13:32:57 -0700 >>> Joe Gordon wrote: >>> >>> > On Mon, Sep 29, 2014 at 5:23 AM, Gary Kotton >>> > wrote: >>> > >>> > > Hi, >>> > > Is the process documented anywhere? That is, if say for example I >>> > > had a spec approved in J and its code did not land, how do we go >>> > > about kicking the tires for K on that spec. >>> > > >>> > >>> > Specs will need be re-submitted once we open up the specs repo for >>> > Kilo. The Kilo template will be changing a little bit, so specs will >>> > need a little bit of reworking. But I expect the process to approve >>> > previously approved specs to be quicker >>> >>> Am biased given I have a spec approved for Juno which we didn't quite >>> fully merge which we want to finish off early in Kilo (most of the >>> patches are very close already to being ready to merge), but I think we >>> should give priority to reviewing specs already approved in Juno and >>> perhaps only require one +2 for re-approval. >> >> >> I like the idea of prioritizing specs that were previously approved and >> only requiring a single +2 for re-approval if there are no major changes to >> them. >> >>> >>> >>> Otherwise we'll end up wasting weeks of development time just when >>> there is lots of review bandwidth available and the CI system is >>> lightly loaded. Honestly, ideally I'd like to just start merging as >>> soon as Kilo opens. Nothing has changed between Juno FF and Kilo opening >>> so there's really no reason that an approved Juno spec should not be >>> reapproved. >>> >>> Chris >>> >>> > >>> > >>> > > Thanks >>> > > Gary >>> > > >>> > > On 9/29/14, 1:07 PM, "John Garbutt" wrote: >>> > > >>> > > >On 27 September 2014 00:31, Joe Gordon >>> > > >wrote: >>> > > >> On Thu, Sep 25, 2014 at 9:21 AM, John Garbutt >>> > > >> >>> > > >>wrote: >>> > > >>> On 25 September 2014 14:10, Daniel P. Berrange >>> > > >>> wrote: >>> > > >>> >> The proposal is to keep kilo-1, kilo-2 much the same as juno. >>> > > >>>Except, >>> > > >>> >> we work harder on getting people to buy into the priorities >>> > > >>> >> that are set, and actively provoke more debate on their >>> > > >>> >> "correctness", and we reduce the bar for what needs a >>> > > >>> >> blueprint. >>> > > >>> >> >>> > > >>> >> We can't have 50 high priority blueprints, it doesn't mean >>> > > >>> >> anything, right? We need to trim the list down to a >>> > > >>> >> manageable number, based >>> > > >>>on >>> > > >>> >> the agreed project priorities. Thats all I mean by slots / >>> > > >>> >> runway at this point. >>> > > >>> > >>> > > >>> > I would suggest we don't try to rank high/medium/low as that >>> > > >>> > is too coarse, but rather just an ordered priority list. Then >>> > > >>> > you would not be in the situation of having 50 high >>> > > >>> > blueprints. We would instead naturally just start at the >>> > > >>> > highest priority and work downwards. >>> > > >>> >>> > > >>> OK. I guess I was fixating about fitting things into launchpad. >>> > > >>> >>> > > >>> I guess having both might be what happens. >>> > > >>> >>> > > >>> >> > The runways >>> > > >>> >> > idea is just going to make me less efficient at reviewing. >>> > > >>> >> > So I'm very much against it as an idea. >>> > > >>> >> >>> > > >>> >> This proposal is different to the runways idea, although it >>> > > >>>certainly >>> > > >>> >> borrows aspects of it. I just don't understand how this >>> > > >>> >> proposal has all the same issues? >>> > > >>> >> >>> > > >>> >> >>> > > >>> >> The key to the kilo-3 proposal, is about getting better at >>> > > >>> >> saying >>> > > >>>no, >>> > > >>> >> this blueprint isn't very likely to make kilo. >>> > > >>> >> >>> > > >>> >> If we focus on a smaller number of blueprints to review, we >>> > > >>> >> should >>> > > >>>be >>> > > >>> >> able to get a greater percentage of those fully completed. >>> > > >>> >> >>> > > >>> >> I am just using slots/runway-like ideas to help pick the high >>> > > >>>priority >>> > > >>> >> blueprints we should conc
Re: [openstack-dev] [nova] Kilo Blueprints and Specs
It seems like a no-brainer to me to prioritise people who have been patient with us. How about we tag these re-proposals with a commit message tag people can search for when they review? Perhaps "Previously-approved: Juno"? Michael On Tue, Sep 30, 2014 at 11:06 AM, Joe Gordon wrote: > > > On Mon, Sep 29, 2014 at 4:46 PM, Christopher Yeoh > wrote: > >> On Mon, 29 Sep 2014 13:32:57 -0700 >> Joe Gordon wrote: >> >> > On Mon, Sep 29, 2014 at 5:23 AM, Gary Kotton >> > wrote: >> > >> > > Hi, >> > > Is the process documented anywhere? That is, if say for example I >> > > had a spec approved in J and its code did not land, how do we go >> > > about kicking the tires for K on that spec. >> > > >> > >> > Specs will need be re-submitted once we open up the specs repo for >> > Kilo. The Kilo template will be changing a little bit, so specs will >> > need a little bit of reworking. But I expect the process to approve >> > previously approved specs to be quicker >> >> Am biased given I have a spec approved for Juno which we didn't quite >> fully merge which we want to finish off early in Kilo (most of the >> patches are very close already to being ready to merge), but I think we >> should give priority to reviewing specs already approved in Juno and >> perhaps only require one +2 for re-approval. >> > > I like the idea of prioritizing specs that were previously approved and > only requiring a single +2 for re-approval if there are no major changes to > them. > > >> >> Otherwise we'll end up wasting weeks of development time just when >> there is lots of review bandwidth available and the CI system is >> lightly loaded. Honestly, ideally I'd like to just start merging as >> soon as Kilo opens. Nothing has changed between Juno FF and Kilo opening >> so there's really no reason that an approved Juno spec should not be >> reapproved. >> >> Chris >> >> > >> > >> > > Thanks >> > > Gary >> > > >> > > On 9/29/14, 1:07 PM, "John Garbutt" wrote: >> > > >> > > >On 27 September 2014 00:31, Joe Gordon >> > > >wrote: >> > > >> On Thu, Sep 25, 2014 at 9:21 AM, John Garbutt >> > > >> >> > > >>wrote: >> > > >>> On 25 September 2014 14:10, Daniel P. Berrange >> > > >>> wrote: >> > > >>> >> The proposal is to keep kilo-1, kilo-2 much the same as juno. >> > > >>>Except, >> > > >>> >> we work harder on getting people to buy into the priorities >> > > >>> >> that are set, and actively provoke more debate on their >> > > >>> >> "correctness", and we reduce the bar for what needs a >> > > >>> >> blueprint. >> > > >>> >> >> > > >>> >> We can't have 50 high priority blueprints, it doesn't mean >> > > >>> >> anything, right? We need to trim the list down to a >> > > >>> >> manageable number, based >> > > >>>on >> > > >>> >> the agreed project priorities. Thats all I mean by slots / >> > > >>> >> runway at this point. >> > > >>> > >> > > >>> > I would suggest we don't try to rank high/medium/low as that >> > > >>> > is too coarse, but rather just an ordered priority list. Then >> > > >>> > you would not be in the situation of having 50 high >> > > >>> > blueprints. We would instead naturally just start at the >> > > >>> > highest priority and work downwards. >> > > >>> >> > > >>> OK. I guess I was fixating about fitting things into launchpad. >> > > >>> >> > > >>> I guess having both might be what happens. >> > > >>> >> > > >>> >> > The runways >> > > >>> >> > idea is just going to make me less efficient at reviewing. >> > > >>> >> > So I'm very much against it as an idea. >> > > >>> >> >> > > >>> >> This proposal is different to the runways idea, although it >> > > >>>certainly >> > > >>> >> borrows aspects of it. I just don't understand how this >> > > >>> >> proposal has all the same issues? >> > > >>> >> >> > > >>> >> >> > > >>> >> The key to the kilo-3 proposal, is about getting better at >> > > >>> >> saying >> > > >>>no, >> > > >>> >> this blueprint isn't very likely to make kilo. >> > > >>> >> >> > > >>> >> If we focus on a smaller number of blueprints to review, we >> > > >>> >> should >> > > >>>be >> > > >>> >> able to get a greater percentage of those fully completed. >> > > >>> >> >> > > >>> >> I am just using slots/runway-like ideas to help pick the high >> > > >>>priority >> > > >>> >> blueprints we should concentrate on, during that final >> > > >>> >> milestone. Rather than keeping the distraction of 15 or so >> > > >>> >> low priority blueprints, with those poor submitters jamming >> > > >>> >> up the check queue, >> > > >>>and >> > > >>> >> constantly rebasing, and having to deal with the odd stray >> > > >>> >> review comment they might get lucky enough to get. >> > > >>> >> >> > > >>> >> Maybe you think this bit is overkill, and thats fine. But I >> > > >>> >> still think we need a way to stop wasting so much of peoples >> > > >>> >> time on >> > > >>>things >> > > >>> >> that will not make it. >> > > >>> > >> > > >>> > The high priority blueprints are going to end up being mostly >> > > >>> > the big scope changes
Re: [openstack-dev] [nova] Kilo Blueprints and Specs
On Mon, Sep 29, 2014 at 4:46 PM, Christopher Yeoh wrote: > On Mon, 29 Sep 2014 13:32:57 -0700 > Joe Gordon wrote: > > > On Mon, Sep 29, 2014 at 5:23 AM, Gary Kotton > > wrote: > > > > > Hi, > > > Is the process documented anywhere? That is, if say for example I > > > had a spec approved in J and its code did not land, how do we go > > > about kicking the tires for K on that spec. > > > > > > > Specs will need be re-submitted once we open up the specs repo for > > Kilo. The Kilo template will be changing a little bit, so specs will > > need a little bit of reworking. But I expect the process to approve > > previously approved specs to be quicker > > Am biased given I have a spec approved for Juno which we didn't quite > fully merge which we want to finish off early in Kilo (most of the > patches are very close already to being ready to merge), but I think we > should give priority to reviewing specs already approved in Juno and > perhaps only require one +2 for re-approval. > I like the idea of prioritizing specs that were previously approved and only requiring a single +2 for re-approval if there are no major changes to them. > > Otherwise we'll end up wasting weeks of development time just when > there is lots of review bandwidth available and the CI system is > lightly loaded. Honestly, ideally I'd like to just start merging as > soon as Kilo opens. Nothing has changed between Juno FF and Kilo opening > so there's really no reason that an approved Juno spec should not be > reapproved. > > Chris > > > > > > > > Thanks > > > Gary > > > > > > On 9/29/14, 1:07 PM, "John Garbutt" wrote: > > > > > > >On 27 September 2014 00:31, Joe Gordon > > > >wrote: > > > >> On Thu, Sep 25, 2014 at 9:21 AM, John Garbutt > > > >> > > > >>wrote: > > > >>> On 25 September 2014 14:10, Daniel P. Berrange > > > >>> wrote: > > > >>> >> The proposal is to keep kilo-1, kilo-2 much the same as juno. > > > >>>Except, > > > >>> >> we work harder on getting people to buy into the priorities > > > >>> >> that are set, and actively provoke more debate on their > > > >>> >> "correctness", and we reduce the bar for what needs a > > > >>> >> blueprint. > > > >>> >> > > > >>> >> We can't have 50 high priority blueprints, it doesn't mean > > > >>> >> anything, right? We need to trim the list down to a > > > >>> >> manageable number, based > > > >>>on > > > >>> >> the agreed project priorities. Thats all I mean by slots / > > > >>> >> runway at this point. > > > >>> > > > > >>> > I would suggest we don't try to rank high/medium/low as that > > > >>> > is too coarse, but rather just an ordered priority list. Then > > > >>> > you would not be in the situation of having 50 high > > > >>> > blueprints. We would instead naturally just start at the > > > >>> > highest priority and work downwards. > > > >>> > > > >>> OK. I guess I was fixating about fitting things into launchpad. > > > >>> > > > >>> I guess having both might be what happens. > > > >>> > > > >>> >> > The runways > > > >>> >> > idea is just going to make me less efficient at reviewing. > > > >>> >> > So I'm very much against it as an idea. > > > >>> >> > > > >>> >> This proposal is different to the runways idea, although it > > > >>>certainly > > > >>> >> borrows aspects of it. I just don't understand how this > > > >>> >> proposal has all the same issues? > > > >>> >> > > > >>> >> > > > >>> >> The key to the kilo-3 proposal, is about getting better at > > > >>> >> saying > > > >>>no, > > > >>> >> this blueprint isn't very likely to make kilo. > > > >>> >> > > > >>> >> If we focus on a smaller number of blueprints to review, we > > > >>> >> should > > > >>>be > > > >>> >> able to get a greater percentage of those fully completed. > > > >>> >> > > > >>> >> I am just using slots/runway-like ideas to help pick the high > > > >>>priority > > > >>> >> blueprints we should concentrate on, during that final > > > >>> >> milestone. Rather than keeping the distraction of 15 or so > > > >>> >> low priority blueprints, with those poor submitters jamming > > > >>> >> up the check queue, > > > >>>and > > > >>> >> constantly rebasing, and having to deal with the odd stray > > > >>> >> review comment they might get lucky enough to get. > > > >>> >> > > > >>> >> Maybe you think this bit is overkill, and thats fine. But I > > > >>> >> still think we need a way to stop wasting so much of peoples > > > >>> >> time on > > > >>>things > > > >>> >> that will not make it. > > > >>> > > > > >>> > The high priority blueprints are going to end up being mostly > > > >>> > the big scope changes which take alot of time to review & > > > >>> > probably go through many iterations. The low priority > > > >>> > blueprints are going to end up > > > >>>being > > > >>> > the small things that don't consume significant resource to > > > >>> > review > > > >>>and > > > >>> > are easy to deal with in the time we're waiting for the big > > > >>> > items to go through rebases or whatever. So what I don't like > > >
Re: [openstack-dev] [nova] Kilo Blueprints and Specs
On Mon, 29 Sep 2014 13:32:57 -0700 Joe Gordon wrote: > On Mon, Sep 29, 2014 at 5:23 AM, Gary Kotton > wrote: > > > Hi, > > Is the process documented anywhere? That is, if say for example I > > had a spec approved in J and its code did not land, how do we go > > about kicking the tires for K on that spec. > > > > Specs will need be re-submitted once we open up the specs repo for > Kilo. The Kilo template will be changing a little bit, so specs will > need a little bit of reworking. But I expect the process to approve > previously approved specs to be quicker Am biased given I have a spec approved for Juno which we didn't quite fully merge which we want to finish off early in Kilo (most of the patches are very close already to being ready to merge), but I think we should give priority to reviewing specs already approved in Juno and perhaps only require one +2 for re-approval. Otherwise we'll end up wasting weeks of development time just when there is lots of review bandwidth available and the CI system is lightly loaded. Honestly, ideally I'd like to just start merging as soon as Kilo opens. Nothing has changed between Juno FF and Kilo opening so there's really no reason that an approved Juno spec should not be reapproved. Chris > > > > Thanks > > Gary > > > > On 9/29/14, 1:07 PM, "John Garbutt" wrote: > > > > >On 27 September 2014 00:31, Joe Gordon > > >wrote: > > >> On Thu, Sep 25, 2014 at 9:21 AM, John Garbutt > > >> > > >>wrote: > > >>> On 25 September 2014 14:10, Daniel P. Berrange > > >>> wrote: > > >>> >> The proposal is to keep kilo-1, kilo-2 much the same as juno. > > >>>Except, > > >>> >> we work harder on getting people to buy into the priorities > > >>> >> that are set, and actively provoke more debate on their > > >>> >> "correctness", and we reduce the bar for what needs a > > >>> >> blueprint. > > >>> >> > > >>> >> We can't have 50 high priority blueprints, it doesn't mean > > >>> >> anything, right? We need to trim the list down to a > > >>> >> manageable number, based > > >>>on > > >>> >> the agreed project priorities. Thats all I mean by slots / > > >>> >> runway at this point. > > >>> > > > >>> > I would suggest we don't try to rank high/medium/low as that > > >>> > is too coarse, but rather just an ordered priority list. Then > > >>> > you would not be in the situation of having 50 high > > >>> > blueprints. We would instead naturally just start at the > > >>> > highest priority and work downwards. > > >>> > > >>> OK. I guess I was fixating about fitting things into launchpad. > > >>> > > >>> I guess having both might be what happens. > > >>> > > >>> >> > The runways > > >>> >> > idea is just going to make me less efficient at reviewing. > > >>> >> > So I'm very much against it as an idea. > > >>> >> > > >>> >> This proposal is different to the runways idea, although it > > >>>certainly > > >>> >> borrows aspects of it. I just don't understand how this > > >>> >> proposal has all the same issues? > > >>> >> > > >>> >> > > >>> >> The key to the kilo-3 proposal, is about getting better at > > >>> >> saying > > >>>no, > > >>> >> this blueprint isn't very likely to make kilo. > > >>> >> > > >>> >> If we focus on a smaller number of blueprints to review, we > > >>> >> should > > >>>be > > >>> >> able to get a greater percentage of those fully completed. > > >>> >> > > >>> >> I am just using slots/runway-like ideas to help pick the high > > >>>priority > > >>> >> blueprints we should concentrate on, during that final > > >>> >> milestone. Rather than keeping the distraction of 15 or so > > >>> >> low priority blueprints, with those poor submitters jamming > > >>> >> up the check queue, > > >>>and > > >>> >> constantly rebasing, and having to deal with the odd stray > > >>> >> review comment they might get lucky enough to get. > > >>> >> > > >>> >> Maybe you think this bit is overkill, and thats fine. But I > > >>> >> still think we need a way to stop wasting so much of peoples > > >>> >> time on > > >>>things > > >>> >> that will not make it. > > >>> > > > >>> > The high priority blueprints are going to end up being mostly > > >>> > the big scope changes which take alot of time to review & > > >>> > probably go through many iterations. The low priority > > >>> > blueprints are going to end up > > >>>being > > >>> > the small things that don't consume significant resource to > > >>> > review > > >>>and > > >>> > are easy to deal with in the time we're waiting for the big > > >>> > items to go through rebases or whatever. So what I don't like > > >>> > about the > > >>>runways > > >>> > slots idea is that removes the ability to be agile and take > > >>> > the initiative > > >>> > to review & approve the low priority stuff that would > > >>> > otherwise never make it through. > > >>> > > >>> The idea is more around concentrating on the *same* list of > > >>> things. > > >>> > > >>> Certainly we need to avoid the priority inversion of > > >>> concentrating only on the big things. >
Re: [openstack-dev] [nova] Kilo Blueprints and Specs
On Mon, Sep 29, 2014 at 5:23 AM, Gary Kotton wrote: > Hi, > Is the process documented anywhere? That is, if say for example I had a > spec approved in J and its code did not land, how do we go about kicking > the tires for K on that spec. > Specs will need be re-submitted once we open up the specs repo for Kilo. The Kilo template will be changing a little bit, so specs will need a little bit of reworking. But I expect the process to approve previously approved specs to be quicker > Thanks > Gary > > On 9/29/14, 1:07 PM, "John Garbutt" wrote: > > >On 27 September 2014 00:31, Joe Gordon wrote: > >> On Thu, Sep 25, 2014 at 9:21 AM, John Garbutt > >>wrote: > >>> On 25 September 2014 14:10, Daniel P. Berrange > >>> wrote: > >>> >> The proposal is to keep kilo-1, kilo-2 much the same as juno. > >>>Except, > >>> >> we work harder on getting people to buy into the priorities that are > >>> >> set, and actively provoke more debate on their "correctness", and we > >>> >> reduce the bar for what needs a blueprint. > >>> >> > >>> >> We can't have 50 high priority blueprints, it doesn't mean anything, > >>> >> right? We need to trim the list down to a manageable number, based > >>>on > >>> >> the agreed project priorities. Thats all I mean by slots / runway at > >>> >> this point. > >>> > > >>> > I would suggest we don't try to rank high/medium/low as that is > >>> > too coarse, but rather just an ordered priority list. Then you > >>> > would not be in the situation of having 50 high blueprints. We > >>> > would instead naturally just start at the highest priority and > >>> > work downwards. > >>> > >>> OK. I guess I was fixating about fitting things into launchpad. > >>> > >>> I guess having both might be what happens. > >>> > >>> >> > The runways > >>> >> > idea is just going to make me less efficient at reviewing. So I'm > >>> >> > very much against it as an idea. > >>> >> > >>> >> This proposal is different to the runways idea, although it > >>>certainly > >>> >> borrows aspects of it. I just don't understand how this proposal has > >>> >> all the same issues? > >>> >> > >>> >> > >>> >> The key to the kilo-3 proposal, is about getting better at saying > >>>no, > >>> >> this blueprint isn't very likely to make kilo. > >>> >> > >>> >> If we focus on a smaller number of blueprints to review, we should > >>>be > >>> >> able to get a greater percentage of those fully completed. > >>> >> > >>> >> I am just using slots/runway-like ideas to help pick the high > >>>priority > >>> >> blueprints we should concentrate on, during that final milestone. > >>> >> Rather than keeping the distraction of 15 or so low priority > >>> >> blueprints, with those poor submitters jamming up the check queue, > >>>and > >>> >> constantly rebasing, and having to deal with the odd stray review > >>> >> comment they might get lucky enough to get. > >>> >> > >>> >> Maybe you think this bit is overkill, and thats fine. But I still > >>> >> think we need a way to stop wasting so much of peoples time on > >>>things > >>> >> that will not make it. > >>> > > >>> > The high priority blueprints are going to end up being mostly the big > >>> > scope changes which take alot of time to review & probably go through > >>> > many iterations. The low priority blueprints are going to end up > >>>being > >>> > the small things that don't consume significant resource to review > >>>and > >>> > are easy to deal with in the time we're waiting for the big items to > >>> > go through rebases or whatever. So what I don't like about the > >>>runways > >>> > slots idea is that removes the ability to be agile and take the > >>> > initiative > >>> > to review & approve the low priority stuff that would otherwise never > >>> > make it through. > >>> > >>> The idea is more around concentrating on the *same* list of things. > >>> > >>> Certainly we need to avoid the priority inversion of concentrating > >>> only on the big things. > >>> > >>> Its also why I suggested that for kilo-1 and kilo-2, we allow any > >>> blueprint to merge, and only restrict it to a specific list in kilo-3, > >>> the idea being to maximise the number of things that get completed, > >>> rather than merging some half blueprints, but not getting to the good > >>> bits. > >>> > >> > >> Do we have to decide this now, or can we see how project priorities go > >>and > >> reevaluate half way through Kilo-2? > > > >What we need to decide is not to use the runway idea for kilo-1 and > >kilo-2. At this point, I guess we have (passively) decided that now. > > > >I like the idea of waiting till mid kilo-2. Thats around Spec freeze, > >which is handy. > > > >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.o
Re: [openstack-dev] [nova] Kilo Blueprints and Specs
Hi, Is the process documented anywhere? That is, if say for example I had a spec approved in J and its code did not land, how do we go about kicking the tires for K on that spec. Thanks Gary On 9/29/14, 1:07 PM, "John Garbutt" wrote: >On 27 September 2014 00:31, Joe Gordon wrote: >> On Thu, Sep 25, 2014 at 9:21 AM, John Garbutt >>wrote: >>> On 25 September 2014 14:10, Daniel P. Berrange >>> wrote: >>> >> The proposal is to keep kilo-1, kilo-2 much the same as juno. >>>Except, >>> >> we work harder on getting people to buy into the priorities that are >>> >> set, and actively provoke more debate on their "correctness", and we >>> >> reduce the bar for what needs a blueprint. >>> >> >>> >> We can't have 50 high priority blueprints, it doesn't mean anything, >>> >> right? We need to trim the list down to a manageable number, based >>>on >>> >> the agreed project priorities. Thats all I mean by slots / runway at >>> >> this point. >>> > >>> > I would suggest we don't try to rank high/medium/low as that is >>> > too coarse, but rather just an ordered priority list. Then you >>> > would not be in the situation of having 50 high blueprints. We >>> > would instead naturally just start at the highest priority and >>> > work downwards. >>> >>> OK. I guess I was fixating about fitting things into launchpad. >>> >>> I guess having both might be what happens. >>> >>> >> > The runways >>> >> > idea is just going to make me less efficient at reviewing. So I'm >>> >> > very much against it as an idea. >>> >> >>> >> This proposal is different to the runways idea, although it >>>certainly >>> >> borrows aspects of it. I just don't understand how this proposal has >>> >> all the same issues? >>> >> >>> >> >>> >> The key to the kilo-3 proposal, is about getting better at saying >>>no, >>> >> this blueprint isn't very likely to make kilo. >>> >> >>> >> If we focus on a smaller number of blueprints to review, we should >>>be >>> >> able to get a greater percentage of those fully completed. >>> >> >>> >> I am just using slots/runway-like ideas to help pick the high >>>priority >>> >> blueprints we should concentrate on, during that final milestone. >>> >> Rather than keeping the distraction of 15 or so low priority >>> >> blueprints, with those poor submitters jamming up the check queue, >>>and >>> >> constantly rebasing, and having to deal with the odd stray review >>> >> comment they might get lucky enough to get. >>> >> >>> >> Maybe you think this bit is overkill, and thats fine. But I still >>> >> think we need a way to stop wasting so much of peoples time on >>>things >>> >> that will not make it. >>> > >>> > The high priority blueprints are going to end up being mostly the big >>> > scope changes which take alot of time to review & probably go through >>> > many iterations. The low priority blueprints are going to end up >>>being >>> > the small things that don't consume significant resource to review >>>and >>> > are easy to deal with in the time we're waiting for the big items to >>> > go through rebases or whatever. So what I don't like about the >>>runways >>> > slots idea is that removes the ability to be agile and take the >>> > initiative >>> > to review & approve the low priority stuff that would otherwise never >>> > make it through. >>> >>> The idea is more around concentrating on the *same* list of things. >>> >>> Certainly we need to avoid the priority inversion of concentrating >>> only on the big things. >>> >>> Its also why I suggested that for kilo-1 and kilo-2, we allow any >>> blueprint to merge, and only restrict it to a specific list in kilo-3, >>> the idea being to maximise the number of things that get completed, >>> rather than merging some half blueprints, but not getting to the good >>> bits. >>> >> >> Do we have to decide this now, or can we see how project priorities go >>and >> reevaluate half way through Kilo-2? > >What we need to decide is not to use the runway idea for kilo-1 and >kilo-2. At this point, I guess we have (passively) decided that now. > >I like the idea of waiting till mid kilo-2. Thats around Spec freeze, >which is handy. > >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
Re: [openstack-dev] [nova] Kilo Blueprints and Specs
On 27 September 2014 00:31, Joe Gordon wrote: > On Thu, Sep 25, 2014 at 9:21 AM, John Garbutt wrote: >> On 25 September 2014 14:10, Daniel P. Berrange >> wrote: >> >> The proposal is to keep kilo-1, kilo-2 much the same as juno. Except, >> >> we work harder on getting people to buy into the priorities that are >> >> set, and actively provoke more debate on their "correctness", and we >> >> reduce the bar for what needs a blueprint. >> >> >> >> We can't have 50 high priority blueprints, it doesn't mean anything, >> >> right? We need to trim the list down to a manageable number, based on >> >> the agreed project priorities. Thats all I mean by slots / runway at >> >> this point. >> > >> > I would suggest we don't try to rank high/medium/low as that is >> > too coarse, but rather just an ordered priority list. Then you >> > would not be in the situation of having 50 high blueprints. We >> > would instead naturally just start at the highest priority and >> > work downwards. >> >> OK. I guess I was fixating about fitting things into launchpad. >> >> I guess having both might be what happens. >> >> >> > The runways >> >> > idea is just going to make me less efficient at reviewing. So I'm >> >> > very much against it as an idea. >> >> >> >> This proposal is different to the runways idea, although it certainly >> >> borrows aspects of it. I just don't understand how this proposal has >> >> all the same issues? >> >> >> >> >> >> The key to the kilo-3 proposal, is about getting better at saying no, >> >> this blueprint isn't very likely to make kilo. >> >> >> >> If we focus on a smaller number of blueprints to review, we should be >> >> able to get a greater percentage of those fully completed. >> >> >> >> I am just using slots/runway-like ideas to help pick the high priority >> >> blueprints we should concentrate on, during that final milestone. >> >> Rather than keeping the distraction of 15 or so low priority >> >> blueprints, with those poor submitters jamming up the check queue, and >> >> constantly rebasing, and having to deal with the odd stray review >> >> comment they might get lucky enough to get. >> >> >> >> Maybe you think this bit is overkill, and thats fine. But I still >> >> think we need a way to stop wasting so much of peoples time on things >> >> that will not make it. >> > >> > The high priority blueprints are going to end up being mostly the big >> > scope changes which take alot of time to review & probably go through >> > many iterations. The low priority blueprints are going to end up being >> > the small things that don't consume significant resource to review and >> > are easy to deal with in the time we're waiting for the big items to >> > go through rebases or whatever. So what I don't like about the runways >> > slots idea is that removes the ability to be agile and take the >> > initiative >> > to review & approve the low priority stuff that would otherwise never >> > make it through. >> >> The idea is more around concentrating on the *same* list of things. >> >> Certainly we need to avoid the priority inversion of concentrating >> only on the big things. >> >> Its also why I suggested that for kilo-1 and kilo-2, we allow any >> blueprint to merge, and only restrict it to a specific list in kilo-3, >> the idea being to maximise the number of things that get completed, >> rather than merging some half blueprints, but not getting to the good >> bits. >> > > Do we have to decide this now, or can we see how project priorities go and > reevaluate half way through Kilo-2? What we need to decide is not to use the runway idea for kilo-1 and kilo-2. At this point, I guess we have (passively) decided that now. I like the idea of waiting till mid kilo-2. Thats around Spec freeze, which is handy. 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] Kilo Blueprints and Specs
On Thu, Sep 25, 2014 at 9:21 AM, John Garbutt wrote: > On 25 September 2014 14:10, Daniel P. Berrange > wrote: > >> The proposal is to keep kilo-1, kilo-2 much the same as juno. Except, > >> we work harder on getting people to buy into the priorities that are > >> set, and actively provoke more debate on their "correctness", and we > >> reduce the bar for what needs a blueprint. > >> > >> We can't have 50 high priority blueprints, it doesn't mean anything, > >> right? We need to trim the list down to a manageable number, based on > >> the agreed project priorities. Thats all I mean by slots / runway at > >> this point. > > > > I would suggest we don't try to rank high/medium/low as that is > > too coarse, but rather just an ordered priority list. Then you > > would not be in the situation of having 50 high blueprints. We > > would instead naturally just start at the highest priority and > > work downwards. > > OK. I guess I was fixating about fitting things into launchpad. > > I guess having both might be what happens. > > >> > The runways > >> > idea is just going to make me less efficient at reviewing. So I'm > >> > very much against it as an idea. > >> > >> This proposal is different to the runways idea, although it certainly > >> borrows aspects of it. I just don't understand how this proposal has > >> all the same issues? > >> > >> > >> The key to the kilo-3 proposal, is about getting better at saying no, > >> this blueprint isn't very likely to make kilo. > >> > >> If we focus on a smaller number of blueprints to review, we should be > >> able to get a greater percentage of those fully completed. > >> > >> I am just using slots/runway-like ideas to help pick the high priority > >> blueprints we should concentrate on, during that final milestone. > >> Rather than keeping the distraction of 15 or so low priority > >> blueprints, with those poor submitters jamming up the check queue, and > >> constantly rebasing, and having to deal with the odd stray review > >> comment they might get lucky enough to get. > >> > >> Maybe you think this bit is overkill, and thats fine. But I still > >> think we need a way to stop wasting so much of peoples time on things > >> that will not make it. > > > > The high priority blueprints are going to end up being mostly the big > > scope changes which take alot of time to review & probably go through > > many iterations. The low priority blueprints are going to end up being > > the small things that don't consume significant resource to review and > > are easy to deal with in the time we're waiting for the big items to > > go through rebases or whatever. So what I don't like about the runways > > slots idea is that removes the ability to be agile and take the > initiative > > to review & approve the low priority stuff that would otherwise never > > make it through. > > The idea is more around concentrating on the *same* list of things. > > Certainly we need to avoid the priority inversion of concentrating > only on the big things. > > Its also why I suggested that for kilo-1 and kilo-2, we allow any > blueprint to merge, and only restrict it to a specific list in kilo-3, > the idea being to maximise the number of things that get completed, > rather than merging some half blueprints, but not getting to the good > bits. > > Do we have to decide this now, or can we see how project priorities go and reevaluate half way through Kilo-2? > > Anyways, it seems like this doesn't hit a middle ground that would > gain pre-summit approval. Or at least needs some online chat time to > work out something. > > > 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
Re: [openstack-dev] [nova] Kilo Blueprints and Specs
On 25 September 2014 14:10, Daniel P. Berrange wrote: >> The proposal is to keep kilo-1, kilo-2 much the same as juno. Except, >> we work harder on getting people to buy into the priorities that are >> set, and actively provoke more debate on their "correctness", and we >> reduce the bar for what needs a blueprint. >> >> We can't have 50 high priority blueprints, it doesn't mean anything, >> right? We need to trim the list down to a manageable number, based on >> the agreed project priorities. Thats all I mean by slots / runway at >> this point. > > I would suggest we don't try to rank high/medium/low as that is > too coarse, but rather just an ordered priority list. Then you > would not be in the situation of having 50 high blueprints. We > would instead naturally just start at the highest priority and > work downwards. OK. I guess I was fixating about fitting things into launchpad. I guess having both might be what happens. >> > The runways >> > idea is just going to make me less efficient at reviewing. So I'm >> > very much against it as an idea. >> >> This proposal is different to the runways idea, although it certainly >> borrows aspects of it. I just don't understand how this proposal has >> all the same issues? >> >> >> The key to the kilo-3 proposal, is about getting better at saying no, >> this blueprint isn't very likely to make kilo. >> >> If we focus on a smaller number of blueprints to review, we should be >> able to get a greater percentage of those fully completed. >> >> I am just using slots/runway-like ideas to help pick the high priority >> blueprints we should concentrate on, during that final milestone. >> Rather than keeping the distraction of 15 or so low priority >> blueprints, with those poor submitters jamming up the check queue, and >> constantly rebasing, and having to deal with the odd stray review >> comment they might get lucky enough to get. >> >> Maybe you think this bit is overkill, and thats fine. But I still >> think we need a way to stop wasting so much of peoples time on things >> that will not make it. > > The high priority blueprints are going to end up being mostly the big > scope changes which take alot of time to review & probably go through > many iterations. The low priority blueprints are going to end up being > the small things that don't consume significant resource to review and > are easy to deal with in the time we're waiting for the big items to > go through rebases or whatever. So what I don't like about the runways > slots idea is that removes the ability to be agile and take the initiative > to review & approve the low priority stuff that would otherwise never > make it through. The idea is more around concentrating on the *same* list of things. Certainly we need to avoid the priority inversion of concentrating only on the big things. Its also why I suggested that for kilo-1 and kilo-2, we allow any blueprint to merge, and only restrict it to a specific list in kilo-3, the idea being to maximise the number of things that get completed, rather than merging some half blueprints, but not getting to the good bits. Anyways, it seems like this doesn't hit a middle ground that would gain pre-summit approval. Or at least needs some online chat time to work out something. 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] Kilo Blueprints and Specs
On Thu, Sep 25, 2014 at 01:52:48PM +0100, John Garbutt wrote: > On 25 September 2014 11:44, Daniel P. Berrange wrote: > > To use the runway system, we need to have a frequently updated list > > of blueprints which are a priority to review / merge. Once we have > > such a list, IMHO, adding the fixed runway slots around that does > > not do anything positive for me as a reviewer. If we have a priority > > list of blueprints that is accurate & timely updated, I'd be far > > more effective if I just worked directly from that list. > > I am proposing we do that for kilo-1 and kilo-2. > > > Please just focus on the maintaining > > the blueprint priority list. > > I am trying to. I clearly failed. > > > The proposal is to keep kilo-1, kilo-2 much the same as juno. Except, > we work harder on getting people to buy into the priorities that are > set, and actively provoke more debate on their "correctness", and we > reduce the bar for what needs a blueprint. > > We can't have 50 high priority blueprints, it doesn't mean anything, > right? We need to trim the list down to a manageable number, based on > the agreed project priorities. Thats all I mean by slots / runway at > this point. I would suggest we don't try to rank high/medium/low as that is too coarse, but rather just an ordered priority list. Then you would not be in the situation of having 50 high blueprints. We would instead naturally just start at the highest priority and work downwards. > > The runways > > idea is just going to make me less efficient at reviewing. So I'm > > very much against it as an idea. > > This proposal is different to the runways idea, although it certainly > borrows aspects of it. I just don't understand how this proposal has > all the same issues? > > > The key to the kilo-3 proposal, is about getting better at saying no, > this blueprint isn't very likely to make kilo. > > If we focus on a smaller number of blueprints to review, we should be > able to get a greater percentage of those fully completed. > > I am just using slots/runway-like ideas to help pick the high priority > blueprints we should concentrate on, during that final milestone. > Rather than keeping the distraction of 15 or so low priority > blueprints, with those poor submitters jamming up the check queue, and > constantly rebasing, and having to deal with the odd stray review > comment they might get lucky enough to get. > > Maybe you think this bit is overkill, and thats fine. But I still > think we need a way to stop wasting so much of peoples time on things > that will not make it. The high priority blueprints are going to end up being mostly the big scope changes which take alot of time to review & probably go through many iterations. The low priority blueprints are going to end up being the small things that don't consume significant resource to review and are easy to deal with in the time we're waiting for the big items to go through rebases or whatever. So what I don't like about the runways slots idea is that removes the ability to be agile and take the initiative to review & approve the low priority stuff that would otherwise never make it through. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Kilo Blueprints and Specs
On 25 September 2014 11:44, Daniel P. Berrange wrote: > To use the runway system, we need to have a frequently updated list > of blueprints which are a priority to review / merge. Once we have > such a list, IMHO, adding the fixed runway slots around that does > not do anything positive for me as a reviewer. If we have a priority > list of blueprints that is accurate & timely updated, I'd be far > more effective if I just worked directly from that list. I am proposing we do that for kilo-1 and kilo-2. > Please just focus on the maintaining > the blueprint priority list. I am trying to. I clearly failed. The proposal is to keep kilo-1, kilo-2 much the same as juno. Except, we work harder on getting people to buy into the priorities that are set, and actively provoke more debate on their "correctness", and we reduce the bar for what needs a blueprint. We can't have 50 high priority blueprints, it doesn't mean anything, right? We need to trim the list down to a manageable number, based on the agreed project priorities. Thats all I mean by slots / runway at this point. Does this sound reasonable? > The runways > idea is just going to make me less efficient at reviewing. So I'm > very much against it as an idea. This proposal is different to the runways idea, although it certainly borrows aspects of it. I just don't understand how this proposal has all the same issues? The key to the kilo-3 proposal, is about getting better at saying no, this blueprint isn't very likely to make kilo. If we focus on a smaller number of blueprints to review, we should be able to get a greater percentage of those fully completed. I am just using slots/runway-like ideas to help pick the high priority blueprints we should concentrate on, during that final milestone. Rather than keeping the distraction of 15 or so low priority blueprints, with those poor submitters jamming up the check queue, and constantly rebasing, and having to deal with the odd stray review comment they might get lucky enough to get. Maybe you think this bit is overkill, and thats fine. But I still think we need a way to stop wasting so much of peoples time on things that will not make it. 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] Kilo Blueprints and Specs
On Thu, Sep 25, 2014 at 11:27:09AM +0100, John Garbutt wrote: > Hi, > > A big thank you to jogo who has done a great job writing up plans for > kilo blueprints and specs: > > 1) Allow more code that doesn't need a blueprint and spec: > https://review.openstack.org/#/c/116699/3 > > Specs are a heavy process, so hopefully this will strike a better > balance between process and freedom. Basically it is forcing developer > write documentation, which is always going to be painful. > > 2) As a community, get project wide buy-in to blueprint priorities: > https://review.openstack.org/#/c/112733/10 > > All attempts to do this have fallen flat of their face. The new summit > structure should really help allow the right conversations to happen. > > > I see two big remaining (inter-related) issues: > * how to get more code merged into a Nova release > * how to get better at saying no to stuff that will not fit > > > There has been much discussion over getting more code into Nova, involving: > * fix technical debt that is slowing us down > * having sub-system (semi-)core reviewers, or similar > * splitting up the code base more (after establishing firmer interfaces) > I think we need a combination of all three, but I didn't want to go > there in this thread. > > > How do we get better at "saying no" ? > > We have "politeness inversion" here. Leaving it to the last moment to > tell people there code is not going to merge causes us lots of hidden > overhead, and frustration all round. Honestly, clicking -2 on so much > code that missed the feature freeze (and in many cases it was already > approved) left me really quite depressed, and the submitters probably > felt worse. > > Discussion at the mid-cylce lead to the runway idea: > https://review.openstack.org/#/c/112733 > > The main push back, are worries over process heaviness of the > approach. The current spec process feels too heavy already, so adding > more process is certainly a risk. > > Here is a possible compromise: > * only use the runway system for kilo-3 > > The idea being, we have a soft-ish feature freeze at the end of > kilo-2, and make any blueprints targeted for kilo-3 go through a > runway-like system, to help ensure what gets on there will get merged > before the end of kilo-3. To use the runway system, we need to have a frequently updated list of blueprints which are a priority to review / merge. Once we have such a list, IMHO, adding the fixed runway slots around that does not do anything positive for me as a reviewer. If we have a priority list of blueprints that is accurate & timely updated, I'd be far more effective if I just worked directly from that list. The runways idea is just going to make me less efficient at reviewing. So I'm very much against it as an idea. Plesae just focus on the maintaining the blueprint priority list. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
