Re: [openstack-dev] [Neutron] keep old specs

2014-09-17 Thread Aaron Rosen
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


Re: [openstack-dev] [Neutron] keep old specs

2014-09-15 Thread Kyle Mestery
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

2014-09-15 Thread Kevin Benton
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

2014-09-15 Thread Russell Bryant
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