<div dir="ltr">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?<div><br></div><div>And by make it better, I don't mean talk about it, I mean actually implementing and enforcing policy.<br><br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 24, 2015 at 6:30 AM Matt Riedemann <<a href="mailto:mriedem@linux.vnet.ibm.com">mriedem@linux.vnet.ibm.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
There is the openstack-specs repo for cross-project specs:<br>
<br>
<a href="http://specs.openstack.org/openstack/openstack-specs/" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/openstack-specs/</a><br>
<br>
That'd be a good place for things like your os-vif library spec which<br>
requires input from both nova and neutron teams, although I think it's<br>
currently OK to have it in nova-specs since a lot of the forklift is<br>
going to come from there and we can add neutron reviewers as needed.</blockquote><div><br></div><div>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.</div><div><br></div><div>First: Overhead</div><div>- 1 week for vacation</div><div>- 1 week for holidays.</div><div>- 4 weeks for feature freeze.</div><div>- 4 weeks of pre-summit roadmap planning.</div><div>- 1 week of summit.</div><div>Remaining: 15 weeks.</div><div><br></div><div>Second: Writing, discussing, and landing the spec.</div><div>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.</div><div>Remaining: 9 weeks.</div><div><br></div><div>Third: Role conflicts and internal overhead.</div><div>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.</div><div>Remaining time: 4.5 weeks</div><div><br></div><div>Writing the code:</div><div>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.</div><div>Remaining time: 3.5 weeks.</div><div><br></div><div>The last step: Getting the cores to agree with your approach.</div><div>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.</div><div>Remaining time: -0.5 weeks. </div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>The problem is how long it takes.</div><div><br></div><div>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.</div><div><br></div><div>But then, I'm none of these things. Turns out I like prefer pushing the codebase forward, as frustrating as it is these days.</div><div><br></div><div>Michael</div></div></div></div>