Open Stack

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 <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.

+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.