Re: [gentoo-dev] One-Day Gentoo Council Reminder for January
> On Wed, 7 Jan 2009, Donnie Berkholz wrote: > Does anyone have additional topics for the Jan 22 meeting? Could you cover the PMS/documentation issue of bug 250077? Or, if you prefer to generalise, set up a procedure to resolve such conflicts? Ulrich
Re: [gentoo-dev] One-Day Gentoo Council Reminder for January
On 03:07 Wed 07 Jan , Mike Frysinger wrote: > This is your one-day friendly reminder ! The monthly Gentoo Council > meeting is tomorrow in #gentoo-council on irc.freenode.net. No topics submitted to the 2-week reminder thread, so no meeting. I've got a few topics for the Jan 22 meeting: - Open bug review (it's too soon post-holiday to do this tomorrow IMHO) - Prepare between now and then for a couple of votes by discussing on the -council list: - Adding the "reopen nominations" false person to all council elections - Adding a vote on council size to all council elections. (This could be another false person, or a separate ballot or something.) Does anyone have additional topics for the Jan 22 meeting? -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgpazhukKtr7D.pgp Description: PGP signature
[gentoo-dev] Get ready for fantastic nights
Catch rapturous girls' looks on your zipper protuberance. http://groupbring.com
[gentoo-dev] One-Day Gentoo Council Reminder for January
This is your one-day friendly reminder ! The monthly Gentoo Council meeting is tomorrow in #gentoo-council on irc.freenode.net. See the channel topic for the exact time (but it's probably 2000 UTC). If you're supposed to show up, please show up. If you're not supposed to show up, then show up anyways and watch your Council monkeys dance for you. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/
[gentoo-dev] Re: [v4] Planning for automatic assignment computation of bugs
Peter Volkov wrote: > ? ???, 04/01/2009 ? 18:57 +0100, Robert Buchholz ?: >> Accepting the fact that different teams have different preferences, we >> need to find a solution for them to set theirs individually. This could >> either be the order of elements in metadata.xml (and would set the >> preference on a per-package basis) or some attribute in herds.xml >> (which would be a global setting per herd, and we'd need to find a >> default). > > It looks like we really need some per-team configuration for default > assignment. I agree, given that it's not going to affect running systems (I hope); in the longer term, it would be nice to be able to configure by pkg, cat or herd. > Probably it's good idea to add 'weight' (or 'nice') > attribute for and elements both in herds.xml and > metadata.xml. Bug assignment field will be selected from the elements > with minimal weight (least nice ;)). Shouldn't the 'nicest' entity take it? ;) A simple assignToHerd="yes|no|" (or 0|1) might be easier to deal with (otherwise you're going to have a maintenance headache with the variant levels?) and would deal with all the use-cases afaict; a team does [eg kde/gnome] or does not want bugs, unless the category/CP/CPV merits a change in that policy. Obviously if none set, use the maintainer list as-is without filtering. Sure, it can be done by patching the tree over time, but it seems crude and a further maintenance + bug-wrangling burden for no benefit, when the coders are on-hand and engaged to tweak the new impl. OFC, a rush to completion is understandable, given how long this has been in the planning; I'd argue that's a reason to go the final ten metres.