Open Stack

On 07/16/2014 10:30 AM, John Garbutt wrote:
> On 16 July 2014 14:07, Thierry Carrez <thierry at 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.

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.

-- 
Russell Bryant