Again: EOL Policy for Fedora Extras

[Ralf Corsepius]

On Sat, 2006-02-18 at 20:59 +0100, Michael Schwendt wrote:
> On Sat, 18 Feb 2006 19:30:14 +0100, Thorsten Leemhuis wrote:
> 
> > We still have no defined EOL Policy for Fedora Extras -- there were some
> > ideas and concepts floating around, but no real policy came out of it so
> > far. I'd really like to get this solved somehow soon. That's why I'm
> > writing this mail. 
> 
> Long mail, short story: Do we agree on common goals with regard to FE?
> I'm not sure we do.
IMO, there is no doubt: No, we don't, we can't and there isn't any need
to do so - Community projects happen or starve.

>  Instead of discussing EOL policy bottom-up for FE3,
> how about we discuss in general _what_ we at Fedora Extras _try_ to offer?
Quite simple: That what happens to happen and what people are
contributing.

> > mailinglist-archives:
> > 
> > 
> > - Now that FC3 was transfered to Legacy we need some kind of policy for
> > FE3, too -- users want to know if FE3 is still completely supported. 
> 
> Reason: package maintainers often move on to the current if not latest
> release of FC and don't run an older FC anymore. So they don't do any
> run-time evaluation of upgrades/updates anymore. Unless they are the "if
> it builds, push it" type of packagers, they don't release any upgrades
> which they don't use regularly themselves. Further, the older a release of
> FC gets, the more difficult security related version upgrades become, if
> they require upgraded dependencies. This also leads to coordination
> and compatibility requirements between FE and Fedora Legacy.
Right, but this applies to all releases of FE, regardless of whether an
FE release is officially announced "dead" or "alive".

> > - We cannot offer an old FE which is out-of-date or possible insecure at
> > least partially.
Nothing prevents us from doing so and in fact nothing will prevent it
from happening. It's a natural life cycle, with all stages of a life
cycle in place: Infancy, youth, maturity, age and death.

> Which means, there's no need to shut down a repo, but the project ought to
> announce the "updates support level users can expect" compared with Extras
> for the current release of FC.
Agreed - This is how I would like to see "EOL'ing FE" to be interpreted.


> > And some concrete plans:
> 
> > - shove FE3 into a Maintenance state for now -- no new packages, no big
> > updates but still updates in case of security problems
> 
> What is "concrete" about this suggestion?
Agreed, this is what will happen naturally, no matter who _claims_ to be
doing the work. Have a look into current FE3 and FE4, and you'll notice
that this already happens, even on "live FE".

> > - we create an extras legacy team that takes over FE3 when FC3 is
> > transfered to legacy. No community developer interest, no show.
> +1  This is the only realistic suggestion. 

+1, if this legacy team is works inside of FE's infrastructure and
collaborates with FE upstream maintainers.

-1, if this legacy team works outside of FE.

My proposal: Establish a legacy team inside of FE with "card blanche
privileges" on FE < FC(EOL), whose task it would be to process PRs on
old FE's. Then, maintainers, who are aren't interested or unable to fix
PRs on old FEs, could assign such PRs to them, instead of closing them
as "won't fix" as they can't avoid having to do now.


Ralf