Quake3 security issue and non-responsive maintainer: Xavier Lamien
jspaleta at gmail.com
Tue May 11 21:26:53 UTC 2010
On Tue, May 11, 2010 at 1:47 AM, Chen Lei <supercyper1 at gmail.com> wrote:
> It seems a lot of trivial packages in fedora are unmaintained for a long
I dispute your claim that there are "a lot."
Yes we are going to have things fall through the cracks. But I've seen
no analysis and no tools which would help us identify things which are
in an unmaintained state for long periods of time..for some consensus
definition of "unmaintained". Until we have that analysis we can't
know if we are talking about 10% or 1% or 0.01% of our packages.
What we have is the orphaning (a proactive process) and awol
maintainer processes (a reactive process).. we don't have an automated
process that helps us identify potentially unmaintained packages to be
How often does the AWOL maintainer process get used? Very rarely. If
there were a lot of "unmaintained" packages I would expect to see the
AWOL process be firing all the time as people reacted to missing
Okay how about the orphaning process. From the orphaning process we
can get a look at how many packages we know are unmaintained. Right
now we have ~ 290 packages orphaned in devel out of 9217 total. That
is ~3% Note this is simple over estimate.. that 290 includes things
like python-ctypes which is a long dead package as its functionality
has been rolled into the main python package. And I looked at this in
October 2008 I saw pretty much the same percentage of orphans. Is it
unreasonable to expect 2 to 3 percent of the repository to be in a
state of maintainer turn over? I'm not sure that its
unreasonable...and it looks to me like its a pretty stable turnover
percentage. We'd have to trend it over time to be more sure of that
So caveats applied... out of those less than 3% devel repository
orphans how many of them are trivial? Surely the maven packageset
aren't trivial and are going to require some java experts to step up.
I do not think you can make any concrete statements about unmaintained
this being a big problem unless we have the analysis tools in place
which point to the existence of a large pool of packages not in the
orphan list already.
Now can we do better with regard to how we deal with orphans and
package expiration. Probably. There is always room for improvement..
but lets keep it in perspective. We are talking about 2 to 3 percent
of the package count. And while 290 packages is not as small as 0, its
far smaller than 9000.
I'm not aware of _any_ linux distribution with a release time scale on
pars with ours that has a better idea of their maintainership turn
over than we currently do. I think we do pretty good at requiring
individual package accountability and encouraging maintainers to
proactively orphan so we can have an accurate listing of what is
unmaintained. The AWOL process works when its required. What else can
we do that we aren't already doing? I've through about this a lot and
I've pestered people with ideas and nothing I have come up with really
sticks to the wall as a way to further reduce the turnover.
More information about the devel