| 1 |
Hi, |
| 2 |
|
| 3 |
TL;DR: if you don't maintain a package, drop it to maintainer-needed, so |
| 4 |
others can step up. |
| 5 |
|
| 6 |
|
| 7 |
Lately I have had to deal with a fair number of packages which haven't |
| 8 |
seen any maintainer activity for a few years already. This includes |
| 9 |
packages with multiple bug reports which haven't seen any response, |
| 10 |
and is especially true of packages maintained by projects, |
| 11 |
and especially the kind of projects that loosely couple lots of barely |
| 12 |
related packages (i.e. categories) -- www-apps, forensics, benchmarks. |
| 13 |
|
| 14 |
I can think of a few reasons why this happens: |
| 15 |
|
| 16 |
a. creating meaningless projects that attempt to group things which |
| 17 |
don't have much in common, and where each project member is interested |
| 18 |
in a subset of the packages, |
| 19 |
|
| 20 |
b. developers leaving projects without ensuring that there's anyone left |
| 21 |
and either cleaning them up or announcing the need for new members, |
| 22 |
|
| 23 |
c. developers abandoning their packages and dumping them on generic |
| 24 |
projects (e.g. dumping random Python programs on python@g.o). |
| 25 |
|
| 26 |
|
| 27 |
This causes two major issues: |
| 28 |
|
| 29 |
1. Newly reported bugs are assigned directly to the maintainer. |
| 30 |
If the maintainer ignores them, then the users end up waiting forever |
| 31 |
for a reply. In this case, it is indeed better if the user clearly sees |
| 32 |
that the package has no maintainer and if people subscribing to |
| 33 |
maintainer-needed@ mail see the new bugs. |
| 34 |
|
| 35 |
2. Other developers hesitate to fix the package, and file bugs instead. |
| 36 |
If the maintainer doesn't reply to those bugs, that's just a wasted |
| 37 |
developer effort + unnecessary delay in getting things fixed. If they |
| 38 |
get fixed at all since the developer may forget that he filed a bug. |
| 39 |
|
| 40 |
|
| 41 |
So, developers: |
| 42 |
|
| 43 |
A. Please make sure you are only listed as a maintainer for the packages |
| 44 |
that you really want to maintain. If you are no longer interested |
| 45 |
in a package, send the usual 'up for grabs' mail to let others take care |
| 46 |
of it [and lastrite or dump it to maintainer-needed if they don't want |
| 47 |
to]. |
| 48 |
|
| 49 |
B. If your project is unable to maintain all the packages it has, then |
| 50 |
either: |
| 51 |
|
| 52 |
B1. announce the need for more project members, |
| 53 |
|
| 54 |
B2. 'up for grabs' some of the packages to let them get a dedicated |
| 55 |
maintainer, |
| 56 |
|
| 57 |
B3. disband the project altogether and take over direct maintenance of |
| 58 |
the packages you care about. |
| 59 |
|
| 60 |
C. If you no longer wish to maintain a package, then don't dump it on |
| 61 |
a generic project without asking first. Just because some project didn't |
| 62 |
mind being backup/advisory maintainer for your package doesn't mean that |
| 63 |
it wants to maintain it by itself. |
| 64 |
|
| 65 |
|
| 66 |
Any comments? |
| 67 |
|
| 68 |
-- |
| 69 |
Best regards, |
| 70 |
Michał Górny |
Archives