John, I spent the drive to the Minneapolis Airport thinking about this chain of e-mails. Hope these thoughts help ...
On Thu, 2014-08-07 at 07:55 -0600, John Griffith wrote: > > > > > On Thu, Aug 7, 2014 at 7:33 AM, Anne Gentle <a...@openstack.org> > wrote: > > > > On Thu, Aug 7, 2014 at 8:20 AM, Russell Bryant > <rbry...@redhat.com> wrote: > On 08/07/2014 09:07 AM, Sean Dague wrote:> I think the > difference is > slot selection would just be Nova drivers. I > > think there is an assumption in the old system that > everyone in Nova > > core wants to prioritize the blueprints. I think > there are a bunch of > > folks in Nova core that are happy having signaling > from Nova drivers on > > high priority things to review. (I know I'm in that > camp.) > > > > Lacking that we all have picking algorithms to hack > away at the 500 open > > reviews. Which basically means it's a giant random > queue. > > > > Having a few blueprints that *everyone* is looking > at also has the > > advantage that the context for the bits in question > will tend to be > > loaded into multiple people's heads at the same > time, so is something > > that's discussable. > > > > Will it fix the issue, not sure, but it's an idea. > > > OK, got it. So, success critically depends on > nova-core being willing > to take review direction and priority setting from > nova-drivers. That > sort of assumption is part of why I think agile > processes typically > don't work in open source. We don't have the ability > to direct people > with consistent and reliable results. > > I'm afraid if people doing the review are not directly > involved in at > least ACKing the selection and commiting to review > something, putting > stuff in slots seems futile. > > > > My original thinking was I'd set aside a "meeting time" to > review specs especially for doc issues and API designs. What I > found quickly was that the 400+ queue in one project alone was > not only daunting but felt like I wasn't going to make a dent > as a single person, try as I may. > > > I did my best but would appreciate any change in process to > help with prioritization. I'm pretty sure it will help someone > like me, looking at cross-project queues of specs, to know > what to review first, second, third, and what to circle back > on. > > -- > 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 > > 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) I totally agree with this statement. We have so many large patches to review that it is daunting. I wish I had a good solution for dealing with this issue. I don't think quick reviews and just trying to get them through is the right answer. Perhaps a coordinated effort for some portion of our code sprint days to knock things down? Split up the work and then work together to push some through? > 2. Overwhelming amount of churn, literally hundreds of little changes > to modify docstrings, comments etc but no real improvements to code I can understand the frustration here, but do we want to discourage people from doing this. If they are submitting fixes, they are looking at the code. They are bound to also find some bugs in code as well. I just think it is dangerous to say that those changes have no real improvement to the code. That is just my feeling. OpenStack, unlike other projects I have been on, is very much like an open book. Anyone can read it and people often do. I don't want Cinder to look like a poorly written book. > 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. > Well, with regards to the misspellings, see my comment above. I don't think people are taking pride in hitting -1 over it. They are seeing issues, don't want to be submitting a bunch of clean-up patches and so are noting that they think something needs to be fixed. I agree the -1 needs to be used with care here. Is it one typo or 20? Are there a bunch of +1's and/or +2's on the review. If so, shouldn't be -1'ing at that point. If people are throwing themselves in front of the train, perhaps we need more education for the crew. Duncan noted that perhaps his code clean-up weeks could help with this. I hate to admit I don't fully understand how to use the process yet. I hope we can talk about that as well as this whole subject at the code sprint. Also, I was surprised in one of your subsequent notes that you were frustrated with the addition of Hacking checks. I had been working on those given that I thought it was part of the solution to all the -1's. Catch some of the issues that are easily caught and also catch us up with other project's Hacking checks. > > 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. > Honestly, I haven't been able to get to the new feature stuff because I am distracted by the little clean-up patches, but because the new features are so big and painful I have been bad about forcing myself to get through them. I wonder how may are guilty of this? :-) > > 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. > Is this problem unique to Cinder? I don't hear others talking about this much. If this is unique to Cinder, why? Maybe we need to start with that question to find a solution. > 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
