Open Stack

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

At some point we will open nova-specs for K, right now we are closed
for all spec submissions. We already have more blueprints approved
than we will be able to merge during the rest of Juno.

The idea is that everyone can now focus more on fixing bugs, reviewing
bug fixes, and reviewing remaining higher priority features, rather
than reviewing designs for K features. It is syncing a lot of
reviewers time looking at nova-specs, and it feels best to divert
attention.

We could leave the reviews open in gerrit, but we are trying hard to
set expectations around the likelihood of being reviewed and/or
accepted. In the past people have got very frustraighted and
complained about not finding out about what is happening (or not) with
what they have up for reviews.

This is all very new, so we are mostly making this up as we go along,
based on what we do with code submissions. Ideas on a better approach
that still meet most of the above goals, would be awesome.

Thanks,
John