Open Stack

On 21/01/16 12:00 +0100, Julien Danjou wrote:
>On Wed, Jan 20 2016, Flavio Percoco wrote:
>
>Hi fellows,
>
>> Now, "stabilization Cycles" are easy to dream about but really hard to do and
>> enforce. Nonetheless, they are still worth a try or, at the very least, a
>> thought. I'll try to go through some of the issues and benefits a stabilization
>> cycle could bring but bear in mind that the lists below are not exhaustive. In
>> fact, I'd love for other folks to chime in and help building a case in favor or
>> against this.
>
>[…]
>
>I don't think this is a bad idea per say – obviously, who would think
>it's a bad idea to fix bugs. But I'm still concerned. Isn't this in some
>way just a band-aid?
>
>If a project needs to spend an entire cycle (6 months) doing
>stabilization, this tells me that its development model and operating is
>having some problems. What about talking about those and trying to fix
>them? Maybe we should try to fix (or at least enhance) the root cause(s)
>rather than just the symptoms?
>
>So can someone enlighten me on why some projects need an entire cycle to
>work fixing bugs? :)

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.

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.

Flavio

>Best,
>-- 
>Julien Danjou
>/* Free Software hacker
>   https://julien.danjou.info */



-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160121/3a41f0ee/attachment.pgp>