<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 4, 2014 at 2:23 AM, John Garbutt <span dir="ltr"><<a href="mailto:john@johngarbutt.com" target="_blank">john@johngarbutt.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Sorry for another top post, but I like how Nikola has pulled this<br>


problem apart, and wanted to respond directly to his response.<br>
<div class=""><br>
On 3 September 2014 10:50, Nikola Đipanov <<a href="mailto:ndipanov@redhat.com">ndipanov@redhat.com</a>> wrote:<br>
> The reason many features including my own may not make the FF is not<br>
> because there was not enough buy in from the core team (let's be<br>
> completely honest - I have 3+ other core members working for the same<br>
> company that are by nature of things easier to convince), but because of<br>
> any of the following:<br>
><br>
> * Crippling technical debt in some of the key parts of the code<br>
<br>
</div>+1<br>
<br>
We have problems that need solving.<br>
<br>
One of the ideas behind the slots proposal is to "encourage" work on<br>
the urgent technical debt, before related features are even approved.<br>
<div class=""><br>
> * that we have not been acknowledging as such for a long time<br>
<br>
</div>-1<br>
<br>
We keep saying "thats cool, but we have to fix/finish XXX first".<br>
<br>
But... we have been very bad at:<br>
* remembering that, and recording that<br>
* actually fixing those problems<br>
<div class=""><br>
> * which leads to proposed code being arbitrarily delayed once it makes<br>
> the glaring flaws in the underlying infra apparent<br>
<br>
</div>Sometimes we only spot this stuff in code reviews, where you throw up<br>
reading all the code around the change, and see all the extra<br>
complexity being added to a fragile bit of the code, and well, then<br>
you really don't want to be the person who clicks approve on that.<br>
<br>
We need to track this stuff better. Every time it happens, we should<br>
try make a not to go back there and do more tidy ups.<br>
<div class=""><br>
> * and that specs process has been completely and utterly useless in<br>
> helping uncover (not that process itself is useless, it is very useful<br>
> for other things)<br>
<br>
</div>Yeah, it hasn't helped for this.<br>
<br>
I don't think we should do this, but I keep thinking about making<br>
specs two step:<br>
* write generally direction doc<br>
* go write the code, maybe upload as WIP<br>
* write the "documentation" part of the spec<br>
* get docs merged before any code<br>
<div class=""><br>
> I am almost positive we can turn this rather dire situation around<br>
> easily in a matter of months, but we need to start doing it! It will not<br>
> happen through pinning arbitrary numbers to arbitrary processes.<br>
<br>
</div>+1<br>
<br>
This is ongoing, but there are some major things, I feel we should<br>
stop and fix in kilo.<br>
<br>
...and that will make getting features in much worse for a little<br>
while, but it will be much better on the other side.<br>
<div class=""><br>
> I will follow up with a more detailed email about what I believe we are<br>
> missing, once the FF settles and I have applied some soothing creme to<br>
> my burnout wounds<br>
<br>
</div>Awesome, please catch up with jogo who was also trying to build this<br>
list. I would love to continue to contribute to that too.<br></blockquote><div><br></div><div>I am not actually trying to build that list yet, right now I am trying to get consensus on the idea of having project priorities: <a href="https://review.openstack.org/#/c/112733/">https://review.openstack.org/#/c/112733/</a>  Once that patch lands I was going to start iterating on a kilo priorities patch so we have something written down (in nova-specs) that we can go off for summit planning.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Might be working moving into here:<br>
<a href="https://etherpad.openstack.org/p/kilo-nova-summit-topics" target="_blank">https://etherpad.openstack.org/p/kilo-nova-summit-topics</a><br>
<br>
The idea was/is to use that list to decide what fills up the majority<br>
of code slots in Juno.<br>
<div class=""><br>
> but currently my sentiment is:<br>
> Contributing features to Nova nowadays SUCKS!!1 (even as a core<br>
> reviewer) We _have_ to change that!<br>
<br>
</div>Agreed.<br>
<br>
<br>
In addition, our bug list would suggest our users are seeing the<br>
impact of this technical debt.<br>
<br>
<br>
My personal feeling is we also need to tidy up our testing debt too:<br>
* document major bits that are NOT tested, so users are clear<br>
* document what combinations and features we actually see tested up stream<br>
* support different levels of testing: on-demand+daily vs every commit<br>
* making it easier to interested parties to own and maintain some testing<br>
* plan for removing the untested code paths in L<br>
* allow for untested code to enter the tree, as experimental, with the<br>
expectation it gets removed in the following release if not tested,<br>
and architected so that is possible (note this means supporting<br>
"experimental" APIs that can be ripped out at a later date.)<br>
<br>
We have started doing some of the above work. But I think we need to<br>
hold ALL code to the same standard. It seems it will take time to<br>
agree on that standard, but the above is an attempt to compromise<br>
between speed of innovation and stability.<br>
<br>
<br>
Thanks,<br>
John<br>
<div class=""><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>