Open Stack

On Wed, Jul 16, 2014 at 9:30 AM, John Garbutt <john at johngarbutt.com> 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
>
> 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.
>
For the most part, I've been giving -2 to specs which we're not
approving for Juno. This means myself (and others who have been giving
-2s) needs to go back and remove those once the "K" release opens in
the neutron-specs repository. This is far from optimal, but does allow
for tracking of the specs and the history. I'm somewhat concerned that
once we open the "K" directory for Neutron specs we'll be deluged with
specs for that while we're trying hard to close Juno out, but I think
this problem will be there for all projects with specs repositories. I
don't think we've figured out a good way to focus people on the
remaining Juno items when this happens.

Kyle


> Thanks,
> John
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev