[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 <blak...@gmail.com> wrote on 09/15/2014 10:01:15 AM:
> From: Kevin Benton <blak...@gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>,
> 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" <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 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
