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