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 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
