From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1DzYa0-0000VO-57 for garchives@archives.gentoo.org; Mon, 01 Aug 2005 11:35:36 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j71BYoHT006349; Mon, 1 Aug 2005 11:34:50 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j71BXEM4000515 for ; Mon, 1 Aug 2005 11:33:14 GMT Received: from p061198130127.ppp.prin.ne.jp ([61.198.130.127] helo=opteron246.suzuki-stubbs.home) by smtp.gentoo.org with esmtpa (Exim 4.43) id 1DzYXm-0001qy-O5 for gentoo-dev@lists.gentoo.org; Mon, 01 Aug 2005 11:33:22 +0000 Received: by opteron246.suzuki-stubbs.home (Postfix, from userid 1000) id 3D7D4100E3D; Mon, 1 Aug 2005 20:33:59 +0900 (JST) From: Jason Stubbs To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Hold on portage feature requests Date: Mon, 1 Aug 2005 20:33:56 +0900 User-Agent: KMail/1.8.1 References: <200507282320.20087.jstubbs@gentoo.org> <42E90CBB.3080403@egr.msu.edu> In-Reply-To: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1195183.fI4nZCelrv"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200508012033.58878.jstubbs@gentoo.org> X-Archives-Salt: a634eac7-cb21-4abc-b36e-b374a9125471 X-Archives-Hash: f9ad24d0b0866dfd51030a87228291ed --nextPart1195183.fI4nZCelrv Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 01 August 2005 02:07, R Hill wrote: > Alec Joseph Warner wrote: > > Donnie Berkholz wrote: > >> > >> Are you having a tough time filtering out enhancements in your queries > >> or something? I don't understand how feature requests could possibly > >> interfere with anything besides other enhancements. > >> > >=20 > > Many of the enhancements aren't marked as such, >=20 > Then they should be. ;) There's nothing wrong with reclassifying your=20 > bugs to make it easier to manage them. The features are there exactly=20 > for this reason - so critical bugs don't get drowned out by less=20 > important bugs or enhancement requests. I guess it doesn't really=20 > matter, but it would have been just as easy to set the severity of these= =20 > bugs to min or enh rather than close them, and then they would still=20 > show up on a simple search. Several people have asked why the available bug attributes don't suffice. The reasons are quite simple: 1) Feature requests won't be addressed any time soon. It was suggested that closing the bugs as LATER will cause more duplicates and effect more work. I deferred (not closed!) 150 feature requests at least a third of which were duplicates. Because feature requests are not being addressed, they are piling up and users are not able to find duplicates with the bugs being open anyway. However, publicizing that feature requests have been put on hold has had the desired affect. There have been no new requests this past week. 2) Every bug change has to be dealt with at least twice. I try to monitor bugs via the emails sent as much as possible. With the amount generated by new feature requests and the numerous "+1" posts on existing requests, it is simply not feasible to parse the incoming mail without making at least two passes. Here, I can hear people suggesting that I just /dev/null the email and monitor bugs via bugzilla. My answer? Opening listing 100+ bugs (that's assuming the bugs were properly categoriz= ed (which they are not) - there is actually about 300 bugs open other than the 150 feature requests closed) as well as the bugs is a slow painful process on a 32000bps connection. 3) To be able to utilize bug mails beyond notification. I've written a simple script to create a report of what bugs have changed and how many times within a set period. I'm posting the results to the portage mailing list in order to try and fish out some fresh blood. Having these reports littered with feature requests means that the important stuff that is causing users problems is hidden between all the "oh wouldn't it be lovely" bugs. Yes, this has also been successful already. There's been patches posted on various bugs that actually fix the root cause of the problems outlined. 4) Less user frustration. The two most frequent comments at the moment are "is anybody looking at this?" and "it's been over a year!" Users knowing what's going on and especially finding that their minor bugs are starting to gain some activity can only be a good thing. I could figure out some more reasons if it's really necessary, but the past week has shown that the path chosen (even if there is some better path) is not a bad one as things are working out well thus far. =2D- Jason Stubbs --nextPart1195183.fI4nZCelrv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBC7gimxvWNPsk/ZP4RAkLHAJ9WRhUArosqBbiBVF/rtV7sKQTbrQCgtc88 pOFPTXAyLqyQD6gAaspNXSg= =BzHb -----END PGP SIGNATURE----- --nextPart1195183.fI4nZCelrv-- -- gentoo-dev@gentoo.org mailing list