<tt><font size=2>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.</font></tt>
<br>
<br><tt><font size=2>[1] </font></tt><a href="https://github.com/openstack/keystone-specs/commit/dbc8545920de1b6e67f227d83b91edd42c36d4ea"><tt><font size=2>https://github.com/openstack/keystone-specs/commit/dbc8545920de1b6e67f227d83b91edd42c36d4ea</font></tt></a>
<br><tt><font size=2>[2] </font></tt><a href="https://github.com/openstack/keystone-specs/commit/7bd84f1723b40bf2bdca8f6e546e9500ec55fa62"><tt><font size=2>https://github.com/openstack/keystone-specs/commit/7bd84f1723b40bf2bdca8f6e546e9500ec55fa62</font></tt></a>
<br><tt><font size=2>[3] </font></tt><a href="https://github.com/openstack/keystone-specs/commit/a7bf269c9afa63f694ff90c1bfb07d04b99f517b"><tt><font size=2>https://github.com/openstack/keystone-specs/commit/a7bf269c9afa63f694ff90c1bfb07d04b99f517b</font></tt></a>
<br><tt><font size=2>[4] </font></tt><a href="http://specs.openstack.org/openstack/keystone-specs/"><tt><font size=2>http://specs.openstack.org/openstack/keystone-specs/</font></tt></a>
<br>
<br><tt><font size=2>Kevin Benton <blak111@gmail.com> wrote on 09/15/2014
10:01:15 AM:<br>
<br>
> From: Kevin Benton <blak111@gmail.com></font></tt>
<br><tt><font size=2>> To: "OpenStack Development Mailing List
(not for usage questions)" <br>
> <openstack-dev@lists.openstack.org>, </font></tt>
<br><tt><font size=2>> Date: 09/15/2014 10:07 AM</font></tt>
<br><tt><font size=2>> Subject: Re: [openstack-dev] [Neutron] keep old
specs</font></tt>
<br><tt><font size=2>> <br>
> Some of the specs had a significant amount of detail and thought put<br>
> into them. It seems like a waste to bury them in a git tree history.
</font></tt>
<br><tt><font size=2>> By having them in a place where external parties
(e.g. operators) <br>
> can easily find them, they could get more visibility and feedback
<br>
> for any future revisions. Just being able to see that a feature was
<br>
> previously designed out and approved can prevent a future person <br>
> from wasting a bunch of time typing up a new spec for the same <br>
> feature. Hardly anyone is going to search deleted specs from two <br>
> cycles ago if it requires checking out a commit. </font></tt>
<br><tt><font size=2>> Why just restrict the whole repo to being documentation
of what went<br>
> in?  If that's all the specs are for, why don't we just wait
to <br>
> create them until after the code merges? </font></tt>
<br>
<br><tt><font size=2>> On Sep 15, 2014 6:16 AM, "Kyle Mestery"
<mestery@mestery.com> wrote:</font></tt>
<br><tt><font size=2>> On Mon, Sep 15, 2014 at 4:52 AM, Kevin Benton
<blak111@gmail.com> wrote:<br>
> > I saw that the specs that didn't make the deadline for the feature
freeze<br>
> > were removed from the tree completely.[1] For easier reference,
can we<br>
> > instead revert that commit to restore them and then move them
intoa release<br>
> > specific folder called 'unimplemented' or something along those
lines?<br>
> ><br>
> No, I don't think there's value to keeping specs along which never<br>
> made a release. The point of the specs repo is to track things which<br>
> made the release.<br>
> <br>
> > It will be nice in the future to browse through the specs for
a release and<br>
> > see what specs were approved but didn't make it in time. Then
if someone<br>
> > wants to try to propose it again, their patch can be to move
the spec into<br>
> > the current cycle and then they only have to make revisions ratherthan
redo<br>
> > the whole thing.<br>
> ><br>
> It should be easy to re-propose the specs for inclusion in Kilo once<br>
> that opens up. You can grab a version of the repo before the removal<br>
> commit, pull out the spec, update it and re-propose it.<br>
> <br>
> > It also reduces the number of hoops to jump through to quickly
search for a<br>
> > spec based on keywords. Otherwise we have to checkout a commit
before the<br>
> > removal and then search.<br>
> ><br>
> > Thoughts, suggestions, or anecdotes about small sailboats?<br>
> ><br>
> > 1.<br>
> > </font></tt><a href="https://github.com/openstack/neutron-specs/commit/"><tt><font size=2>https://github.com/openstack/neutron-specs/commit/</font></tt></a><tt><font size=2><br>
> 77f8c806a49769322b02ea6017a1a2a39ef1cfd7<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > OpenStack-dev@lists.openstack.org<br>
> > </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
> ><br>
> <br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
</font></tt>