Stable release updates vision

[Paul Frields]

On Fri, Mar 12, 2010 at 11:10 AM, Jesse Keating <jkeating at redhat.com> wrote:
> On Fri, 2010-03-12 at 09:32 -0500, Greg DeKoenigsberg wrote:
>> On Thu, 11 Mar 2010, Paul W. Frields wrote:
>>
>> > As noted in our previous minutes[1], the Board was tasked with
>> > producing a vision statement for updates to Fedora stable releases.
>> > That vision can be found here:
>> >
>> > https://fedoraproject.org/wiki/Stable_release_updates_vision
>> >
>> > This statement is the result of many Board discussions which have
>> > taken into consideration issues raised recently in numerous other
>> > venues such as the devel list.  After considering these issues
>> > carefully, along with other factors such as the broad user base for
>> > which we should strive[2], the Board feels this vision will best meet
>> > the needs of our millions of users, including our contributor base.
>> >
>> > The Board would like FESCo to read through this vision statement, and
>> > use it as a basis for implementing changes that will help achieve this
>> > vision.  We look forward to working with FESCo and across the whole
>> > Fedora Project to continue improving the Fedora distribution.
>>
>> 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.  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.

Yes, the Board's role here is to point things in the direction where
we want to be in the future. We all realize there's work to do to get
there, and it's not going to happen overnight. Board members
themselves will continue to pitch in wherever possible to help move
things forward.

Pau