Open Stack

Sorry for another top post, but I like how Nikola has pulled this
problem apart, and wanted to respond directly to his response.

On 3 September 2014 10:50, Nikola Đipanov <ndipanov at redhat.com> wrote:
> The reason many features including my own may not make the FF is not
> because there was not enough buy in from the core team (let's be
> completely honest - I have 3+ other core members working for the same
> company that are by nature of things easier to convince), but because of
> any of the following:
>
> * Crippling technical debt in some of the key parts of the code

+1

We have problems that need solving.

One of the ideas behind the slots proposal is to "encourage" work on
the urgent technical debt, before related features are even approved.

> * that we have not been acknowledging as such for a long time

-1

We keep saying "thats cool, but we have to fix/finish XXX first".

But... we have been very bad at:
* remembering that, and recording that
* actually fixing those problems

> * which leads to proposed code being arbitrarily delayed once it makes
> the glaring flaws in the underlying infra apparent

Sometimes we only spot this stuff in code reviews, where you throw up
reading all the code around the change, and see all the extra
complexity being added to a fragile bit of the code, and well, then
you really don't want to be the person who clicks approve on that.

We need to track this stuff better. Every time it happens, we should
try make a not to go back there and do more tidy ups.

> * and that specs process has been completely and utterly useless in
> helping uncover (not that process itself is useless, it is very useful
> for other things)

Yeah, it hasn't helped for this.

I don't think we should do this, but I keep thinking about making
specs two step:
* write generally direction doc
* go write the code, maybe upload as WIP
* write the "documentation" part of the spec
* get docs merged before any code

> I am almost positive we can turn this rather dire situation around
> easily in a matter of months, but we need to start doing it! It will not
> happen through pinning arbitrary numbers to arbitrary processes.

+1

This is ongoing, but there are some major things, I feel we should
stop and fix in kilo.

...and that will make getting features in much worse for a little
while, but it will be much better on the other side.

> I will follow up with a more detailed email about what I believe we are
> missing, once the FF settles and I have applied some soothing creme to
> my burnout wounds

Awesome, please catch up with jogo who was also trying to build this
list. I would love to continue to contribute to that too.

Might be working moving into here:
https://etherpad.openstack.org/p/kilo-nova-summit-topics

The idea was/is to use that list to decide what fills up the majority
of code slots in Juno.

> but currently my sentiment is:
> Contributing features to Nova nowadays SUCKS!!1 (even as a core
> reviewer) We _have_ to change that!

Agreed.


In addition, our bug list would suggest our users are seeing the
impact of this technical debt.


My personal feeling is we also need to tidy up our testing debt too:
* document major bits that are NOT tested, so users are clear
* document what combinations and features we actually see tested up stream
* support different levels of testing: on-demand+daily vs every commit
* making it easier to interested parties to own and maintain some testing
* plan for removing the untested code paths in L
* allow for untested code to enter the tree, as experimental, with the
expectation it gets removed in the following release if not tested,
and architected so that is possible (note this means supporting
"experimental" APIs that can be ripped out at a later date.)

We have started doing some of the above work. But I think we need to
hold ALL code to the same standard. It seems it will take time to
agree on that standard, but the above is an attempt to compromise
between speed of innovation and stability.


Thanks,
John