Re: [openstack-dev] [Neutron] keep old specs
For reference, I proposed a review which does this for nova last night: https://review.openstack.org/#/c/122109/ On Thu, Sep 18, 2014 at 8:42 AM, Aaron Rosen wrote: > 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 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 > -- Rackspace Australia ___ 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
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 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
Re: [openstack-dev] [Neutron] keep old specs
FWIW, they Keystone team had discussed this topic a few weeks ago. For the specs that didn't make FF, we pinged the author to see if it would be re-submitted for Kilo. If we received a yes, then we moved it to a separate Kilo folder [1][2][3]. Otherwise we were going to move the spec into a new folder 'untargeted'. We were concerned about the same reason Kevin mentioned, we didn't want to lose the detail and work that went into making the spec, and still make the intent of the work visible to others. Having a Kilo (N+1) or Untageted section at [4] could also save time and effort for other folks who would otherwise propose a similar topic. [1] https://github.com/openstack/keystone-specs/commit/dbc8545920de1b6e67f227d83b91edd42c36d4ea [2] https://github.com/openstack/keystone-specs/commit/7bd84f1723b40bf2bdca8f6e546e9500ec55fa62 [3] https://github.com/openstack/keystone-specs/commit/a7bf269c9afa63f694ff90c1bfb07d04b99f517b [4] http://specs.openstack.org/openstack/keystone-specs/ Kevin Benton wrote on 09/15/2014 10:01:15 AM: > From: Kevin Benton > To: "OpenStack Development Mailing List (not for usage questions)" > , > Date: 09/15/2014 10:07 AM > Subject: 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" wrote: > On Mon, Sep 15, 2014 at 4:52 AM, Kevin Benton 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 intoa 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 ratherthan 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 ___ 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
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" wrote: > On Mon, Sep 15, 2014 at 4:52 AM, Kevin Benton 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 Mon, Sep 15, 2014 at 4:52 AM, Kevin Benton 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
