On Fri, Nov 28, 2014 at 10:32 PM, Steve Gordon <[email protected]> wrote:
> ----- Original Message ----- > > From: "Deepak Shetty" <[email protected]> > > To: "OpenStack Development Mailing List (not for usage questions)" < > [email protected]> > > > > But isn't *-specs comes very early in the process where you have an > > idea/proposal of a feature, u don't have it yet implemented. Hence specs > > just end up with Para's on how the feature is supposed to work, but > doesn't > > include any real world screen shots as the code is not yet ready at that > > point of time. Along with patch it would make more sense, since the > author > > would have tested it so it isn't a big overhead to catch those cli screen > > shots and put it in a .txt or .md file so that patch reviewers can see > the > > patch in action and hence can review more effectively > > > > thanx, > > deepak > > Sure but in the original email you listed a number of other items, not > just CLI screen shots, including: > > > >> > 1) What changes are needed in manila.conf to make this work > > >> > 2) How to use the cli with this change incorporated > > >> > 3) Some screen shots of actual usage > > >> > 4) Any caution/caveats that one has to keep in mind while using this > > Ideally I see 1, 2, and 4 as things that should be added to the spec > (retrospectively if necessary) to ensure that it maintains an accurate > record of the feature. I can see potential benefits to including listings > of real world usage (3) in the client projects, but I don't think all of > the items listed belong there. > Agree, IMHO (2) and (3) will be possible only when patch is ready, others can be part of spec. thanx, deepak
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
