Re: [openstack-dev] [Neutron] keep old specs
I agree as well. I think moving them to an unimplemented folder makes sense and would be helpful in reviewing if one re-proposes a blueprint. On Mon, Sep 15, 2014 at 7:20 AM, Russell Bryant rbry...@redhat.com wrote: On 09/15/2014 10:01 AM, Kevin Benton wrote: Some of the specs had a significant amount of detail and thought put into them. It seems like a waste to bury them in a git tree history. By having them in a place where external parties (e.g. operators) can easily find them, they could get more visibility and feedback for any future revisions. Just being able to see that a feature was previously designed out and approved can prevent a future person from wasting a bunch of time typing up a new spec for the same feature. Hardly anyone is going to search deleted specs from two cycles ago if it requires checking out a commit. Why just restrict the whole repo to being documentation of what went in? If that's all the specs are for, why don't we just wait to create them until after the code merges? FWIW, I agree with you that it makes sense to keep them in a directory that makes it clear that they were not completed. There's a ton of useful info in them. Even if they get re-proposed, it's still useful to see the difference in the proposal as it evolved between releases. -- Russell Bryant ___ 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
[openstack-dev] [Neutron] keep old specs
I saw that the specs that didn't make the deadline for the feature freeze were removed from the tree completely.[1] For easier reference, can we instead revert that commit to restore them and then move them into a release specific folder called 'unimplemented' or something along those lines? It will be nice in the future to browse through the specs for a release and see what specs were approved but didn't make it in time. Then if someone wants to try to propose it again, their patch can be to move the spec into the current cycle and then they only have to make revisions rather than redo the whole thing. It also reduces the number of hoops to jump through to quickly search for a spec based on keywords. Otherwise we have to checkout a commit before the removal and then search. Thoughts, suggestions, or anecdotes about small sailboats? 1. https://github.com/openstack/neutron-specs/commit/77f8c806a49769322b02ea6017a1a2a39ef1cfd7 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] keep old specs
On Mon, Sep 15, 2014 at 4:52 AM, Kevin Benton blak...@gmail.com wrote: I saw that the specs that didn't make the deadline for the feature freeze were removed from the tree completely.[1] For easier reference, can we instead revert that commit to restore them and then move them into a release specific folder called 'unimplemented' or something along those lines? No, I don't think there's value to keeping specs along which never made a release. The point of the specs repo is to track things which made the release. It will be nice in the future to browse through the specs for a release and see what specs were approved but didn't make it in time. Then if someone wants to try to propose it again, their patch can be to move the spec into the current cycle and then they only have to make revisions rather than redo the whole thing. It should be easy to re-propose the specs for inclusion in Kilo once that opens up. You can grab a version of the repo before the removal commit, pull out the spec, update it and re-propose it. It also reduces the number of hoops to jump through to quickly search for a spec based on keywords. Otherwise we have to checkout a commit before the removal and then search. Thoughts, suggestions, or anecdotes about small sailboats? 1. https://github.com/openstack/neutron-specs/commit/77f8c806a49769322b02ea6017a1a2a39ef1cfd7 ___ 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
Re: [openstack-dev] [Neutron] keep old specs
Some of the specs had a significant amount of detail and thought put into them. It seems like a waste to bury them in a git tree history. By having them in a place where external parties (e.g. operators) can easily find them, they could get more visibility and feedback for any future revisions. Just being able to see that a feature was previously designed out and approved can prevent a future person from wasting a bunch of time typing up a new spec for the same feature. Hardly anyone is going to search deleted specs from two cycles ago if it requires checking out a commit. Why just restrict the whole repo to being documentation of what went in? If that's all the specs are for, why don't we just wait to create them until after the code merges? On Sep 15, 2014 6:16 AM, Kyle Mestery mest...@mestery.com wrote: On Mon, Sep 15, 2014 at 4:52 AM, Kevin Benton blak...@gmail.com wrote: I saw that the specs that didn't make the deadline for the feature freeze were removed from the tree completely.[1] For easier reference, can we instead revert that commit to restore them and then move them into a release specific folder called 'unimplemented' or something along those lines? No, I don't think there's value to keeping specs along which never made a release. The point of the specs repo is to track things which made the release. It will be nice in the future to browse through the specs for a release and see what specs were approved but didn't make it in time. Then if someone wants to try to propose it again, their patch can be to move the spec into the current cycle and then they only have to make revisions rather than redo the whole thing. It should be easy to re-propose the specs for inclusion in Kilo once that opens up. You can grab a version of the repo before the removal commit, pull out the spec, update it and re-propose it. It also reduces the number of hoops to jump through to quickly search for a spec based on keywords. Otherwise we have to checkout a commit before the removal and then search. Thoughts, suggestions, or anecdotes about small sailboats? 1. https://github.com/openstack/neutron-specs/commit/77f8c806a49769322b02ea6017a1a2a39ef1cfd7 ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] keep old specs
On 09/15/2014 10:01 AM, Kevin Benton wrote: Some of the specs had a significant amount of detail and thought put into them. It seems like a waste to bury them in a git tree history. By having them in a place where external parties (e.g. operators) can easily find them, they could get more visibility and feedback for any future revisions. Just being able to see that a feature was previously designed out and approved can prevent a future person from wasting a bunch of time typing up a new spec for the same feature. Hardly anyone is going to search deleted specs from two cycles ago if it requires checking out a commit. Why just restrict the whole repo to being documentation of what went in? If that's all the specs are for, why don't we just wait to create them until after the code merges? FWIW, I agree with you that it makes sense to keep them in a directory that makes it clear that they were not completed. There's a ton of useful info in them. Even if they get re-proposed, it's still useful to see the difference in the proposal as it evolved between releases. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
