On Thu, Jan 21, 2016 at 06:37:00PM +0100, Markus Zoeller wrote: > Flavio Percoco <fla...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
