Gentoo Archives: gentoo-dev

From: Nirbheek Chauhan <nirbheek@g.o>
To: Rich Freeman <rich0@g.o>
Cc: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
Date: Sun, 27 Mar 2011 21:10:50
Message-Id: AANLkTikX_RCB_jpof9fK1gG9u=GKzLaOCP2+vWux1oz8@mail.gmail.com
In Reply to: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml by Rich Freeman
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

Replies