Re: [openstack-dev] [cinder] The future of the integrated release
On 08/07/2014 09:55 AM, John Griffith wrote: Seems everybody that's been around a while has noticed issues this release and have talked about it, thanks Thierry for putting it together so well and kicking off the ML thread here. I'd agree with everything that you stated, I've also floated the idea this past week with a few members of the Core Cinder team to have an every other release for new drivers submissions in Cinder (I'm expecting this to be a HUGELY popular proposal [note sarcastic tone]). There are three things that have just crushed productivity and motivation in Cinder this release (IMO): 1. Overwhelming number of drivers (tactical contributions) 2. Overwhelming amount of churn, literally hundreds of little changes to modify docstrings, comments etc but no real improvements to code I'm not sure that there is much data to support that this has been a problem to the point of impacting productivity. Even if some patches make changes that aren't too significant, those tend to be quick to review. Personally, I haven't found this to be a troublesome area, and it's been clear that Cinder does need some cleanup/refactoring work in some areas. Just going on my gut feeling, I'd argue that we too often have patchsets that are too large and should be split into a series of smaller commits, and that concerns me more, because these are both harder to review and harder to catch bugs in. 3. A new sense of pride in hitting the -1 button on reviews. A large number of reviews these days seem to be -1 due to punctuation or misspelling in comments and docstrings. There's also a lot of my way of writing this method is better because it's *clever* taking place. I still don't really have a good sense of how much this happens and what the impact is. But, the basic problem with this argument is that if we feel that #2 and #3 are both problems, we are effectively inviting the code/documentation to get sloppier and rot over time. It needs to either be cleaned up in review or patched later. (Or if there's a dispute about need there, we at least need to be ok with letting people who feel that this is worthwhile fix it up.) I'd add: 4. Quite a few people have put time into working on third-party driver CI, presumably at the expense of the other usual efforts. This is fine, and a good thing, but it surely impacted the amount of attention given to other efforts with our small team. In Cinder's case I don't think new features is a problem, in fact we can't seem to get new features worked on and released because of all the other distractions. That being said doing a maintenance or hardening only type of release is for sure good with me. Anyway, I've had some plans to talk about how we might fix some of this in Cinder at next week's sprint. If there's a broader community effort along these lines that's even better. Thanks, John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] The future of the integrated release
On Thu, Aug 7, 2014 at 9:28 AM, Eric Harney ehar...@redhat.com wrote: On 08/07/2014 09:55 AM, John Griffith wrote: Seems everybody that's been around a while has noticed issues this release and have talked about it, thanks Thierry for putting it together so well and kicking off the ML thread here. I'd agree with everything that you stated, I've also floated the idea this past week with a few members of the Core Cinder team to have an every other release for new drivers submissions in Cinder (I'm expecting this to be a HUGELY popular proposal [note sarcastic tone]). There are three things that have just crushed productivity and motivation in Cinder this release (IMO): 1. Overwhelming number of drivers (tactical contributions) 2. Overwhelming amount of churn, literally hundreds of little changes to modify docstrings, comments etc but no real improvements to code I'm not sure that there is much data to support that this has been a problem to the point of impacting productivity. Even if some patches make changes that aren't too significant, those tend to be quick to review. Personally, I haven't found this to be a troublesome area, and it's been clear that Cinder does need some cleanup/refactoring work in some areas. Ok... s/There are three things that have just crushed productivity and motivation/There are three things that have just crushed MY productivity and motivation/g better? Just going on my gut feeling, I'd argue that we too often have patchsets that are too large and should be split into a series of smaller commits, and that concerns me more, because these are both harder to review and harder to catch bugs in. I totally agree with you on this, no argument at all. The never ending stream of six additions, typo fixes and new hacking adds however is a different category for me. 3. A new sense of pride in hitting the -1 button on reviews. A large number of reviews these days seem to be -1 due to punctuation or misspelling in comments and docstrings. There's also a lot of my way of writing this method is better because it's *clever* taking place. I still don't really have a good sense of how much this happens and what the impact is. But, the basic problem with this argument is that if we feel that #2 and #3 are both problems, we are effectively inviting the code/documentation to get sloppier and rot over time. It needs to either be cleaned up in review or patched later. See my search/replace above, guess it's just me. I see it quite often, I could try and gather some numbers but honestly it seems like almost every other patch I review has a -1 for something along these lines. (Or if there's a dispute about need there, we at least need to be ok with letting people who feel that this is worthwhile fix it up.) I'd add: 4. Quite a few people have put time into working on third-party driver CI, presumably at the expense of the other usual efforts. This is fine, and a good thing, but it surely impacted the amount of attention given to other efforts with our small team. I do think this has certainly had a significant impact on some folks for sure. But I've already ranted about that and won't do it again here :) In Cinder's case I don't think new features is a problem, in fact we can't seem to get new features worked on and released because of all the other distractions. That being said doing a maintenance or hardening only type of release is for sure good with me. Anyway, I've had some plans to talk about how we might fix some of this in Cinder at next week's sprint. If there's a broader community effort along these lines that's even better. Thanks, John ___ 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] [cinder] The future of the integrated release
On 7 August 2014 16:39, John Griffith john.griff...@solidfire.com wrote: On Thu, Aug 7, 2014 at 9:28 AM, Eric Harney ehar...@redhat.com wrote: On 08/07/2014 09:55 AM, John Griffith wrote: There are three things that have just crushed productivity and motivation in Cinder this release (IMO): 1. Overwhelming number of drivers (tactical contributions) 2. Overwhelming amount of churn, literally hundreds of little changes to modify docstrings, comments etc but no real improvements to code I'm not sure that there is much data to support that this has been a problem to the point of impacting productivity. Even if some patches make changes that aren't too significant, those tend to be quick to review. Personally, I haven't found this to be a troublesome area, and it's been clear that Cinder does need some cleanup/refactoring work in some areas. Ok... s/There are three things that have just crushed productivity and motivation/There are three things that have just crushed MY productivity and motivation/g For the record, I feel the same way as John... Cinder has become a great big, complex API wrapper for other products... it is a direction that I think means we aren't developing anything new or nevel within cinder, we're making it harder to even think about doing that, and what we have is becoming flakier and flakier. Just going on my gut feeling, I'd argue that we too often have patchsets that are too large and should be split into a series of smaller commits, and that concerns me more, because these are both harder to review and harder to catch bugs in. I totally agree with you on this, no argument at all. The never ending stream of six additions, typo fixes and new hacking adds however is a different category for me. I started the code cleanup tag to help reduce the impact of these, we can hopefully punt them to a couple of one week periods per release. Have to see how that works out over time. I'd add: 4. Quite a few people have put time into working on third-party driver CI, presumably at the expense of the other usual efforts. This is fine, and a good thing, but it surely impacted the amount of attention given to other efforts with our small team. I do think this has certainly had a significant impact on some folks for sure. But I've already ranted about that and won't do it again here :) I'm one of the people who's been pushing hard on CI, to the point I'm sure that some people are really fed up with my emails, but I do feel that if we can get it done and working then the future benefits are substantial. And all of the people complaining that openstack / devstack is too flaky to get CI working I think are realising a problem that really needs to be fixed. If we can't stand up a simple system to run basic tests on, we have clear problems. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
