Stable release updates vision

Greg DeKoenigsberg gdk at redhat.com
Fri Mar 12 16:22:16 UTC 2010


On Fri, 12 Mar 2010, Jesse Keating wrote:

>> I believe that we should build the infrastructure to support these policy
>> changes first.
>>
>> As Spot eloquently pointed out, the number of users who are likely to help
>> promote packages from testing to stable is currently a vanishingly small
>> number.
>>
>> We must first solve this problem.  When we are satisfied that we've got
>> tools that significantly increase participation in updates-testing, then
>> *and only then* should we change the policies around updates-testing.
>>
>> Which, to me, means "build improved updates-testing flow for F14, change
>> policy starting with F15".
>>
>> My $0.02.
>>
>> --g
>
> Greg, it fully makes sense to build supporting infrastructure before 
> /enacting/ a policy.  However, a policy is needed to guide the building 
> of said supporting infrastructure.

In this case, I'm not sure I agree.  The need -- to get more participants 
in the testing->update process -- is crystal clear, and completely 
independent of any policy changes.  The policy could stay exactly the 
same, and the proposed tool, if properly built, would drive an order of 
magnitude more participation.

> See numerous examples of release engineering proposing new policy and 
> changes, get approval for the change, build up the infrastructure to 
> support the change, and /then/ enact the change.  It is quite difficult 
> to spend the time / energy to build up infrastructure for something that 
> may not be accepted in the first place.

My point: we don't need to have a perfect policy in place to move, quickly 
and in parallel, on a project that is obviously valuable independently of 
the policy.

I think it also allows us to hedge our bets a little bit.  It's clear that 
there's still a lot of debate ahead regarding this policy change.  I think 
it makes sense to give folks a big tactical win to embrace, while we 
continue to hash out the strategic questions.

--g

--
Educational materials should be high-quality, collaborative, and free.
Visit http://opensource.com/education and join the conversation.


More information about the advisory-board mailing list