1 |
On Sun, Mar 27, 2011 at 3:40 PM, Nirbheek Chauhan <nirbheek@g.o> wrote: |
2 |
> It's really simple: |
3 |
> |
4 |
> (a) If the package has plenty of users, there should be no problems |
5 |
> finding a maintainer or a proxy-maintainer. |
6 |
|
7 |
Uh, I guess that's why we are flooded with people wanting to be |
8 |
devs... There are lots of high-use packages that could use more |
9 |
maintainers. I'm not aware of any teams that would turn away help. |
10 |
|
11 |
> (b) If the package has few users and is high-maintenance, it's either |
12 |
> already broken, or will get broken soon without a maintainer. Find one |
13 |
> or remove it! |
14 |
|
15 |
If it doesn't build, then it can be removed. Nobody is arguing with |
16 |
that. If you think that someday it might not build, then just wait a |
17 |
few months and if you're right you can satisfy your itch to prune the |
18 |
tree... |
19 |
|
20 |
> (c) If the package has few users and is low-maintenance, package.mask |
21 |
> it so we can figure out who the users are, and we can get them to |
22 |
> proxy-maintain it, it's so little work anyway, right? |
23 |
|
24 |
Uh, package.mask is not intended to be an end-user communication tool. |
25 |
News is slightly better in this respect, but again this is not its |
26 |
purpose. |
27 |
|
28 |
We shouldn't be punishing people for not becoming developers. I don't |
29 |
want to use a distro that throws up warning messages every few months |
30 |
because some package I've been using had its developer retire, and I'm |
31 |
a developer. If it breaks and I care enough about it, I'll rescue it. |
32 |
If I'm passionate about it, I'll step in before it breaks. Holding |
33 |
users ransom is not the solution. |
34 |
|
35 |
> (d) If the package has very few or no users, what the hell is it doing |
36 |
> unmaintained in the tree? It's just eating up disk inodes and space. |
37 |
> |
38 |
|
39 |
Uh, and how much does the inodes, space, and bandwidth consumed by |
40 |
those ~700 m-n packages actually cost. Are we talking about going |
41 |
through wailing and gnashing of teeth so that our stakeholders can |
42 |
save a total of 45 cents worth of disk space across 50 mirrors and |
43 |
50,000 Gentoo boxes over the next 5 years? If one person is getting |
44 |
use out of it, and nobody is getting hurt, and it costs a few inodes, |
45 |
I'm fine with that. |
46 |
|
47 |
> We all like to boast about how gentoo has 15,000 packages, but we |
48 |
> neglect to mention that more than 1000 of these are either |
49 |
> unmaintained or very poorly maintained. And this is a very |
50 |
> conservative number. |
51 |
|
52 |
I don't know anybody who uses Gentoo because of our huge repository. |
53 |
Sure, compared to LFS it is big. Compared to most major distros, |
54 |
Gentoo isn't all that large. If all somebody wants is a ton of |
55 |
packages they're going to run Debian or whatever. Sure, we have a |
56 |
nice repository and we should be proud of it, but I don't think |
57 |
anybody is trying to over-inflate our repo size just by loading it up |
58 |
with junk. |
59 |
|
60 |
The thing I don't understand here is that there seems to be some |
61 |
perception that having stuff in the tree or in Bugzilla costs us |
62 |
something. Sure, at some level it does, and if 99.99% of portage were |
63 |
junk data, then we might have a problem. However, database records |
64 |
and inodes come billions for the dollar. Having a few percent more |
65 |
churn so that we can more gracefully handle the lifecycle of packages |
66 |
doesn't seem like much of a sacrifice. If you're tired of looking at |
67 |
junk when you search bugzilla, then you need to think about how you're |
68 |
searching it. These sorts of arguments come up at work all the time |
69 |
and unless there is some kind of regulatory issue at stake or real |
70 |
loss of revenue associated with lost opportunities, chasing down |
71 |
unnecessary database records to be "tidy" almost always costs far more |
72 |
than it saves. |
73 |
|
74 |
I'd be shocked if the total cost to our sponsors in mirror space for |
75 |
m-n packages exceeded the value of time spent by everybody reading |
76 |
this thread. I think we should be practical - I'm all for giving |
77 |
treecleaners a free hand when packages really cause problems, but |
78 |
being anal-retentive just for the sake of doing so doesn't seem to |
79 |
create real value. |
80 |
|
81 |
Rich |