Seems like we all agree on the basic idea here, which is great. I think just not concentrating on nova-spec reviews is fine, at least, it is the simplest way to implement the freeze (as Russell pointed out).
I so worry about setting the right expectations for the poor souls who's specs might stick in there for a few months unreviewed, and we come back to re-write the template for K and tell them they did it all wrong. But lets try avoid that. I guess the carrot is we have more reviewer (by which I mean everyone) focus on code, post the nova-specs soft freeze. Lets bring this up at the nova-meeting on Thursday (at the end) and see if we can get some consensus in there. Either way we should talk about the options to relax some of the nova-spec process at the mid-cycle summit, as I feel we have somewhat over-rotated here. Thanks, John On 25 June 2014 00:47, Michael Still <[email protected]> wrote: > Your comments are fair. I think perhaps at this point we should defer > discussion of the further away deadlines until the mid cycle meetup -- > that will give us a chance to whiteboard the flow for that period of > the release. > > Or do you really want to lock this down now? > > Michael > > On Wed, Jun 25, 2014 at 12:53 AM, Day, Phil <[email protected]> wrote: >>> -----Original Message----- >>> From: Russell Bryant [mailto:[email protected]] >>> Sent: 24 June 2014 13:08 >>> To: [email protected] >>> Subject: Re: [openstack-dev] [Nova] Timeline for the rest of the Juno >>> release >>> >>> On 06/24/2014 07:35 AM, Michael Still wrote: >>> > Phil -- I really want people to focus their efforts on fixing bugs in >>> > that period was the main thing. The theory was if we encouraged people >>> > to work on specs for the next release, then they'd be distracted from >>> > fixing the bugs we need fixed in J. >>> > >>> > Cheers, >>> > Michael >>> > >>> > On Tue, Jun 24, 2014 at 9:08 PM, Day, Phil <[email protected]> wrote: >>> >> Hi Michael, >>> >> >>> >> Not sure I understand the need for a gap between "Juno Spec approval >>> freeze" (Jul 10th) and "K opens for spec proposals" (Sep 4th). I can >>> understand that K specs won't get approved in that period, and may not get >>> much feedback from the cores - but I don't see the harm in letting specs be >>> submitted to the K directory for early review / feedback during that period >>> ? >>> >>> I agree with both of you. Priorities need to be finishing up J, but I >>> don't see >>> any reason not to let people post K specs whenever. >>> Expectations just need to be set appropriately that it may be a while before >>> they get reviewed/approved. >>> >> Exactly - I think it's reasonable to set the expectation that the focus of >> those that can produce/review code will be elsewhere - but that shouldn't >> stop some small effort going into knocking the rough corners off the specs >> at the same time >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > Rackspace Australia > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
