RFC: Fedora Extras EOL Policy

Patrice Dumas pertusus at free.fr
Fri Apr 14 13:56:22 UTC 2006


> > Why not? If a part of the community is willing to maintain a package, they
> > should be able to do it.
> 
> That would be the "some do, some don't" playground.

That's allready what is the extras project - within the policy 
constraints.
To be more clearer, what is common is defined by the guidelines, 
everything else is "some do, some don't" and that's good.

> We try to move away from Fedora Extras being a second class citizen.

Fedora Extras isn't a second class citizen. Currently I think it is 
better that core for the quality of the packages, and the transparency 
of the package acceptance process and build process. Core may be better
with regard with the security fix. But I don't have numbers on how fast 
the security issues are processed in extras and in core.
 
> We cannot do that as long as we lack a well-defined life-cycle compared
> with Fedora Core. And when we distinguish between active (i.e. maintained,

I don't see why fedora extras would be a second class citizen if it hasn't
a well-defined life-cycle. This seems unimportant with regard with other
issues like packages cleaness, time to respond on bug reports, willing to 
track new things and completness of packages offer.

> "supported") branches, legacy branches and dead branches, we need policies
> which allow for improved security response times, e.g. through the work of
> a Fedora Extras security response team, which under well-defined
> conditions may touch packages in _all_ branches. Whether these are the
> same people who would maintain legacy branches, is an unimportant detail.

I agree, but this has nothing to do with the "some do, some don't" 
regarding maintaining or not packages for legacy branches. It is allready
"some do, some don't" for 'supported' branches. It's a voluntary project,
after all.

> And yes, we do need improved and stricter policies on how to handle
> orphaned packages.

Agreed.

--
Pat




More information about the fedora-extras-list mailing list