On Mon, Jul 14, 2014 at 7:38 AM, Duncan Thomas <duncan.tho...@gmail.com> wrote:
> On 14 July 2014 07:11, Flavio Percoco <fla...@redhat.com> wrote: > > I almost fully agree with this last point. The bit I don't agree with is > > that there are some small refactor changes that aim to change a core > > piece of the project without any impact on the final user that are > > spec/blueprint worthy to explaining the motivation, expected results and > > drawbacks. > > > > To put it in another way. Developers are consumers of project's code, > > therefore the changes affecting the way developers interact with the > > code are also blueprint worth it, IMHO. > > The way I've been playing it on cinder is to ask for a spec if I'm > reviewing a patch that doesn't have one and I find myself questioning > the approach rather than the code. > Exactly. Also in Ironic, we're still feeling around when a spec is appropriate versus when it's just a bug, and I know we've had a few cases where both were created multiple solutions for the bug were found and I (or others on the core team) wanted some discussion around and justification for the proposed solution, the specs process seemed like a better medium for that discussion than the launchpad bug page. Of course, discussions like this one help us all to think about and find a good balance -- not every change requires a spec, but, as Flavio pointed out, sometimes even just refactoring code has enough impact on developers that a discussion would be beneficial. (I'm thinking of the nova db object code as one example...) Best, -D
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
