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

Reply via email to