Again: EOL Policy for Fedora Extras

[Nicolas Mailhot]

Le samedi 18 février 2006 à 23:05 -0600, Dennis Gilmore a écrit :

> One thing i realise  now  is that some people may not want to   or have the 
> resources  to support the development branch.  Its a huge moving target.  not 
> only do you get frequent changes in extras   you get it in core also.  and 
> some people just cant  or dont want to keep up.  we kinda assume  that they 
> will.

I totally agree most maintainers have a range of releases they're
prepared to work on, for some this range centers on devel for others on
legacy.

I thoroughly disagree we should treat all releases the same and let
people contribute to whichever random FE release they want to.

This is what the kernel team used to do in 2.4+2.5 days, and the result
is dispersion of efforts and massive frustration on part of everyone
(2.4 contributors complaining core team does not care about them, core
team complaining freeloaders want them to review 2.4 stuff and won't
help get 2.5 out of the door).

Devel should be mandatory for new functionality. If we don't do that we
betray Fedora goals, because most contributors will do the current
release only. This will mean no one will run/test rawhide and the
various FCn+1Tx, leading to a FCn+1 that slips or sucks, and harming the
whole project (after a while people won't be contributing to current FC
but current FC + a few stabilizing months and so on). Also, devel
packaging is when you see rawhide is missing some crucial bits and when
you can ask for them to be pulled in. After release it's *too* *late*.
RH people have moved to the next release. (this is my main beef with the
other external repositories. They all say devel is too much work, and in
practical terms their influence with users and upstream is used to focus
efforts on FCn-x, diverting efforts that should be used on rawhide)

People not interested in devel can join FEL. That means they also have
no say in what new features get in FE.

We should have three levels of support (more would be nicer for
packagers, but do you imagine the level of frustration of users which
have to evaluate support on a package per package basis ?)

1. partial maintenance -> devel only or devel+FCn, and only if some
needed features are not present in FCn or FCn-1
2. "standard" maintenance -> same as FC, from devel to FCn-1 till devel
graduates to FCn+1T2
3. "long-term" maintenance -> for packages that are picked up by FEL at
FCn+1T2 time. And FEL should draw a red line after which *no* packages
are maintained anymore (iterate if there is the will and resources to
create a FEL++ team charged with "extended long term" maintenance)

And I absolutely do not mean FEL should be a separate entity with no
access to FE ressources. It could be a FE SIG or something else within
FE. But there must be some coordinating structure, and package lifetimes
should not be decorrelated. Pick up when you want and abandon whenever
you feel so is fine and dandy for packagers, but it's also user hell.
One big part of distribution work is to make something coherent out of
random pieces of software. That includes coherent support durations.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 199 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20060219/3d2e47b1/attachment.sig>