[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Blend Fedora Objectives (was Re: Again: EOL Policy for Fedora Extras)



Le samedi 18 février 2006 à 15:45 -0500, Warren Togami a écrit :

> > 3. we should let FEL define its own policies. Today we don't know the
> > number of people interested in FEL and their level of involvement. It's
> > useless to dictate rules to a team which is not assembled yet. People
> > who want to do it should first go to 1. and create some form of entity
> > 
> 
> I think it is entirely broken to "hand over" the entire Extras and 
> expect some other volunteer to take care of it.  This will create a 
> guaranteed failure situation for a community group because the set of 
> packages is potentially infinite and the natural problem that security 
> is difficult to maintain with only volunteers (even Debian struggles). 
> It is a *fantasy* for maintainers to expect they hand over 
> responsibility to some theoretical entity and expect it to actually work.

The fantasy is to continue not acknowledging the problem. I'm very
sceptical about the viability of a FEL. I write so openly. If we create
one it will suck the first releases just like it did for FCL (and this
is the optimistic scenario). But at least users will know where they
stand and not expect that because no one dared announce an EOL FE will
somehow continue to be maintained indefinitely (and the problem is *not*
specifically FC3. Given Fedora's short release cycles the number of
releases to maintain is potentially much higher).

As far as I'm concerned my part of FE3 was EOLed at FC5T2 time. You can
argue all day about FEL or not FEL, but no FEL doesn't mean FE
maintainers will magically continue maintaining FE3. It means there's no
one to pick up the ball, and the FE3 EOL is final.

I say create a FEL team. It will fly or sink. Either way users and
maintainers will know what to expect. Sometimes life is tough. That's no
reason to play the ostrich.

-- 
Nicolas Mailhot

Attachment: signature.asc
Description: Ceci est une partie de message numériquement signée


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]