Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects
On Sun, Jul 20, 2014, at 04:35 PM, Jay S. Bryant wrote: Thanks Duncan and also Dolph, I should have made the question broader. :-) On Wed, 2014-07-16 at 13:22 +0100, Duncan Thomas wrote: On 16 July 2014 03:57, Jay S. Bryant jsbry...@electronicjungle.net wrote: John, So you have said a few times that the specs are a learning process. What do you feel with have learned thus far using specs? I'm not John, but I'm going to answer as if you'd addressed the question wider: - Specs can definitely help flesh out ideas and are much better than blueprints as a way of tracking concerns, questions, etc I feel I have better knowledge of what is being worked thanks to the specs. This may partially be because I was also involved from the summit on for the first time. They definitely are better for fleshing out ideas and discussing concerns. - We as a community are rather shy about making decisions as individuals, even low risk ones like 'Does this seem to require a spec' - if there doesn't seem to be value in a spec, don't do one unless somebody asks for one Agreed. I think we all need to be less shy about making decisions and voicing them. At least in Cinder. :-) - Not all questions can be answered at spec time, sometimes you need to go bash out some code to see what works, then circle again - Careful planning reduces velocity. No significant evidence either way as to whether it improves quality, but my gut feeling is that it does. We need to figure out what tradeoffs on either scale we're happy to make, and perhaps that answer is different based on the area of code being touched and the date (e.g. a change that doesn't affect external APIs in J-1 might need less careful planning than a change in J-3. API changes or additions need more discussion and eyes on than none-API changes) I think, through this development cycle we are starting to narrow down what really needs a spec. I think it would be good to perhaps have a Lessons Learned session at the K summit on the specs and try to better define expectations for use in the future. I feel it has slowed, or at least focused development. That has been good. We should make that a cross-project session, so we can learn from what the other projects did, too. Doug - Specs are terrible for tracking work items, but no worse than blueprints Agreed. - Multiple people might choose to work on the same blueprint in parallel - this is going to happen, isn't necessarily rude and the correct solution to competing patches is entirely subjective ___ 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
Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects
Thanks Duncan and also Dolph, I should have made the question broader. :-) On Wed, 2014-07-16 at 13:22 +0100, Duncan Thomas wrote: On 16 July 2014 03:57, Jay S. Bryant jsbry...@electronicjungle.net wrote: John, So you have said a few times that the specs are a learning process. What do you feel with have learned thus far using specs? I'm not John, but I'm going to answer as if you'd addressed the question wider: - Specs can definitely help flesh out ideas and are much better than blueprints as a way of tracking concerns, questions, etc I feel I have better knowledge of what is being worked thanks to the specs. This may partially be because I was also involved from the summit on for the first time. They definitely are better for fleshing out ideas and discussing concerns. - We as a community are rather shy about making decisions as individuals, even low risk ones like 'Does this seem to require a spec' - if there doesn't seem to be value in a spec, don't do one unless somebody asks for one Agreed. I think we all need to be less shy about making decisions and voicing them. At least in Cinder. :-) - Not all questions can be answered at spec time, sometimes you need to go bash out some code to see what works, then circle again - Careful planning reduces velocity. No significant evidence either way as to whether it improves quality, but my gut feeling is that it does. We need to figure out what tradeoffs on either scale we're happy to make, and perhaps that answer is different based on the area of code being touched and the date (e.g. a change that doesn't affect external APIs in J-1 might need less careful planning than a change in J-3. API changes or additions need more discussion and eyes on than none-API changes) I think, through this development cycle we are starting to narrow down what really needs a spec. I think it would be good to perhaps have a Lessons Learned session at the K summit on the specs and try to better define expectations for use in the future. I feel it has slowed, or at least focused development. That has been good. - Specs are terrible for tracking work items, but no worse than blueprints Agreed. - Multiple people might choose to work on the same blueprint in parallel - this is going to happen, isn't necessarily rude and the correct solution to competing patches is entirely subjective ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects
On 16 July 2014 03:57, Jay S. Bryant jsbry...@electronicjungle.net wrote: John, So you have said a few times that the specs are a learning process. What do you feel with have learned thus far using specs? I'm not John, but I'm going to answer as if you'd addressed the question wider: - Specs can definitely help flesh out ideas and are much better than blueprints as a way of tracking concerns, questions, etc - We as a community are rather shy about making decisions as individuals, even low risk ones like 'Does this seem to require a spec' - if there doesn't seem to be value in a spec, don't do one unless somebody asks for one - Not all questions can be answered at spec time, sometimes you need to go bash out some code to see what works, then circle again - Careful planning reduces velocity. No significant evidence either way as to whether it improves quality, but my gut feeling is that it does. We need to figure out what tradeoffs on either scale we're happy to make, and perhaps that answer is different based on the area of code being touched and the date (e.g. a change that doesn't affect external APIs in J-1 might need less careful planning than a change in J-3. API changes or additions need more discussion and eyes on than none-API changes) - Specs are terrible for tracking work items, but no worse than blueprints - Multiple people might choose to work on the same blueprint in parallel - this is going to happen, isn't necessarily rude and the correct solution to competing patches is entirely subjective ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects
On 15 July 2014 15:01, Erlon Cruz sombra...@gmail.com wrote: Leave the option about when to submit a design vs. when to submit code to the contributor. That's is what is being done so far right? Hard to know (mainly if you are a first contributor) when a change is big or not. I can see lots of patches being submitted without the spec getting rejected and being asked to a SPEC. This line between large-needs-spec/small-dont-need can not be subjective. Of course it is subjective, like good code style and bunch of other things we review for. If it's hard to know, guess, it doesn't hurt either way - an unnecessary spec that is really simple should get approved quickly enough, and if you need a spec but haven't done one then somebody will ask for one soon enough. Why launchpad doesn't have a better discussion capability? I mean, users should be able to post comments on the whiteboard of the vluprint/bug. Then a quick discussion there could be used to define if a SPEC would be needed. Launchpad has proven terrible for this, which is a strong driver for the spec process in the first place -- Duncan Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects
Leave the option about when to submit a design vs. when to submit code to the contributor. That's is what is being done so far right? Hard to know (mainly if you are a first contributor) when a change is big or not. I can see lots of patches being submitted without the spec getting rejected and being asked to a SPEC. This line between large-needs-spec/small-dont-need can not be subjective. Why launchpad doesn't have a better discussion capability? I mean, users should be able to post comments on the whiteboard of the vluprint/bug. Then a quick discussion there could be used to define if a SPEC would be needed. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects
John, So you have said a few times that the specs are a learning process. What do you feel with have learned thus far using specs? I think you had the hope that it would help organize targeting blueprints and not missing things for a release. Do you feel that is working? I would like to hear more about how you feel this is working. Personally, initially, having specs made sense given that they are a better way to spark discussion around a design change. They were working well early in the release for that purpose. Now, however, they have become a point of confusion. There is the question of when is just a BP sufficient versus when is neither required. I think this is part of the learning process. Just worth having discussion so we know for the next round what is needed when. Jay On Sun, 2014-07-13 at 16:31 -0600, John Griffith wrote: On Sun, Jul 13, 2014 at 8:01 AM, Dolph Mathews dolph.math...@gmail.com wrote: On Wed, Jul 9, 2014 at 1:54 PM, Jay Bryant jsbry...@electronicjungle.net wrote: I had been under the impression that all BPs we going to require a spec. I, however, was made are in today's cinder meeting that we are only requiring specs for changes that change the user's interaction with the system or are a large change that touches the broader cinder code base. That's generally where we use blueprints in Keystone, anyway. If the change has no impact on end users, deployers or other projects, then it doesn't need a spec/blueprint. For example, a refactor only affects developers of Keystone, so I'd argue that blueprints are unnecessary. The premise of a large change that touches the broader ... code base requiring a blueprint is flawed though - we don't want to review large changes anyway ;) Just have to say I really like this last point... also even though I'm the one who made that statement the problem with it is that it's rather subjective. My position is and continues to be that specs are a learning process, we're hammering it out and these conversations on the ML are helpful. This seemsto make sense to me. The user's commit message and unit tests should show the thought of the changes impact. Jay On Jul 9, 2014 7:57 AM, Dugger, Donald D donald.d.dug...@intel.com wrote: Much as I dislike the overhead and the extra latency involved (now you need to have a review cycle for the spec plus the review cycle for the patch itself) I agreed with the `small features require small specs’. The problem is that even a small change can have a big impact. Forcing people to create a spec even for small features means that it’s very clear that the implications of the feature have been thought about and addressed. Note that there is a similar issue with bugs. I would expect that a patch to fix a bug would have to have a corresponding bug report. Just accepting patches with no known justification seems like the wrong way to go. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 From: Dolph Mathews [mailto:dolph.math...@gmail.com] Sent: Tuesday, July 1, 2014 11:02 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects The argument has been made in the past that small features will require correspondingly small specs. If there's a counter-argument to this example (a small feature
Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects
) Subject: Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects The argument has been made in the past that small features will require correspondingly small specs. If there's a counter-argument to this example (a small feature requiring a relatively large amount of spec effort), I'd love to have links to both the spec and the resulting implementation so we can discuss exactly why the spec was an unnecessary additional effort. On Tue, Jul 1, 2014 at 10:30 AM, Jason Dunsmore jason.dunsm...@rackspace.com javascript:; wrote: On Mon, Jun 30 2014, Joshua Harlow wrote: There is a balance here that needs to be worked out and I've seen specs start to turn into requirements for every single patch (even if the patch is pretty small). I hope we can rework the 'balance in the force' to avoid being so strict that every little thing requires a spec. This will not end well for us as a community. How have others thought the spec process has worked out so far? To much overhead, to little…? I personally am of the opinion that specs should be used for large topics (defining large is of course arbitrary); and I hope we find the right balance to avoid scaring everyone away from working with openstack. Maybe all of this is part of openstack maturing, I'm not sure, but it'd be great if we could have some guidelines around when is a spec needed and when isn't it and take it into consideration when requesting a spec that the person you have requested may get frustrated and just leave the community (and we must not have this happen) if you ask for it without explaining why and how clearly. +1 I think specs are too much overhead for small features. A set of guidelines about when specs are needed would be sufficient. Leave the option about when to submit a design vs. when to submit code to the contributor. Jason ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org javascript:; http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org javascript:; http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org javascript:; http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org javascript:; http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org javascript:; http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev
Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects
On 07/13/2014 04:01 PM, Dolph Mathews wrote: On Wed, Jul 9, 2014 at 1:54 PM, Jay Bryant jsbry...@electronicjungle.net mailto:jsbry...@electronicjungle.net wrote: I had been under the impression that all BPs we going to require a spec. I, however, was made are in today's cinder meeting that we are only requiring specs for changes that change the user's interaction with the system or are a large change that touches the broader cinder code base. That's generally where we use blueprints in Keystone, anyway. If the change has no impact on end users, deployers or other projects, then it doesn't need a spec/blueprint. For example, a refactor only affects developers of Keystone, so I'd argue that blueprints are unnecessary. The premise of a large change that touches the broader ... code base requiring a blueprint is flawed though - we don't want to review large changes anyway ;) 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. Flavio -- @flaper87 Flavio Percoco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects
On Mon, Jul 14, 2014 at 8: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. I think it is fair to say that core reviewers shouldn't be afraid to ask for a spec at any time they think it will help, guidelines aside. This allows contributors to attempt the lightweight process and skip the spec if they don't expect to need one. +1 This is exactly what I was hoping to see in Cinder at least. -- Duncan Thomas ___ 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
Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects
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. I think it is fair to say that core reviewers shouldn't be afraid to ask for a spec at any time they think it will help, guidelines aside. This allows contributors to attempt the lightweight process and skip the spec if they don't expect to need one. -- Duncan Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects
On Wed, Jul 9, 2014 at 1:54 PM, Jay Bryant jsbry...@electronicjungle.net wrote: I had been under the impression that all BPs we going to require a spec. I, however, was made are in today's cinder meeting that we are only requiring specs for changes that change the user's interaction with the system or are a large change that touches the broader cinder code base. That's generally where we use blueprints in Keystone, anyway. If the change has no impact on end users, deployers or other projects, then it doesn't need a spec/blueprint. For example, a refactor only affects developers of Keystone, so I'd argue that blueprints are unnecessary. The premise of a large change that touches the broader ... code base requiring a blueprint is flawed though - we don't want to review large changes anyway ;) This seemsto make sense to me. The user's commit message and unit tests should show the thought of the changes impact. Jay On Jul 9, 2014 7:57 AM, Dugger, Donald D donald.d.dug...@intel.com wrote: Much as I dislike the overhead and the extra latency involved (now you need to have a review cycle for the spec plus the review cycle for the patch itself) I agreed with the `small features require small specs’. The problem is that even a small change can have a big impact. Forcing people to create a spec even for small features means that it’s very clear that the implications of the feature have been thought about and addressed. Note that there is a similar issue with bugs. I would expect that a patch to fix a bug would have to have a corresponding bug report. Just accepting patches with no known justification seems like the wrong way to go. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 *From:* Dolph Mathews [mailto:dolph.math...@gmail.com] *Sent:* Tuesday, July 1, 2014 11:02 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects The argument has been made in the past that small features will require correspondingly small specs. If there's a counter-argument to this example (a small feature requiring a relatively large amount of spec effort), I'd love to have links to both the spec and the resulting implementation so we can discuss exactly why the spec was an unnecessary additional effort. On Tue, Jul 1, 2014 at 10:30 AM, Jason Dunsmore jason.dunsm...@rackspace.com wrote: On Mon, Jun 30 2014, Joshua Harlow wrote: There is a balance here that needs to be worked out and I've seen specs start to turn into requirements for every single patch (even if the patch is pretty small). I hope we can rework the 'balance in the force' to avoid being so strict that every little thing requires a spec. This will not end well for us as a community. How have others thought the spec process has worked out so far? To much overhead, to little…? I personally am of the opinion that specs should be used for large topics (defining large is of course arbitrary); and I hope we find the right balance to avoid scaring everyone away from working with openstack. Maybe all of this is part of openstack maturing, I'm not sure, but it'd be great if we could have some guidelines around when is a spec needed and when isn't it and take it into consideration when requesting a spec that the person you have requested may get frustrated and just leave the community (and we must not have this happen) if you ask for it without explaining why and how clearly. +1 I think specs are too much overhead for small features. A set of guidelines about when specs are needed would be sufficient. Leave the option about when to submit a design vs. when to submit code to the contributor. Jason ___ 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
Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects
On Sun, Jul 13, 2014 at 8:01 AM, Dolph Mathews dolph.math...@gmail.com wrote: On Wed, Jul 9, 2014 at 1:54 PM, Jay Bryant jsbry...@electronicjungle.net wrote: I had been under the impression that all BPs we going to require a spec. I, however, was made are in today's cinder meeting that we are only requiring specs for changes that change the user's interaction with the system or are a large change that touches the broader cinder code base. That's generally where we use blueprints in Keystone, anyway. If the change has no impact on end users, deployers or other projects, then it doesn't need a spec/blueprint. For example, a refactor only affects developers of Keystone, so I'd argue that blueprints are unnecessary. The premise of a large change that touches the broader ... code base requiring a blueprint is flawed though - we don't want to review large changes anyway ;) Just have to say I really like this last point... also even though I'm the one who made that statement the problem with it is that it's rather subjective. My position is and continues to be that specs are a learning process, we're hammering it out and these conversations on the ML are helpful. This seemsto make sense to me. The user's commit message and unit tests should show the thought of the changes impact. Jay On Jul 9, 2014 7:57 AM, Dugger, Donald D donald.d.dug...@intel.com wrote: Much as I dislike the overhead and the extra latency involved (now you need to have a review cycle for the spec plus the review cycle for the patch itself) I agreed with the `small features require small specs’. The problem is that even a small change can have a big impact. Forcing people to create a spec even for small features means that it’s very clear that the implications of the feature have been thought about and addressed. Note that there is a similar issue with bugs. I would expect that a patch to fix a bug would have to have a corresponding bug report. Just accepting patches with no known justification seems like the wrong way to go. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 *From:* Dolph Mathews [mailto:dolph.math...@gmail.com] *Sent:* Tuesday, July 1, 2014 11:02 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects The argument has been made in the past that small features will require correspondingly small specs. If there's a counter-argument to this example (a small feature requiring a relatively large amount of spec effort), I'd love to have links to both the spec and the resulting implementation so we can discuss exactly why the spec was an unnecessary additional effort. On Tue, Jul 1, 2014 at 10:30 AM, Jason Dunsmore jason.dunsm...@rackspace.com wrote: On Mon, Jun 30 2014, Joshua Harlow wrote: There is a balance here that needs to be worked out and I've seen specs start to turn into requirements for every single patch (even if the patch is pretty small). I hope we can rework the 'balance in the force' to avoid being so strict that every little thing requires a spec. This will not end well for us as a community. How have others thought the spec process has worked out so far? To much overhead, to little…? I personally am of the opinion that specs should be used for large topics (defining large is of course arbitrary); and I hope we find the right balance to avoid scaring everyone away from working with openstack. Maybe all of this is part of openstack maturing, I'm not sure, but it'd be great if we could have some guidelines around when is a spec needed and when isn't it and take it into consideration when requesting a spec that the person you have requested may get frustrated and just leave the community (and we must not have this happen) if you ask for it without explaining why and how clearly. +1 I think specs are too much overhead for small features. A set of guidelines about when specs are needed would be sufficient. Leave the option about when to submit a design vs. when to submit code to the contributor. Jason ___ 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
Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects
I had been under the impression that all BPs we going to require a spec. I, however, was made are in today's cinder meeting that we are only requiring specs for changes that change the user's interaction with the system or are a large change that touches the broader cinder code base. This seemsto make sense to me. The user's commit message and unit tests should show the thought of the changes impact. Jay On Jul 9, 2014 7:57 AM, Dugger, Donald D donald.d.dug...@intel.com wrote: Much as I dislike the overhead and the extra latency involved (now you need to have a review cycle for the spec plus the review cycle for the patch itself) I agreed with the `small features require small specs’. The problem is that even a small change can have a big impact. Forcing people to create a spec even for small features means that it’s very clear that the implications of the feature have been thought about and addressed. Note that there is a similar issue with bugs. I would expect that a patch to fix a bug would have to have a corresponding bug report. Just accepting patches with no known justification seems like the wrong way to go. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 *From:* Dolph Mathews [mailto:dolph.math...@gmail.com] *Sent:* Tuesday, July 1, 2014 11:02 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects The argument has been made in the past that small features will require correspondingly small specs. If there's a counter-argument to this example (a small feature requiring a relatively large amount of spec effort), I'd love to have links to both the spec and the resulting implementation so we can discuss exactly why the spec was an unnecessary additional effort. On Tue, Jul 1, 2014 at 10:30 AM, Jason Dunsmore jason.dunsm...@rackspace.com wrote: On Mon, Jun 30 2014, Joshua Harlow wrote: There is a balance here that needs to be worked out and I've seen specs start to turn into requirements for every single patch (even if the patch is pretty small). I hope we can rework the 'balance in the force' to avoid being so strict that every little thing requires a spec. This will not end well for us as a community. How have others thought the spec process has worked out so far? To much overhead, to little…? I personally am of the opinion that specs should be used for large topics (defining large is of course arbitrary); and I hope we find the right balance to avoid scaring everyone away from working with openstack. Maybe all of this is part of openstack maturing, I'm not sure, but it'd be great if we could have some guidelines around when is a spec needed and when isn't it and take it into consideration when requesting a spec that the person you have requested may get frustrated and just leave the community (and we must not have this happen) if you ask for it without explaining why and how clearly. +1 I think specs are too much overhead for small features. A set of guidelines about when specs are needed would be sufficient. Leave the option about when to submit a design vs. when to submit code to the contributor. Jason ___ 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
Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects
IMO, 'spec' is indeed a good idea and indeed useful for tracking features, although it's a little tough for us not using English as native language. But we still need to identify these 'small features', and core reviewers do some review, then approve them ASAP, so that we can avoid to waste a lot of time to wait for code implementaion. 2014-07-02 2:08 GMT+08:00 Devananda van der Veen devananda@gmail.com: On Tue, Jul 1, 2014 at 10:02 AM, Dolph Mathews dolph.math...@gmail.com wrote: The argument has been made in the past that small features will require correspondingly small specs. If there's a counter-argument to this example (a small feature requiring a relatively large amount of spec effort), I'd love to have links to both the spec and the resulting implementation so we can discuss exactly why the spec was an unnecessary additional effort. On Tue, Jul 1, 2014 at 10:30 AM, Jason Dunsmore jason.dunsm...@rackspace.com wrote: On Mon, Jun 30 2014, Joshua Harlow wrote: There is a balance here that needs to be worked out and I've seen specs start to turn into requirements for every single patch (even if the patch is pretty small). I hope we can rework the 'balance in the force' to avoid being so strict that every little thing requires a spec. This will not end well for us as a community. How have others thought the spec process has worked out so far? To much overhead, to little…? I personally am of the opinion that specs should be used for large topics (defining large is of course arbitrary); and I hope we find the right balance to avoid scaring everyone away from working with openstack. Maybe all of this is part of openstack maturing, I'm not sure, but it'd be great if we could have some guidelines around when is a spec needed and when isn't it and take it into consideration when requesting a spec that the person you have requested may get frustrated and just leave the community (and we must not have this happen) if you ask for it without explaining why and how clearly. +1 I think specs are too much overhead for small features. A set of guidelines about when specs are needed would be sufficient. Leave the option about when to submit a design vs. when to submit code to the contributor. Jason Yes, there needs to be balance, but as far as I have seen, folks are finding the balance around when to require specs within each of the project teams. I am curious if there are any specific examples where a project's core team required a large spec for what they considered to be a small feature. I also feel strongly that the spec process has been very helpful for the projects that I'm involved in for fleshing out the implications of changes which may at first glance seem small, by requiring both proposers and reviewers to think about and discuss the wider ramifications for changes in a way that simply reviewing code often does not. Just my 2c, Devananda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Regards! --- Lingxian Kong ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects
On Wed, Jul 2, 2014 at 7:08 AM, Lingxian Kong anlin.k...@gmail.com wrote: IMO, 'spec' is indeed a good idea and indeed useful for tracking features, although it's a little tough for us not using English as native language. But we still need to identify these 'small features', and core reviewers do some review, then approve them ASAP, so that we can avoid to waste a lot of time to wait for code implementaion. If you are confident in the acceptability of your spec, I don't think you should necessarily wait to begin work on an implementation. In fact, I'd suggest that you not wait at all. An implementation can help illustrate a spec, find it's weak points, or even identify unimplementable parts of a spec. That said, you should maintain such an implementation in Gerrit as a Work In Progress so that it is not accidentally merged ahead of the spec. 2014-07-02 2:08 GMT+08:00 Devananda van der Veen devananda@gmail.com : On Tue, Jul 1, 2014 at 10:02 AM, Dolph Mathews dolph.math...@gmail.com wrote: The argument has been made in the past that small features will require correspondingly small specs. If there's a counter-argument to this example (a small feature requiring a relatively large amount of spec effort), I'd love to have links to both the spec and the resulting implementation so we can discuss exactly why the spec was an unnecessary additional effort. On Tue, Jul 1, 2014 at 10:30 AM, Jason Dunsmore jason.dunsm...@rackspace.com wrote: On Mon, Jun 30 2014, Joshua Harlow wrote: There is a balance here that needs to be worked out and I've seen specs start to turn into requirements for every single patch (even if the patch is pretty small). I hope we can rework the 'balance in the force' to avoid being so strict that every little thing requires a spec. This will not end well for us as a community. How have others thought the spec process has worked out so far? To much overhead, to little…? I personally am of the opinion that specs should be used for large topics (defining large is of course arbitrary); and I hope we find the right balance to avoid scaring everyone away from working with openstack. Maybe all of this is part of openstack maturing, I'm not sure, but it'd be great if we could have some guidelines around when is a spec needed and when isn't it and take it into consideration when requesting a spec that the person you have requested may get frustrated and just leave the community (and we must not have this happen) if you ask for it without explaining why and how clearly. +1 I think specs are too much overhead for small features. A set of guidelines about when specs are needed would be sufficient. Leave the option about when to submit a design vs. when to submit code to the contributor. Jason Yes, there needs to be balance, but as far as I have seen, folks are finding the balance around when to require specs within each of the project teams. I am curious if there are any specific examples where a project's core team required a large spec for what they considered to be a small feature. I also feel strongly that the spec process has been very helpful for the projects that I'm involved in for fleshing out the implications of changes which may at first glance seem small, by requiring both proposers and reviewers to think about and discuss the wider ramifications for changes in a way that simply reviewing code often does not. Just my 2c, Devananda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Regards! --- Lingxian Kong ___ 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
Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects
Excerpts from Dolph Mathews's message of 2014-07-01 10:02:13 -0700: The argument has been made in the past that small features will require correspondingly small specs. If there's a counter-argument to this example (a small feature requiring a relatively large amount of spec effort), I'd love to have links to both the spec and the resulting implementation so we can discuss exactly why the spec was an unnecessary additional effort. Indeed. The line to be drawn isn't around the size, IMO, but around communication. Nobody has the bandwidth to watch all of the git logs. Nobody has the bandwidth to poll all of the developers what has changed in the interfaces available. So the line for me is whether or not users and operators will need to know something is under way and may want to comment _before_ a change to an interface is made. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects
On Mon, Jun 30 2014, Joshua Harlow wrote: There is a balance here that needs to be worked out and I've seen specs start to turn into requirements for every single patch (even if the patch is pretty small). I hope we can rework the 'balance in the force' to avoid being so strict that every little thing requires a spec. This will not end well for us as a community. How have others thought the spec process has worked out so far? To much overhead, to little…? I personally am of the opinion that specs should be used for large topics (defining large is of course arbitrary); and I hope we find the right balance to avoid scaring everyone away from working with openstack. Maybe all of this is part of openstack maturing, I'm not sure, but it'd be great if we could have some guidelines around when is a spec needed and when isn't it and take it into consideration when requesting a spec that the person you have requested may get frustrated and just leave the community (and we must not have this happen) if you ask for it without explaining why and how clearly. +1 I think specs are too much overhead for small features. A set of guidelines about when specs are needed would be sufficient. Leave the option about when to submit a design vs. when to submit code to the contributor. Jason ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects
The argument has been made in the past that small features will require correspondingly small specs. If there's a counter-argument to this example (a small feature requiring a relatively large amount of spec effort), I'd love to have links to both the spec and the resulting implementation so we can discuss exactly why the spec was an unnecessary additional effort. On Tue, Jul 1, 2014 at 10:30 AM, Jason Dunsmore jason.dunsm...@rackspace.com wrote: On Mon, Jun 30 2014, Joshua Harlow wrote: There is a balance here that needs to be worked out and I've seen specs start to turn into requirements for every single patch (even if the patch is pretty small). I hope we can rework the 'balance in the force' to avoid being so strict that every little thing requires a spec. This will not end well for us as a community. How have others thought the spec process has worked out so far? To much overhead, to little…? I personally am of the opinion that specs should be used for large topics (defining large is of course arbitrary); and I hope we find the right balance to avoid scaring everyone away from working with openstack. Maybe all of this is part of openstack maturing, I'm not sure, but it'd be great if we could have some guidelines around when is a spec needed and when isn't it and take it into consideration when requesting a spec that the person you have requested may get frustrated and just leave the community (and we must not have this happen) if you ask for it without explaining why and how clearly. +1 I think specs are too much overhead for small features. A set of guidelines about when specs are needed would be sufficient. Leave the option about when to submit a design vs. when to submit code to the contributor. Jason ___ 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
Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects
Much as I dislike the overhead and the extra latency involved (now you need to have a review cycle for the spec plus the review cycle for the patch itself) I agreed with the `small features require small specs’. The problem is that even a small change can have a big impact. Forcing people to create a spec even for small features means that it’s very clear that the implications of the feature have been thought about and addressed. Note that there is a similar issue with bugs. I would expect that a patch to fix a bug would have to have a corresponding bug report. Just accepting patches with no known justification seems like the wrong way to go. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 From: Dolph Mathews [mailto:dolph.math...@gmail.com] Sent: Tuesday, July 1, 2014 11:02 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects The argument has been made in the past that small features will require correspondingly small specs. If there's a counter-argument to this example (a small feature requiring a relatively large amount of spec effort), I'd love to have links to both the spec and the resulting implementation so we can discuss exactly why the spec was an unnecessary additional effort. On Tue, Jul 1, 2014 at 10:30 AM, Jason Dunsmore jason.dunsm...@rackspace.commailto:jason.dunsm...@rackspace.com wrote: On Mon, Jun 30 2014, Joshua Harlow wrote: There is a balance here that needs to be worked out and I've seen specs start to turn into requirements for every single patch (even if the patch is pretty small). I hope we can rework the 'balance in the force' to avoid being so strict that every little thing requires a spec. This will not end well for us as a community. How have others thought the spec process has worked out so far? To much overhead, to little…? I personally am of the opinion that specs should be used for large topics (defining large is of course arbitrary); and I hope we find the right balance to avoid scaring everyone away from working with openstack. Maybe all of this is part of openstack maturing, I'm not sure, but it'd be great if we could have some guidelines around when is a spec needed and when isn't it and take it into consideration when requesting a spec that the person you have requested may get frustrated and just leave the community (and we must not have this happen) if you ask for it without explaining why and how clearly. +1 I think specs are too much overhead for small features. A set of guidelines about when specs are needed would be sufficient. Leave the option about when to submit a design vs. when to submit code to the contributor. Jason ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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
Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects
On Tue, Jul 1, 2014 at 10:02 AM, Dolph Mathews dolph.math...@gmail.com wrote: The argument has been made in the past that small features will require correspondingly small specs. If there's a counter-argument to this example (a small feature requiring a relatively large amount of spec effort), I'd love to have links to both the spec and the resulting implementation so we can discuss exactly why the spec was an unnecessary additional effort. On Tue, Jul 1, 2014 at 10:30 AM, Jason Dunsmore jason.dunsm...@rackspace.com wrote: On Mon, Jun 30 2014, Joshua Harlow wrote: There is a balance here that needs to be worked out and I've seen specs start to turn into requirements for every single patch (even if the patch is pretty small). I hope we can rework the 'balance in the force' to avoid being so strict that every little thing requires a spec. This will not end well for us as a community. How have others thought the spec process has worked out so far? To much overhead, to little…? I personally am of the opinion that specs should be used for large topics (defining large is of course arbitrary); and I hope we find the right balance to avoid scaring everyone away from working with openstack. Maybe all of this is part of openstack maturing, I'm not sure, but it'd be great if we could have some guidelines around when is a spec needed and when isn't it and take it into consideration when requesting a spec that the person you have requested may get frustrated and just leave the community (and we must not have this happen) if you ask for it without explaining why and how clearly. +1 I think specs are too much overhead for small features. A set of guidelines about when specs are needed would be sufficient. Leave the option about when to submit a design vs. when to submit code to the contributor. Jason Yes, there needs to be balance, but as far as I have seen, folks are finding the balance around when to require specs within each of the project teams. I am curious if there are any specific examples where a project's core team required a large spec for what they considered to be a small feature. I also feel strongly that the spec process has been very helpful for the projects that I'm involved in for fleshing out the implications of changes which may at first glance seem small, by requiring both proposers and reviewers to think about and discuss the wider ramifications for changes in a way that simply reviewing code often does not. Just my 2c, Devananda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all][specs] Please stop doing specs for any changes in projects
Hi all, Specs are interesting idea, that may be really useful, when you need to discuss large topics: 1) work on API 2) Large refactoring 3) Large features 4) Performance, scale, ha, security issues that requires big changes And I really dislike idea of adding spec for every patch. Especially when changes (features) are small, don't affect too much, and they are optional. It really kills OpenStack. And will drastically slow down process of contribution and reduce amount of contributors. Thanks. Best regards, Boris Pavlovic ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects
Thanks boris for starting this topic, There is a balance here that needs to be worked out and I've seen specs start to turn into requirements for every single patch (even if the patch is pretty small). I hope we can rework the 'balance in the force' to avoid being so strict that every little thing requires a spec. This will not end well for us as a community. How have others thought the spec process has worked out so far? To much overhead, to little…? I personally am of the opinion that specs should be used for large topics (defining large is of course arbitrary); and I hope we find the right balance to avoid scaring everyone away from working with openstack. Maybe all of this is part of openstack maturing, I'm not sure, but it'd be great if we could have some guidelines around when is a spec needed and when isn't it and take it into consideration when requesting a spec that the person you have requested may get frustrated and just leave the community (and we must not have this happen) if you ask for it without explaining why and how clearly. From: Boris Pavlovic bpavlo...@mirantis.commailto:bpavlo...@mirantis.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Monday, June 30, 2014 at 2:11 PM To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects Hi all, Specs are interesting idea, that may be really useful, when you need to discuss large topics: 1) work on API 2) Large refactoring 3) Large features 4) Performance, scale, ha, security issues that requires big changes And I really dislike idea of adding spec for every patch. Especially when changes (features) are small, don't affect too much, and they are optional. It really kills OpenStack. And will drastically slow down process of contribution and reduce amount of contributors. Thanks. Best regards, Boris Pavlovic ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][specs] Please stop doing specs for any changes in projects
Excerpts from Boris Pavlovic's message of 2014-06-30 14:11:08 -0700: Hi all, Specs are interesting idea, that may be really useful, when you need to discuss large topics: 1) work on API 2) Large refactoring 3) Large features 4) Performance, scale, ha, security issues that requires big changes And I really dislike idea of adding spec for every patch. Especially when changes (features) are small, don't affect too much, and they are optional. It really kills OpenStack. And will drastically slow down process of contribution and reduce amount of contributors. Who says there needs to be a spec for every patch? I agree with your items above. Any other change is likely just fixing a bug. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
