On Thu, Sep 4, 2014 at 2:23 AM, John Garbutt <j...@johngarbutt.com> wrote:
> 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 <ndipa...@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. > 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: https://review.openstack.org/#/c/112733/ 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. > > 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 > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev