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
