From: "Stephen P. Becker" <geoman@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Bug voting
Date: Tue, 27 Jul 2004 19:01:17 -0400 [thread overview]
Message-ID: <4106DEBD.6070502@gentoo.org> (raw)
In-Reply-To: <200407271526.46575.absinthe@gentoo.org>
>
>>| I frankly don't understand why you're so outspoken on this issue. You
>>| can ignore votes if that's what you choose to do. This is not a
>>| policy change proposal, this is an enhancement request for Bugzilla.
>>
>>1) Because it will lead to "this bug has over a hundred votes, why is
>>it being ignored?" posts.
>
>
> And would such posts be unreasonable? I don't think so. If a bug has a
> large # of votes relative to everything else, and it IS being ignored,
> it's a valid question.
>
The answer is, that depends on the feature/ebuild/bug being voted on. I
think ciaranm's thought on this point really gets down to the heart of
the problem with voting.
There are two ways of looking at this. First, we as devs have a
responsibility to incorporate features/ebuilds and fix bugs that our
users want. Second, we have a responsibility to protect our users from
completely fragging their systems, even those who have demonstrated they
will go out of their way to do so at any chance.
I think the first point is adequately covered by bugzilla as it is. If
a user wants a new ebuild included or a bug fixed, he/she files a bug
for it. The problem with this is that we simply don't have enough devs
right now to cover the sheer volume of stuff in bugzilla. This is a
fixable problem, however. As for the second point, I think we already
do a good job at that, like not including certain kernel source packages
that include potentially dangerous patches like reiser4. We also inform
users we will not support them if they install 3rd-party-sources or
stuff from breakymgentoo. This is all very reasonable.
Considering these two points, I think you have to either say "yes, we
are going to prioritize high votes" or "we're going to protect our users
from potentially unstable stuff and use discretion instead."
Now that I've rambled on, let me get to what I really think. I believe
bug voting would be great for bugs that are truly problems with
supported configurations/ebuilds. However, I do not think voting should
be considered for additions of new ebuilds into portage. It will create
too many posts whining that system-killer-6.6.6.ebuild has not been
added to portage. As I said before, I'm not sure we can have it both
ways without there being problems, so I would say voting is a bad idea.
Steve (geoman)
--
gentoo-dev@gentoo.org mailing list
next prev parent reply other threads:[~2004-07-27 23:01 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-27 16:54 [gentoo-dev] Bug voting Dylan Carlson
2004-07-27 17:04 ` Ciaran McCreesh
2004-07-27 17:21 ` Chris Bainbridge
2004-07-27 17:27 ` Dylan Carlson
2004-07-27 17:39 ` Peter Johanson
2004-07-27 17:54 ` Olivier Crete
2004-07-27 18:20 ` Chris Gianelloni
2004-07-27 18:41 ` Lance Albertson
2004-07-27 17:59 ` Jason Rhinelander
2004-07-27 19:31 ` [gentoo-dev] " Duncan
2004-07-27 18:07 ` [gentoo-dev] " Ciaran McCreesh
2004-07-27 18:18 ` Dylan Carlson
2004-07-27 18:45 ` Ciaran McCreesh
2004-07-27 19:26 ` Dylan Carlson
2004-07-27 20:09 ` Ciaran McCreesh
2004-07-27 20:23 ` Donnie Berkholz
2004-07-27 20:29 ` Spider
2004-07-27 20:37 ` Dylan Carlson
2004-07-27 21:39 ` Ciaran McCreesh
2004-07-27 22:24 ` Dylan Carlson
2004-07-27 22:59 ` Ciaran McCreesh
2004-07-27 23:12 ` Dylan Carlson
2004-07-28 7:06 ` Tom Wesley
2004-07-27 22:49 ` Tommi Pirinen
2004-07-27 23:07 ` Ciaran McCreesh
2004-07-27 23:46 ` Tommi Pirinen
2004-07-28 6:55 ` Tom Wesley
2004-07-28 7:52 ` Georgi Georgiev
2004-07-27 23:26 ` [gentoo-dev] " Gabriel Ebner
2004-07-27 23:41 ` Gabriel Ebner
2004-07-27 23:48 ` Gabriel Ebner
2004-07-27 23:52 ` Gabriel Ebner
2004-07-28 0:02 ` Ciaran McCreesh
2004-07-28 0:08 ` Mike Frysinger
2004-07-28 0:10 ` Gabriel Ebner
2004-07-28 0:08 ` Jon Portnoy
2004-07-28 0:14 ` Gabriel Ebner
2004-07-28 0:09 ` Dylan Carlson
2004-07-28 0:21 ` Gabriel Ebner
2004-07-28 0:30 ` Gabriel Ebner
2004-07-27 21:06 ` [gentoo-dev] " David Sparks
2004-07-27 23:01 ` Stephen P. Becker [this message]
2004-07-28 3:48 ` Kumba
2004-07-27 19:49 ` Kurt Lieber
2004-07-27 19:53 ` Lance Albertson
[not found] ` <4108A16D.9090508@butsugenjitemple.org>
[not found] ` <4108ECA5.1020102@gentoo.org>
[not found] ` <4108F3A5.1000505@butsugenjitemple.org>
2004-07-29 13:11 ` Lance Albertson
2004-07-29 15:14 ` [gentoo-dev] " Duncan
2004-07-29 17:50 ` Dylan Carlson
2004-07-30 2:41 ` Ciaran McCreesh
2004-07-30 4:00 ` Dylan Carlson
2004-07-30 11:05 ` [gentoo-dev] " Duncan
2004-08-06 10:09 ` [gentoo-dev] " Paul de Vrieze
2004-07-27 20:09 ` [gentoo-dev] Bug voting++ Frank van de Pol
2004-07-27 21:09 ` Dylan Carlson
2004-07-28 0:26 ` [gentoo-dev] Re: Bug voting Joel Konkle-Parker
2004-07-28 2:53 ` [gentoo-dev] " Mike Gardiner
2004-07-28 3:11 ` Robin H. Johnson
2004-07-28 6:55 ` Tom Wesley
2004-07-28 14:12 ` Dylan Carlson
2004-07-28 23:58 ` [gentoo-dev] " Joel Konkle-Parker
2004-07-29 0:38 ` Dylan Carlson
-- strict thread matches above, loose matches on Subject: below --
2004-07-27 18:17 [gentoo-dev] " Brian Harring
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=4106DEBD.6070502@gentoo.org \
--to=geoman@gentoo.org \
--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