From: Chris Gianelloni <wolf31o2@gentoo.org>
To: Chris Bainbridge <c.j.bainbridge@ed.ac.uk>
Cc: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Stuff that makes people mad
Date: Fri, 21 May 2004 11:39:27 -0400 [thread overview]
Message-ID: <1085153967.25140.76.camel@localhost> (raw)
In-Reply-To: <200405211554.06946.c.j.bainbridge@ed.ac.uk>
[-- Attachment #1: Type: text/plain, Size: 5902 bytes --]
On Fri, 2004-05-21 at 10:54, Chris Bainbridge wrote:
> One of the things that seems to annoy lots of people is this idea that their
> ebuilds are being ignored. I've usually got a bunch (8 at the moment) of
> ebuilds in bugs.gentoo waiting to be processed.. the oldest is almost a year
> old now. There ought to be some sort of procedure for dealing with user
> submitted ebuilds. I would suggest a system of putting them in ~x86 (or
> whatever) immediately, and if there are no bug reports for x days move them
> to x86.
If your ebuild is being ignored, it is probably because of one of a few
possible reasons.
1. Developers responsible for that area of Gentoo don't see the value of
it. While this is sometimes a sad thing to think about, it happens. A
good way to solve this is to drum up support for your ebuild. An ebuild
submitted to bugzilla with no comments from other users doesn't *appear*
to have nearly as much support as an ebuild with lots of comments from
users on how they wish this was in portage, and how well it works, etc.
2. Developers responsible for that area of Gentoo don't have the time to
maintain another package they don't understand. In a lot of cases, I
would say that this is the main factor in an ebuild staying in
bugzilla. Once again, a good show of support from users is always a
good motivator. Remember that many developers *never* visit the forums
or #gentoo, so their only real interface with the users is via bugzilla.
3. Developers are busy working on features which affect many more people
and have a much greater demand than your package/ebuild. Unfortunately,
this is one you pretty much have to live with, unless of course you want
to contribute in the effort to get those features implemented, and
therefore give the developers more time to add things like packages and
ebuilds to the tree.
I am sure there are plenty of other reasons that I am missing, but you
start to see the trend. Sometimes simply posting a bug to bugzilla
isn't enough to get your package noticed.
> All of this could be easily automated... the idea that every package needs a
> maintainer is something that comes from Debian, and is imho unnecessary. You
> end up with a few problems: a limited number of maintainers with limited
> package interests and a lack of time to devote, and an alienated developer
> community who have no way to bug fix or add new ebuilds without going through
> the single developer. When that developers interests shift (as they
> invariably do), updates to the package become ignored, and once again the
> developer community can do nothing to fix this as the power rests with the
> maintainer.
As for the idea of *ever* automating any of the additions to ~arch or
arch, I quite frankly think it is a horrible idea. There are many
ebuild submissions to bugzilla which are very good, and there are just
as many that are absolutely appalling. The bad ones can cause some
serious damage to not only Gentoo's quality, but possibly even Gentoo's
stability. Imagine if someone purposefully added a broken/trojaned
package to bugzilla? Imagine if it was glibc?
The idea that every package needs a maintainer has little to do with
Debian, and more to do with the fact that having accountability in one's
actions tends to leave people more honest. It also tends to improve
quality, since the person who added the ebuild will be held accountable
for what the ebuild does to a user's system. The solution to the
"single developer" problem is the Gentoo herd system. There are usually
multiple developers responsible for a single ebuild/set of ebuilds,
rather than a single person.
Given that Gentoo will never have an automated ebuild submission system,
how does having a single developer decide to no longer maintain a
package become any worse than a user submitting an ebuild, it being
added, with no maintainer, mind you, as you would want, then the user
dropping off the face of the planet. Either way you are left with an
unmaintained ebuild, which lowers the quality, and possibly even the
security of our distribution as a whole. After all, what if the
unmaintained package has a security flaw in it that goes unnoticed?
The difference between a package having a Gentoo maintainer or not is
that with a Gentoo maintainer, the chances of something being
unmaintained are much less than simply accepting any ebuild from
anywhere and not having a dedicated maintainer. Usually, when a
developer leaves, devrel and others try to find a new maintainer for
that developer's packages. If it ends up being a long-term problem, we
decide on whether or not the package should remain in the portage tree.
There have been cases where a package was *not* removed simply because
there were users out there submitting fixed ebuilds for newer version,
etc to bugzilla.
Once again, active participation helps much more with Gentoo than any
amount of talk. When users ask, we listen. The more users that request
something, the greater the chances of us doing it. It all boils down to
there being only a limited number of developers and a limited number of
hours in the day. We have to prioritize. A flaw in kde-libs is
probably going to get higher priority than an ebuild for a new
lm-sensors front-end for XFCE, simply due to the numbers affected.
> There is no need to be defensive and start saying things like "if you don't
> like it this way then fork away.." when the desire of the complainer is to
> improve gentoo, not start/join another project.
I completely understand, and as I stated before, drum up some support
for the things you request and you'll get a lot farther in your quests
to improve Gentoo.
--
Chris Gianelloni
Developer
Games/LiveCD Teams
Gentoo Linux
Is your power animal a penguin?
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2004-05-21 15:31 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-21 1:46 [gentoo-dev] Stuff that makes people mad C. Brewer
2004-05-21 4:08 ` Andrew Gaffney
2004-05-21 6:33 ` Robin H. Johnson
2004-05-21 13:19 ` John Nilsson
2004-05-21 13:39 ` Chris Gianelloni
2004-05-21 14:54 ` Chris Bainbridge
2004-05-21 15:04 ` Stephen Becker
2004-05-21 16:29 ` Josh Glover
2004-05-21 16:36 ` Jon Portnoy
2004-05-21 16:40 ` Ciaran McCreesh
2004-05-21 17:39 ` Josh Glover
2004-05-21 17:59 ` Ciaran McCreesh
2004-05-21 22:07 ` Mike Frysinger
2004-05-23 15:54 ` Karl Trygve Kalleberg
2004-05-23 17:13 ` Joseph Booker
2004-05-23 21:46 ` Karl Trygve Kalleberg
2004-05-21 18:14 ` Christian Gut
2004-05-21 18:36 ` Marius Mauch
2004-05-21 20:53 ` Joseph Booker
2004-05-21 18:55 ` Chris Gianelloni
2004-05-21 15:32 ` Jason Stubbs
2004-05-21 16:12 ` Chris Bainbridge
2004-05-21 16:33 ` Ciaran McCreesh
2004-05-21 16:42 ` Chris Bainbridge
2004-05-21 16:53 ` Ciaran McCreesh
2004-05-21 18:35 ` Chris Gianelloni
2004-05-21 17:40 ` Jason Stubbs
2004-05-21 15:39 ` Chris Gianelloni [this message]
2004-05-21 15:42 ` Jason Stubbs
2004-05-25 16:02 ` Jean Jordaan
2004-05-21 15:43 ` Tom Payne
2004-05-21 16:11 ` Allen Dale Parker
2004-05-21 16:19 ` Jon Portnoy
2004-05-21 19:49 ` Stuart Herbert
2004-05-21 16:59 ` John Nilsson
2004-05-21 17:14 ` Jon Portnoy
2004-05-21 17:16 ` Tom Payne
2004-05-21 17:25 ` Jason Stubbs
2004-05-21 21:59 ` John Nilsson
2004-05-21 22:06 ` Stuart Herbert
2004-05-21 22:34 ` John Nilsson
2004-05-21 22:43 ` Joseph Booker
2004-05-23 13:42 ` John Nilsson
2004-05-21 18:45 ` Chris Gianelloni
2004-05-21 22:28 ` John Nilsson
2004-05-21 22:40 ` Joseph Booker
2004-05-21 23:27 ` John Nilsson
2004-05-21 23:59 ` Joseph Booker
2004-05-22 3:29 ` John Nilsson
2004-05-22 13:02 ` Stuart Herbert
2004-05-23 14:05 ` John Nilsson
2004-05-23 14:45 ` Allen Dale Parker
2004-05-23 19:56 ` John Nilsson
2004-05-23 15:40 ` Joseph Booker
2004-05-23 21:17 ` John Nilsson
2004-05-23 23:12 ` Marius Mauch
2004-05-24 1:26 ` John Nilsson
2004-05-23 23:34 ` Joseph Booker
2004-05-24 4:11 ` [gentoo-dev] " Duncan
2004-05-24 4:59 ` John Nilsson
2004-05-24 8:21 ` Paul de Vrieze
2004-05-21 18:42 ` [gentoo-dev] " Stuart Herbert
2004-05-21 13:30 ` Chris Gianelloni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1085153967.25140.76.camel@localhost \
--to=wolf31o2@gentoo.org \
--cc=c.j.bainbridge@ed.ac.uk \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox