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

Reply via email to