1 |
On Mon, Mar 28, 2011 at 2:14 AM, Rich Freeman <rich0@g.o> wrote: |
2 |
> On Sun, Mar 27, 2011 at 3:40 PM, Nirbheek Chauhan <nirbheek@g.o> wrote: |
3 |
>> It's really simple: |
4 |
>> |
5 |
>> (a) If the package has plenty of users, there should be no problems |
6 |
>> finding a maintainer or a proxy-maintainer. |
7 |
> |
8 |
> Uh, I guess that's why we are flooded with people wanting to be |
9 |
> devs... There are lots of high-use packages that could use more |
10 |
> maintainers. I'm not aware of any teams that would turn away help. |
11 |
> |
12 |
|
13 |
Everyone thinks all is dandy, and so no one volunteers. Why would |
14 |
someone volunteer their help if we don't advertise the need? Every |
15 |
single team I know has members that are there for historical value and |
16 |
don't do anything anymore. This means team member lists are inevitably |
17 |
artificially inflated. |
18 |
|
19 |
>> (b) If the package has few users and is high-maintenance, it's either |
20 |
>> already broken, or will get broken soon without a maintainer. Find one |
21 |
>> or remove it! |
22 |
> |
23 |
> If it doesn't build, then it can be removed. Nobody is arguing with |
24 |
> that. If you think that someday it might not build, then just wait a |
25 |
> few months and if you're right you can satisfy your itch to prune the |
26 |
> tree... |
27 |
> |
28 |
|
29 |
I think you missed my point about fewer users meaning the likelihood |
30 |
of bugs getting reported being low. And even if bugs get reported, who |
31 |
reads bug reports assigned to maintainer-needed@g.o? |
32 |
|
33 |
>> (c) If the package has few users and is low-maintenance, package.mask |
34 |
>> it so we can figure out who the users are, and we can get them to |
35 |
>> proxy-maintain it, it's so little work anyway, right? |
36 |
> |
37 |
> Uh, package.mask is not intended to be an end-user communication tool. |
38 |
> News is slightly better in this respect, but again this is not its |
39 |
> purpose. |
40 |
> |
41 |
|
42 |
End-user? No. Potential developer? Yes. That's why we have a one-month |
43 |
package.mask period while last-riting unmaintained packages for QA |
44 |
problems. |
45 |
|
46 |
> We shouldn't be punishing people for not becoming developers. I don't |
47 |
> want to use a distro that throws up warning messages every few months |
48 |
> because some package I've been using had its developer retire, and I'm |
49 |
> a developer. If it breaks and I care enough about it, I'll rescue it. |
50 |
> If I'm passionate about it, I'll step in before it breaks. Holding |
51 |
> users ransom is not the solution. |
52 |
> |
53 |
|
54 |
So you're worried that the "oldness" criteria in the policy should not |
55 |
be too strict? Cool, that's something for discussion. |
56 |
|
57 |
>> (d) If the package has very few or no users, what the hell is it doing |
58 |
>> unmaintained in the tree? It's just eating up disk inodes and space. |
59 |
>> |
60 |
> |
61 |
> Uh, and how much does the inodes, space, and bandwidth consumed by |
62 |
> those ~700 m-n packages actually cost. Are we talking about going |
63 |
> through wailing and gnashing of teeth so that our stakeholders can |
64 |
> save a total of 45 cents worth of disk space across 50 mirrors and |
65 |
> 50,000 Gentoo boxes over the next 5 years? If one person is getting |
66 |
> use out of it, and nobody is getting hurt, and it costs a few inodes, |
67 |
> I'm fine with that. |
68 |
> |
69 |
|
70 |
One person who gets some use out of it, and how many who either can't |
71 |
compile it, or can't run it? This kind of thing affects how people see |
72 |
Gentoo. Besides, removal of a package from the tree doesn't mean |
73 |
there's no way to use it anymore. For those who still use that one |
74 |
package that no one else really uses anymore, local portdir_overlay |
75 |
configuration is really easy. |
76 |
|
77 |
>> We all like to boast about how gentoo has 15,000 packages, but we |
78 |
>> neglect to mention that more than 1000 of these are either |
79 |
>> unmaintained or very poorly maintained. And this is a very |
80 |
>> conservative number. |
81 |
> |
82 |
> I don't know anybody who uses Gentoo because of our huge repository. |
83 |
> Sure, compared to LFS it is big. Compared to most major distros, |
84 |
> Gentoo isn't all that large. If all somebody wants is a ton of |
85 |
> packages they're going to run Debian or whatever. |
86 |
|
87 |
Note that most other distros have large package numbers because they |
88 |
split their packages into "pkgname", "pkgname-dev" "pkgname-doc", etc. |
89 |
I'm not sure if anyone counts source-package numbers for binary |
90 |
distros. |
91 |
|
92 |
> Sure, we have a |
93 |
> nice repository and we should be proud of it, but I don't think |
94 |
> anybody is trying to over-inflate our repo size just by loading it up |
95 |
> with junk. |
96 |
> |
97 |
> The thing I don't understand here is that there seems to be some |
98 |
> perception that having stuff in the tree or in Bugzilla costs us |
99 |
> something. Sure, at some level it does, and if 99.99% of portage were |
100 |
> junk data, then we might have a problem. However, database records |
101 |
> and inodes come billions for the dollar. Having a few percent more |
102 |
> churn so that we can more gracefully handle the lifecycle of packages |
103 |
> doesn't seem like much of a sacrifice. If you're tired of looking at |
104 |
> junk when you search bugzilla, then you need to think about how you're |
105 |
> searching it. These sorts of arguments come up at work all the time |
106 |
> and unless there is some kind of regulatory issue at stake or real |
107 |
> loss of revenue associated with lost opportunities, chasing down |
108 |
> unnecessary database records to be "tidy" almost always costs far more |
109 |
> than it saves. |
110 |
> |
111 |
> I'd be shocked if the total cost to our sponsors in mirror space for |
112 |
> m-n packages exceeded the value of time spent by everybody reading |
113 |
> this thread. I think we should be practical - I'm all for giving |
114 |
> treecleaners a free hand when packages really cause problems, but |
115 |
> being anal-retentive just for the sake of doing so doesn't seem to |
116 |
> create real value. |
117 |
> |
118 |
|
119 |
Where did this come from? My entire argument was based around the fact |
120 |
that unmaintained packages that may or may not be broken fundamentally |
121 |
constitute a *bad* experience for the user. If we cannot guarantee |
122 |
that bugs for a package will be fixed, we should not take up the |
123 |
responsibility of the package! |
124 |
|
125 |
Which is worse? Suddenly pulling a package from underneath the feet of |
126 |
users when it inevitably breaks or telling them upfront that it's |
127 |
*completely not* supported by us so they can do something about it |
128 |
before it breaks? |
129 |
|
130 |
|
131 |
-- |
132 |
~Nirbheek Chauhan |
133 |
|
134 |
Gentoo GNOME+Mozilla Team |