Open Stack

On 27/01/16 11:00 +0000, Kuvaja, Erno wrote:
>> -----Original Message-----
>> From: Flavio Percoco [mailto:flavio at redhat.com]
>> Sent: Monday, January 25, 2016 3:07 PM
>> To: openstack-dev at lists.openstack.org
>> Subject: Re: [openstack-dev] [all][tc] Stabilization cycles: Elaborating on the
>> idea to move it forward
>>
>> On 20/01/16 13:23 -0430, Flavio Percoco wrote:
>> >Thoughts? Feedback?
>>
>> Hey Folks,
>>
>> Thanks a lot for the feedback. Great comments and proposals in the many
>> replies.
>> I've gone through the whole thread and collected the most common
>> feedback.
>> Here's the summary:
>>
>> - The general idea of planning some sort of stabilization for a project is good
>>   but considering a cycle for it is terrible. It'd be easier if development
>>   cycles would be shorter but the 6-month based development cycles don't
>> allow
>>   for planning this properly.
>>
>> - Therefore, milestones are more likely to be good for this but there has to
>> be
>>   a good plan. What will happen with on-going features? How does a project
>>   decide what to merge or not? Is it really going to help with reviews/bugs
>>   backlog? or would this just increase the bakclog?
>>
>> - We shouldn't need any governance resolution/reference for this. Perhaps a
>>   chapter/section on the project team guide should do it.
>>
>> - As other changes in the commuity, it'd be awesome to get feedback from a
>>   project doing this before we start encouraging other projects to do the
>> same.
>>
>>
>> I'll work on adding something to the project team guide that covers the
>> above points.
>>
>> did I miss something? Anything else that we should add and or consider?
>>
>
>Sorry for jumping the gun this late, but I have been thinking about this since your first e-mail and one thing bothers me. Don't we have stabilization cycle for each release starting right from the release?
>
>In my understanding this is exactly what the Stable releases Support Phase I is accepting bug fixes but no new features. After 6 months the release is moved to Phase II where only critical and security fixes are accepted; I think this is good example of stabilization cycle and the output is considered solid.
>
>All concerns looked at I think the big problem really is to get the people working on these cycles. Perhaps we should encourage more active maintenance on our stable branches and see then what we can bring from that to our development branch expertise and knowledge wise.
>
>While I'm not huge believer of constant agile development, this is one of those things that needs to be lived with and I think stable branches are our best bet for stabilization work (specifically when that work needs to land to master first). For long term refactoring I'd like to see us using more feature branches so we can keep doing the work without releasing it before it's done.

So, I think what confused most people in the thread is the title itself. The
title is Stabilization Cycles but it really means "clean up the mess we have in
the code base.... including bugs". We can't address technical debt in stable
branches other than bug fixes. Refactors are rejected and, of course, no
breaking changes allowed.

While your thoughts are correct, as we should encourage more folks to contribute
to stable branches and fix bugs there, it's true that there are not enough
people in every project to keep master moving forward and focusing on bugs for
master *and* stable branches at the same time. Ideally, most of that
"Stabilization" work should be backported to stable branches as well.

Flavio

>My 2 Euro cents,
>Erno
>
>> Cheers,
>> Flavio
>>
>> --
>> @flaper87
>> Flavio Percoco

-- 
@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/20160127/c30ea399/attachment.pgp>