Gentoo Archives: gentoo-dev

From: Chris Gianelloni <wolf31o2@g.o>
To: Chris Bainbridge <c.j.bainbridge@×××××.uk>
Cc: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Stuff that makes people mad
Date: Fri, 21 May 2004 15:31:29
Message-Id: 1085153967.25140.76.camel@localhost
In Reply to: Re: [gentoo-dev] Stuff that makes people mad by Chris Bainbridge
1 On Fri, 2004-05-21 at 10:54, Chris Bainbridge wrote:
2 > One of the things that seems to annoy lots of people is this idea that their
3 > ebuilds are being ignored. I've usually got a bunch (8 at the moment) of
4 > ebuilds in bugs.gentoo waiting to be processed.. the oldest is almost a year
5 > old now. There ought to be some sort of procedure for dealing with user
6 > submitted ebuilds. I would suggest a system of putting them in ~x86 (or
7 > whatever) immediately, and if there are no bug reports for x days move them
8 > to x86.
9
10 If your ebuild is being ignored, it is probably because of one of a few
11 possible reasons.
12
13 1. Developers responsible for that area of Gentoo don't see the value of
14 it. While this is sometimes a sad thing to think about, it happens. A
15 good way to solve this is to drum up support for your ebuild. An ebuild
16 submitted to bugzilla with no comments from other users doesn't *appear*
17 to have nearly as much support as an ebuild with lots of comments from
18 users on how they wish this was in portage, and how well it works, etc.
19
20 2. Developers responsible for that area of Gentoo don't have the time to
21 maintain another package they don't understand. In a lot of cases, I
22 would say that this is the main factor in an ebuild staying in
23 bugzilla. Once again, a good show of support from users is always a
24 good motivator. Remember that many developers *never* visit the forums
25 or #gentoo, so their only real interface with the users is via bugzilla.
26
27 3. Developers are busy working on features which affect many more people
28 and have a much greater demand than your package/ebuild. Unfortunately,
29 this is one you pretty much have to live with, unless of course you want
30 to contribute in the effort to get those features implemented, and
31 therefore give the developers more time to add things like packages and
32 ebuilds to the tree.
33
34 I am sure there are plenty of other reasons that I am missing, but you
35 start to see the trend. Sometimes simply posting a bug to bugzilla
36 isn't enough to get your package noticed.
37
38 > All of this could be easily automated... the idea that every package needs a
39 > maintainer is something that comes from Debian, and is imho unnecessary. You
40 > end up with a few problems: a limited number of maintainers with limited
41 > package interests and a lack of time to devote, and an alienated developer
42 > community who have no way to bug fix or add new ebuilds without going through
43 > the single developer. When that developers interests shift (as they
44 > invariably do), updates to the package become ignored, and once again the
45 > developer community can do nothing to fix this as the power rests with the
46 > maintainer.
47
48 As for the idea of *ever* automating any of the additions to ~arch or
49 arch, I quite frankly think it is a horrible idea. There are many
50 ebuild submissions to bugzilla which are very good, and there are just
51 as many that are absolutely appalling. The bad ones can cause some
52 serious damage to not only Gentoo's quality, but possibly even Gentoo's
53 stability. Imagine if someone purposefully added a broken/trojaned
54 package to bugzilla? Imagine if it was glibc?
55
56 The idea that every package needs a maintainer has little to do with
57 Debian, and more to do with the fact that having accountability in one's
58 actions tends to leave people more honest. It also tends to improve
59 quality, since the person who added the ebuild will be held accountable
60 for what the ebuild does to a user's system. The solution to the
61 "single developer" problem is the Gentoo herd system. There are usually
62 multiple developers responsible for a single ebuild/set of ebuilds,
63 rather than a single person.
64
65 Given that Gentoo will never have an automated ebuild submission system,
66 how does having a single developer decide to no longer maintain a
67 package become any worse than a user submitting an ebuild, it being
68 added, with no maintainer, mind you, as you would want, then the user
69 dropping off the face of the planet. Either way you are left with an
70 unmaintained ebuild, which lowers the quality, and possibly even the
71 security of our distribution as a whole. After all, what if the
72 unmaintained package has a security flaw in it that goes unnoticed?
73
74 The difference between a package having a Gentoo maintainer or not is
75 that with a Gentoo maintainer, the chances of something being
76 unmaintained are much less than simply accepting any ebuild from
77 anywhere and not having a dedicated maintainer. Usually, when a
78 developer leaves, devrel and others try to find a new maintainer for
79 that developer's packages. If it ends up being a long-term problem, we
80 decide on whether or not the package should remain in the portage tree.
81 There have been cases where a package was *not* removed simply because
82 there were users out there submitting fixed ebuilds for newer version,
83 etc to bugzilla.
84
85 Once again, active participation helps much more with Gentoo than any
86 amount of talk. When users ask, we listen. The more users that request
87 something, the greater the chances of us doing it. It all boils down to
88 there being only a limited number of developers and a limited number of
89 hours in the day. We have to prioritize. A flaw in kde-libs is
90 probably going to get higher priority than an ebuild for a new
91 lm-sensors front-end for XFCE, simply due to the numbers affected.
92
93 > There is no need to be defensive and start saying things like "if you don't
94 > like it this way then fork away.." when the desire of the complainer is to
95 > improve gentoo, not start/join another project.
96
97 I completely understand, and as I stated before, drum up some support
98 for the things you request and you'll get a lot farther in your quests
99 to improve Gentoo.
100
101 --
102 Chris Gianelloni
103 Developer
104 Games/LiveCD Teams
105 Gentoo Linux
106
107 Is your power animal a penguin?

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-dev] Stuff that makes people mad Jason Stubbs <jstubbs@g.o>
Re: [gentoo-dev] Stuff that makes people mad Jean Jordaan <jean@×××××××××××××××××.za>