[ACTION REQUIRED] Retiring packages for F-17
Kevin Kofler
kevin.kofler at chello.at
Fri Jan 13 20:03:09 UTC 2012
Bill Nottingham wrote:
> Due to the orphaning of packages due to inactive maintainers, this list
> is a little longer than normal.
When we're in danger of losing so many packages, it's a sign that our
processes are broken:
* The forced password and SSH key change caused us to lose many maintainers,
not all of whom would have become inactive if it hadn't been for such stupid
asinine and totally useless (since the keys were NOT compromised) "security"
bureaucracy being forced on them, wasting their time.
* The whole concept of packages being "owned", and by one person at that, is
broken. Fedora as a whole should feel responsible for those packages, commit
access should be open to ALL packagers (not just provenpackagers) as in the
good old Extras, and there should be experienced packagers actually stepping
in to rebuild packages with broken dependencies, fix FTBFS issues etc. (I
used to do that, but I had to mostly give up because nobody else would help
(Alex Lancaster used to help fixing broken dependencies, but mostly doesn't
anymore) and I don't have the time to do it all alone anymore.) And packages
such as perl-* should just be owned (automatically) by the relevant SIG.
* Depending on timing, some packages can end up retired with little to no
time to pick them up first, e.g. in one case (avl), your mail threatens to
retire a package less than 97 minutes (!) after it got orphaned. The time
between the mass orphaning due to the "security" farce and the mass retiring
(now) is also deeply insufficient, and there wasn't even one updated list of
not yet picked up packages from the "security" fiasco (the original one
contained way too many packages for packagers to notice the ones of
interest) before this one which already threatens their removal.
Any package which is removed from Fedora is a package our users will no
longer be able to use. Removing a package should only be a last resort if it
cannot be made to work at all.
Kevin Kofler
More information about the devel
mailing list