Michael J. Knox
michael at knox.net.nz
Tue Apr 25 23:35:35 UTC 2006
Patrice Dumas wrote:
>> orphaned = no maintainer
>> dropped/retired = no maintainer and unmaintainable
> I don't see a clear distinction. For me both are orphaned. In the second
> case it will require more work for a potential maintainer, or maybe the
> potential maintainer won't push it to devel/newer fc versions, but I
> don't understand why there is a need to make 2 separate cases?
A package that has been declared dropped/retired by its former
maintainer or by a Fedora Extras house keeper, can be
"undropped/unretired" should someone from the Fedora Legacy group choose
to take ownership of it.
People come out of retirement all the time, why not software too?
The distinction should be made (between orphan of dropped/retired) based
on the upstream at the time a packager abandons a package.
>> If a package has a maintainer and is unmaintainable, then that's the
>> packagers problem to resolve.
> Sure, but a way to resolve it could be to say: I don't push that package
> to the devel branch. This should also be marked somewhere. But this may
> not be what you are talking about.
See above. It becomes the responsibility of the packager to determine
which branches get pushed out too.
>> I am wanting to make it clearer which packages are orphaned, which ones
>> have been dropped/retired and clearly defining how a package gets a
>> dropped/retired status.
> You mean that you would like to distinguish among orphaned package some
> that are broken and should also be removed from previous releases, where
> they exist as binary packages, and so remove the binary packages from
Yes, that should be considered too.
A package with no maintainer and no upstream development has the
potential to be a security risk and introduce bugs. Who is going to fix
a security issue? Who is going to fix bugs filed against it?
Think of it as an extended QA for FE.
More information about the fedora-extras-list