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? |