Open Stack

On Thu, Jan 21, 2016 at 06:37:00PM +0100, Markus Zoeller wrote:
> Flavio Percoco <flavio at redhat.com> wrote on 01/21/2016 09:13:02 AM:

[...]

First, positive remark(s): 

Thanks for writing this up.  FWIW, I support the notion of having
milestones focusing on stability, as opposed to explicitly declaring a
whole cycle as 'stable' as I agree (as do you) with Dan Berrange's
reasoning.

(Also see Doug's comment in the thread: "projects the option of choosing
a release model that allows for multiple releases per 6 month cycle,
while still maintaining a single stable release after the cycle.")

> > >> Negative(?) effects
> > >> ===================
> > >>
> > >> - Project won't get new features for a period of time Economic
> > >> impact  on developers(?)
> > >> - It was mentioned that some folks receive bonuses for landed 
> > >>   features

This (non-point) reminds of a recent comment I've read elsewhere[1]
about why websites have been becoming bloated[1], and how people are
(dis)incentivized.  [NB: This was written in the context of websites;
we're talking about an Infra project, so adjust the view accordingly]:

   "[...] People (designers, coders, etc) get bonuses and paychecks for
   creating stuff more than tearing down stuff.

   Put this on your resume -- "Implemented feature x, designed y, added
   z" vs "Cut out 10k lines worth of crap only 10% of customers
   [operators] used, stripped away stupid 1Mb worth for js that displays
   animated snowflakes, etc".  You'd produce a better perception by
   claiming you added / created / built, rather than deleted.

   So it is not surprising that more stuff gets built, more code added
   to the pile, more features implemented. Heck, even GMail keeps
   changing every 6 months for apparently no reason. But in reality
   there is a reason -- Google has full time designers on the GMail
   team. There is probably no way they'd end the year with "Yap, site
   worked great, we did a nice job 2 years ago, so I didn't touch it
   this year."

[...]
 
> I try to handle in one post the different aspects which came up so
> far:
> 
> wrt dedicated stabilization cycles|milestones:
> 
>     Piled up (=older) bugs are harder to solve than fresh ones.  I've
>     seen next to no bug report in Nova which has all the necessary
>     data to do a proper analysis. There are usually 1-3 requests to
>     the bug reporter necessary to get enough data.  This makes me
>     believe that stabilization should be a continuous effort.

Whole-heartedly agree with this.  It just ought to be a _continuous_
effort.

While we're at it, thanks Markus for your patient (and productive)
efforts on bug triaging in Nova!

[...]

[1] https://news.ycombinator.com/item?id=10820716

-- 
/kashyap