Open Stack

TL/DR: I think the original poster is simply frustrated with how long it
takes to go from spec to landed feature. How about we stop talking about
whether specs are good or not (I think everyone agrees that they are
beneficial), and try to actually make the process better?

And by make it better, I don't mean talk about it, I mean actually
implementing and enforcing policy.

On Wed, Jun 24, 2015 at 6:30 AM Matt Riedemann <mriedem at linux.vnet.ibm.com>
wrote:

>
> There is the openstack-specs repo for cross-project specs:
>
> http://specs.openstack.org/openstack/openstack-specs/
>
> That'd be a good place for things like your os-vif library spec which
> requires input from both nova and neutron teams, although I think it's
> currently OK to have it in nova-specs since a lot of the forklift is
> going to come from there and we can add neutron reviewers as needed.


Let's walk through a hypothetical (because I just went through this)
example of a cross-project spec, assuming a 6 month release cycle (26
weeks), assuming one person driving a spec.

First: Overhead
- 1 week for vacation
- 1 week for holidays.
- 4 weeks for feature freeze.
- 4 weeks of pre-summit roadmap planning.
- 1 week of summit.
Remaining: 15 weeks.

Second: Writing, discussing, and landing the spec.
Taking a quick look at the most recent cross-project specs that have
merged, they seem to take between one and two months from proposal to
landing. This process involves hunting down cores from all impacted
projects, the TC, the x-project team, getting your spec onto the agenda for
discussion, making sure your spec gets proper exposure and time on the
mailing list, and more. So, let's conservatively assume it'll take 6 weeks
to land a cross-project spec, on average. Note that none of requires 40
hours a week, but it is disruptive time because you never know when someone
will be online and accessible.
Remaining: 9 weeks.

Third: Role conflicts and internal overhead.
Now let's assume that you're either a core, or a PTL, or a lead/contributor
on an internal project. Assuming that you're even permitted to work on the
spec, it's unlikely that you'll be able to dedicate your entire time to
just this particular piece. So let's conservatively estimate that between
standups, doing other reviews, discussing other code, internal work, and
shifting context, you're about 50% efficient.
Remaining time: 4.5 weeks

Writing the code:
Yay, we're coding! Let's assume that the initial code, plus tests and
dependencies, takes .5 weeks per project. In our above example, there's 2
projects involved, so that takes 1 week total.
Remaining time: 3.5 weeks.

The last step: Getting the cores to agree with your approach.
Inevitably, the approach you took can't please everyone, because technical
goals != technical implementation. Usually there's some feature you didn't
know about, or something that needs to land first, or a docimpact you
forgot about... Long story short, you lose about 2 weeks fixing your
patch.... per project... because there's always something.
Remaining time: -0.5 weeks.

Sorry! But the PTL just -2'd your patch because you couldn't get it in on
time. Why? Because the continuous insistence of 'discuss everything' in
OpenStack, while ethically sound, is TERRIBLE if there's no forcing
function to bring people to the table and force a decision in a timely
manner.

So, to summarize: Specs are great, because we can get an idea of the why,
the impact, etc. I don't think anyone denies the benefit of discussing
technical goals before implementation.

The problem is how long it takes.

Solutions? Frankly, I'm annoying and persistent on IRC in order to force
the PTL's to pay attention to me. It sometimes works. Many times (I'm
looking at you, PTL's and TC's) I'm ignored. However across openstack?
Personally, I believe that there's a conflict of interest between the TC
and PTL's, and the two roles should be exclusive. I believe that both TC
members and PTL's should step down if they can't dedicate 100% of their
time to their upstream role. I believe that cores, ptl's, and tc members,
have an obligation to review every patch that comes in, every morning, no
matter whether there's already a -1 on it.

But then, I'm none of these things. Turns out I like prefer pushing the
codebase forward, as frustrating as it is these days.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150624/5edaabd3/attachment.html>