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 1DyCNS-0001Up-Sq for garchives@archives.gentoo.org; Thu, 28 Jul 2005 17:41:03 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j6SHdrwb007178; Thu, 28 Jul 2005 17:39:53 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 j6SHcFub001351 for ; Thu, 28 Jul 2005 17:38:15 GMT Received: from adsl-67-39-48-193.dsl.milwwi.ameritech.net ([67.39.48.193] helo=exodus) by smtp.gentoo.org with esmtpa (Exim 4.43) id 1DyCLE-0003S5-UO for gentoo-dev@lists.gentoo.org; Thu, 28 Jul 2005 17:38:45 +0000 Date: Thu, 28 Jul 2005 12:38:55 -0500 From: "Brian D. Harring" To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Hold on portage feature requests Message-ID: <20050728173855.GC13704@exodus> References: <200507282320.20087.jstubbs@gentoo.org> <42E90660.4010001@gentoo.org> 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; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TYecfFk8j8mZq+dy" Content-Disposition: inline In-Reply-To: <42E90660.4010001@gentoo.org> User-Agent: Mutt/1.5.8i X-Archives-Salt: 77ebaf70-f958-4b65-ad61-a30924c0817e X-Archives-Hash: 1e811355899711c1cc63358e4b5c6de3 --TYecfFk8j8mZq+dy Content-Type: text/plain; charset=utf8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 28, 2005 at 09:22:56AM -0700, Donnie Berkholz wrote: > Jason Stubbs wrote: >=20 > | The reason behind this is that at approximately two thirds of bugs > received > | are feature requests and they are drowning at the real bugs. More > importantly, > | the critical bugs are becoming very hard to keep track of. This, at a t= ime > | when we are focusing on fixing major and critical bugs only so as to > get the > | next version completed quicker. >=20 > 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. Well... we have over 350 bugs open (roughly). How do=20 continual "we want xyz implemented" screw with things? Dupes up the=20 wing wang, lot of continual requests for the same thing, etc, lot of=20 old bugs that need attention but get drowned out by new bugs (or new=20 bugs that flat out miss old bugs due to their age). Basically, this is a bit along the lines of trying to keep things=20 easily filterable so that people who want to work on portage can=20 quickly see what relevant (stable) bugs exist, and can dig up the=20 feature requests (fricking multitude of them). The feature requests aren't being ignored, the issue comes down to=20 what I stated in an earlier email on this ml; with the current code,=20 if it were easy to pull it off, we would do so without hesitation=20 already- most of the features *can* be pulled off without too much=20 hackery, but it requires (long needed) changes to portage innards. Two main thrusts of work at this point, stable bug squashing, and=20 rewriting sizable chunks of the underlying portagelib code so that the=20 feature requests (sync per repo, seperated caches per repo, use deps,=20 slot deps, EAPI changes, glep33, glep37 (potentially), better binpkg=20 handling, drop md5/mtime as default for unmerge checks and use=20 refcounts, framework for remote, etc) are doable. Essentially it's squashing old noise on the bugs till we can actually=20 address it. Like I said above, two main thrusts of work are stable,=20 and mangling the codebase so that we can actually pull this stuff off,=20 and with the limited # of people hacking on portage, more time devoted=20 to that the better. So... yeah. not dodging bugs, just need a way to do something about=20 massive # of older bugs and noise on the bugs ml. Man power issues=20 somewhat, but mainly trying to focus on taking care of what needs to=20 be taken care of right now. Patches make a world of difference, since=20 it A) involves people in the code, B) allows us to work on what needs=20 to be addressed *now*, without digging about for a feature that in the=20 grand scheme, doesn't matter too much. Clarifiaction of B, which=20 matters most in the long run, a UI change, or use deps? Etc. pardon the long winded explanation... It's something that has been=20 toyed with for a while, and so far we (portage devs) seem to think=20 it's a good way to at least get a handle on the current mess. ~harring --TYecfFk8j8mZq+dy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC6RgvvdBxRoA3VU0RAnPGAKCqfzNFgNEEhBDFvNJhVbbQd+3tHwCgnrx0 zgSdtgE4ur5NbABJk2mThP8= =bjgW -----END PGP SIGNATURE----- --TYecfFk8j8mZq+dy-- -- gentoo-dev@gentoo.org mailing list