Open Stack

Le 08/04/2015 23:07, Michael Still a écrit :
> I just wanted to send a note about John running in the PTL election for Nova.
>
> I want to make it clear that I think having more than one candidate is
> a good thing -- its a healthy part of a functional democracy, and it
> also means regardless of the outcome we have at least one succession
> planning option should a PTL need to step down at some point in the
> future.
>
> That said, I think there are a few things we need to do in Liberty,
> regardless of who is PTL. I started this as a Google doc to share with
> John if he won so that we didn’t drop the ball, but then I realised
> that nothing here is secret. So, here is my brain dump of things we
> need to do in Liberty, in no particular order:
>
> nova-coresec reboot
> ================
>
> The nova-coresec team has been struggling recently to keep up with
> their workload. We need to drop people off this team who haven’t had
> time recently to work on security bugs, and we need to find new people
> to volunteer for this team, noting that the team is kept deliberately
> small because of embargoed security vulnerabilities. If I am not
> re-elected as PTL, I will probably volunteer for this team.
>
> priorities and specs
> ===============
>
> I think the current spec process is starting to work well for us, and
> that priorities was a success. We should continue with specs, but with
> an attempt to analyse why so many approved specs don’t land (we have
> had about 50% of our approved specs not land in Juno and Kilo). Is
> that as simple as code review bandwidth? Or is the problem more
> complicated than that? We just don’t know until someone goes digging.

As a reviewer, I think it's sometimes hard to figure out which specs can 
be looked first as we have more than 100 changes. For Kilo, I tried to 
query Gerrit using keywords but I found it was not good because I missed 
some important specs that I discovered once merged.

On the other hand, some specs can be missed while there is a consensus. 
Could we maybe imagine to triage those specs using like we do in 
Launchpad ? I don't think amending the commit msgs is good, I'm more 
thinking about a dynamic etherpad that we can use for finding those.

Now, as a proposer having had 4 specs approved by Kilo but only 2 of 
them landed (all of them part of a priority), I don't even think I can 
give a rule for that. I had a spec which was approved very early in Kilo 
but took most of my engineering effort for Kilo, I had one spec which 
was approved very late with a high number of iterations but whose 
implementation was implemented and merged in less than one week (!) and 
two specs which were kinda rational but failed at the implementation 
stage, mainly because some corner cases were not identified at the spec 
stage.

Based on that experience, I would be tempted to consider that we 
underestimate how long it is necessary to provide a good spec by 
considering the design issues and the implementation details. If a spec 
is really easy to be approved and straightforward to implement, I would 
therefore consider if it would even be worth submitting a spec for it.
I think the Kilo initiative to reduce the number of specs by easing what 
can be merged with only a blueprint move towards the right direction. We 
maybe need to further identify how a spec is really a design document 
which is not only a declaration of intent, but rather a very technical 
document which presents the steps and the change quite precisely.


> Priorities worked well. We need to start talking about what should be
> a priority in Liberty now, and the first step is to decide as a team
> what we think the big problems we’re trying to solve in Liberty are.

++

> nova-core
> ========
>
> I think there are a couple of things to be done here.
>
> There are still a few idle cores, particularly people who haven’t done
> less than ten reviews in the last 90 days. We should drop those people
> from core and thank them for their work in the past noting once again
> that this is a natural part of the Open Source process -- those people
> are off working on other problems now and that’s cool.
>
> We also need to come up with a way to grow more cores. Passive
> approaches like asking existing cores to keep an eye out for talent
> they trust haven’t worked, so I think its time to actively start
> mentoring core candidates.
>
> I am not convinced that just adding cores will solve our review
> bandwidth problems though. We have these conversations about why
> people’s reviews sit around without a lot of data to back them up, and
> I feel like we often jump to conclusions that feel intuitive but that
> aren’t supported by the data.
>
> nova-net
> =======
>
> OMG, this is still a thing. We need to actually work out what we’re
> doing here, and then do it. The path isn’t particularly clear to me
> any more, I thought I understood what we needed to do in Kilo, but it
> turns out that operators don’t feel that plan meets their needs.
> Somehow we need to get this work done. This is an obvious candidate
> for a summit session, if we can come up with a concrete proposal to
> discuss.
>
> bugs
> ====
>
> Trivial bug monkey’ing has worked well for us in Kilo, but one of our
> monkeys is off running as a PTL. We need to ensure we have this
> staffed with people who understand the constraints on the bugs we’re
> willing to let through this process. It would be sad to see this die
> on the vine.

By looking at the etherpad, I can see around 4 to 6 people having 
proposed trivial bugs, which is good. The main problem is about giving 
time and priority to those people for finding bugs, reviewing and 
reporting them. Most of us are doing that on their spare time, which can 
be very limited around milestone deadlines or RC cuts.
I think the idea is to find a critical mass of people that are able to 
report those bugs when they see the solution in Gerrit could help the 
problem. Unfortunately, we are far from that critical mass so we can 
only expect people to think about reporting in the etherpad what they 
consider worth it when they review.


> We also need to fix more bugs. I know we always say this, but we don’t
> have enough senior developers just kicking around looking at bugs to
> fix in a systematic way. This is something I used to do when I had
> more time before PTL’ing became a thing. If I am not elected this is
> the other thing I’ll probably go back to spending time on.
>
> conclusion
> ========
>
> I make no claim that my list is exhaustive. What else do you think we
> should be tackling in Liberty?
>
> Michael
>