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
