From mboxrd@z Thu Jan 1 00:00:00 1970 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 j4OKm57v008890 for ; Tue, 24 May 2005 20:48:05 GMT Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by smtp.gentoo.org with esmtp (Exim 4.43) id 1DagJx-0003sU-VV for gentoo-dev@lists.gentoo.org; Tue, 24 May 2005 20:48:14 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DagGf-0002wR-F3 for gentoo-dev@gentoo.org; Tue, 24 May 2005 22:44:49 +0200 Received: from hsdbyk206-163-249-51.sasknet.sk.ca ([206.163.249.51]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 May 2005 22:44:49 +0200 Received: from dirtyepic by hsdbyk206-163-249-51.sasknet.sk.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 May 2005 22:44:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: R Hill Subject: [gentoo-dev] Re: Pinboard of outdated ports Date: Tue, 24 May 2005 14:44:17 -0600 Message-ID: References: <20050523171138.GA22313@neurogen> <42923403.3080007@gentoo.org> <20050523225024.GC5870@neurogen> <429262B1.90109@gentoo.org> <20050524052649.GA5733@neurogen> <1116941770.14290.119.camel@cgianelloni.nuvox.net> 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: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: hsdbyk206-163-249-51.sasknet.sk.ca User-Agent: Mozilla Thunderbird 1.0+ (X11/20050519) In-Reply-To: <1116941770.14290.119.camel@cgianelloni.nuvox.net> Sender: news X-Archives-Salt: fdf9c591-0f88-442d-b405-8719c411e314 X-Archives-Hash: 1453af1fb8ac80ffc3fa95bc97bbe3e4 Chris Gianelloni wrote: >>I dunno if it's really big work to have a look at one site to see if >>there are ebuilds you missed when they were updated. >>It was not my intention to make really more work. It was just to find a faster >>way for outdated ebuilds getting updated. > There is really only one way to do this. Figure out how to give the > developers more time to develop. Right. I think most maintainers keep on top of what's happening with their charges. It's not that they've missed the fact that a new version has been released, it's that they haven't had the time to bump it yet. This might be less true for pkgs that don't have a single maintainer but are covered by a herd, but even in that case it's a matter of having time, not being oblivious that there's an update. > Having to search through bugs.gentoo.org, plus some external site, would > increase the time needed to find packages in need of upgrade, as some > will be filed as bugs, which would need to be resolved, so they would > have to be searched for *anyway* in bugzilla. > > The most productive thing you could do, would be to figure out a simple > way of testing ebuilds, marking them as tested, and assigning them to > the proper parties quicker than is being done now. I like this. It could probably be done through keywording, and in fact the keywords are already there (ebuild and tested)[1]. They just never get used. ;) Maybe raising people's (user's) awareness of their existence and how to use them properly would help. I'd be willing to write up a Bugzilla user-guide if there's any interest in it; I've been meaning to write one for the wiki/forum anyways. As for what happens after a ebuild is tested, I see a couple options. Devs can always just keep doing what they do now and just use the tested keyword as a handy at-a-glance reference. Or, you could implement the Bugzilla request system[2][3] to allow a tester to flag a bug ready for review by a developer. I think this would both improve the turn-around time on bumps and save some time for the devs by letting them know that any such request both has an ebuild attached and that ebuild has been tested by the community. Adding a review request flag does add a little more complexity to the process of using bugzilla, but with proper user documentation I think the benefit will outweigh the cost. > What we really need is to have the AT program extended from just amd64 > to every arch, including x86 (which desperately needs an arch team). Really? What does such a team do? --de. [1]https://bugs.gentoo.org/describekeywords.cgi [2]http://www.bugzilla.org/features/#rs [3]https://bugzilla.mozilla.org/flag-help.html -- gentoo-dev@gentoo.org mailing list