Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev