Re: [openstack-dev] [specs] how to continue spec discussion
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 thie...@openstack.org wrote: Daniel P. Berrange wrote: On Wed, Jul 16, 2014 at 11:57:33AM +, 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/k directory instead of specs/juno, but we don't know what the k 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. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [specs] how to continue spec discussion
Agreed. And we should keep records for each release. On Wed, Jul 16, 2014 at 7:57 PM, Tim Bell tim.b...@cern.ch wrote: As we approach Juno-3, a number of specs have been correctly marked as abandoned since they are not expected to be ready in time for the release. Is there a mechanism to keep these specs open for discussion even though there is no expectation that they will be ready for Juno and ‘defer’ them to ‘K’ ? 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. Tim ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best wishes! Baohua ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [specs] how to continue spec discussion
On Wed, Jul 16, 2014 at 03:30:56PM +0100, John Garbutt wrote: 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. The main thing I'd say in favour of allowing people to submit K^H^H^H^H^H Kilo specs now is that it gives everyone a good heads up on what people are thinking about. We've had a number of cases where people have basically been working on specs for the same feature. If we don't open up Kilo specs now, people will write their specs up keep them private meaning there is less opportunity for people to discover they are working on the same problem. IMHO anything we can do to facilitate collaboration and communication between people with interests in the same area is worthwhile. I agree though, that if we do allow Kilo specs now, we should explicitly state that we will not be reviewing them yet. Perhaps we could even add a boilerplate comment to Kilo specs that are submitted before review period opens to this effect so that people aren't disappointed by lack of formal review. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [specs] how to continue spec discussion
On 07/16/2014 10:30 AM, John Garbutt wrote: 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 +, 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/k directory instead of specs/juno, but we don't know what the k 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [specs] how to continue spec discussion
As we approach Juno-3, a number of specs have been correctly marked as abandoned since they are not expected to be ready in time for the release. Is there a mechanism to keep these specs open for discussion even though there is no expectation that they will be ready for Juno and 'defer' them to 'K' ? 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. Tim ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [specs] how to continue spec discussion
On Wed, Jul 16, 2014 at 11:57:33AM +, Tim Bell wrote: As we approach Juno-3, a number of specs have been correctly marked as abandoned since they are not expected to be ready in time for the release. Is there a mechanism to keep these specs open for discussion even though there is no expectation that they will be ready for Juno and 'defer' them to 'K' ? 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, 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/k directory instead of specs/juno, but we don't know what the k directory needs to be called yet :-( Assuming we determine the directory name, then IMHO any spec could just be restored placing the spec into the new directory for K. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [specs] how to continue spec discussion
Le 16/07/2014 14:09, Daniel P. Berrange a écrit : On Wed, Jul 16, 2014 at 11:57:33AM +, Tim Bell wrote: As we approach Juno-3, a number of specs have been correctly marked as abandoned since they are not expected to be ready in time for the release. Is there a mechanism to keep these specs open for discussion even though there is no expectation that they will be ready for Juno and 'defer' them to 'K' ? 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, 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/k directory instead of specs/juno, but we don't know what the k directory needs to be called yet :-( Assuming we determine the directory name, then IMHO any spec could just be restored placing the spec into the new directory for K. Regards, Daniel I'm just thinking about the opportunity of creating a 'next' directory in addition to the juno and Kxxx dirs, so that the logic would be the same as for Launchpad. That would also mean that a spec could be merged with target set to 'next', which is not a non-sense but just means the idea is validated, without having determined a release date yet. Thoughts ? -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [specs] how to continue spec discussion
Daniel P. Berrange wrote: On Wed, Jul 16, 2014 at 11:57:33AM +, 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, 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/k directory instead of specs/juno, but we don't know what the k directory needs to be called yet :-( The poll ends in 18 hours, so that should no longer be a blocker :) 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. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [specs] how to continue spec discussion
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 +, 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/k directory instead of specs/juno, but we don't know what the k 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
Re: [openstack-dev] [specs] how to continue spec discussion
On Wed, Jul 16, 2014 at 9:30 AM, John Garbutt j...@johngarbutt.com wrote: 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 +, 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/k directory instead of specs/juno, but we don't know what the k 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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
