Julien Danjou wrote:
On Thu, Jan 21 2016, Flavio Percoco wrote:
So, I don't think it has to be the entire cycle. It could also be a couple of
milestones (or even just 1). Thing is, I believe this has to be communicated and
I want teams to know this is fine and they are encouraged to do so.
Tl;DR: It's fine to tell folks no new features will land on this and the
upcoming milestone because they'll be used to stabilize the project.
I can understand that, though I think it's a very naive approach. If
your project built technical debt for the last N cycles, unfortunately I
doubt that stating you're gonna work for ⅓ of a cycle on reducing it is
going to improve your project on the long run – that's why I was saying
"band-aid".
I'd be more inclined to spend time trying to fix the root cause that
pushes projects on the slope of the technical debt rate increase.
Unfortunately, just talking and proposing to fix them doesn't help. We don't
control contributor's management and we can't make calls for them other than
proposing things. I'm not saying this will fix that issue but at least it'll
communicate properly that that will be the only way to contribute to project X
in that period of time.
Yes, exactly. So it's my view¹ that people will just do something else
for 1.5 month (e.g. work downstream, take vacation…), and then come back
knocking at your door for their feature to be merged, now that this
stabilization period is over. And even in the best case scenario, you'll
merge some fixes and improvement, and that's it: in the end you'll end
up with the same problems in N cycle, and you'll have to redo that
again.
That's why I'm talking about fixing the root causes. :-)
Cheers,
¹ pessimistic or realistic, YMMV :-)
IMHO realistic, there are root causes that we need to dig out and fully
expose to really deal with the issue of why stabilization cycles are
needed in the first place (and said issues exposed there are going to be
painful, and controversial and such, that's just how it is going to be).
Overall though, I'm glad we are talking about this and starting to think
about what we as a community can do to start talking and thinking about
these issues (and hopefully figuring out a plan to resolve some or all
of those issues).
In all honesty its likely going to require a carrot and a stick (in some
cases more of a carrot or more of a stick) to get companies that want to
focus on features to think about focusing on stability. If done
incorrectly this will have a real impact on some peoples lives and
businesses (for better or worse this is the reality of the world, sorry
for people that have just realized this, time to get some coffee for
u...) so we really need to be thoughtful about how to go about this.
Anyways, enough rant/comments/thoughts from me, +1 for the general idea,
and +1 for starting to think about what are the root causes of requiring
this kind of cycle in the first place (to large of project? to many
features? not enough contributors? to much code? to much junk/debt in
your project that never got cleaned up/removed? ...)
-Josh
__________________________________________________________________________
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
__________________________________________________________________________
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
