On 2014-07-17 09:37, Russell Bryant wrote: > On 07/16/2014 10:30 AM, John Garbutt wrote: >> On 16 July 2014 14:07, Thierry Carrez <thie...@openstack.org> wrote: >>> Daniel P. Berrange wrote: >>>> On Wed, Jul 16, 2014 at 11:57:33AM +0000, Tim Bell wrote: >>>>> It seems a pity to archive the comments and reviewer lists along >>>>> with losing a place to continue the discussions even if we are not >>>>> expecting to see code in Juno. >> >> Agreed we should keep those comments. >> >>>> Agreed, that is sub-optimal to say the least. >>>> >>>> The spec documents themselves are in a release specific directory >>>> though. Any which are to be postponed to Kxxx would need to move >>>> into a specs/kxxxx directory instead of specs/juno, but we don't >>>> know what the kxxxx directory needs to be called yet :-( >>> >>> The poll ends in 18 hours, so that should no longer be a blocker :) >> >> Aww, there goes our lame excuse for punting making a decision on this. >> >>> I think what we don't really want to abandon those specs and lose >>> comments and history... but we want to shelve them in a place where they >>> do not interrupt core developers workflow as they concentrate on Juno >>> work. It will be difficult to efficiently ignore them if they are filed >>> in a next or a kxxx directory, as they would still clutter /most/ Gerrit >>> views. >> >> +1 >> >> My intention was that once the specific project is open for K specs, >> people will restore their original patch set, and move the spec to the >> K directory, thus keeping all the history. >> >> For Nova, the open reviews, with a -2, are ones that are on the >> potential exception list, and so still might need some reviews. If >> they gain an exception, the -2 will be removed. The list of possible >> exceptions is currently included in bottom of this etherpad: >> https://etherpad.openstack.org/p/nova-juno-spec-priorities > > I think we can track potential exceptions without abandoning patches. I > think having them still open helps retain a dashboard of outstanding > specs. I'm also worried about how contributors feel having their spec > abandoned when it's not especially clear why in the review. Anyway, I'd > prefer just leaving them all open (with a -2 is fine) unless we think > it's a dead end.
+1. This is basically how we handle code changes that don't make feature freeze, so I don't see why it wouldn't work for specs too. > > For exceptions, I think we should require a core review sponsor for any > exception, similar to how we've handled feature freeze exceptions in the > past. I don't think it makes much sense to provide an exception unless > we're confident we can get it in. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
