On Sun, Jan 04, 2009 at 06:12:17PM +0000, Mike Auty wrote:
> a) herds.xml per-herd priority flag (herd gets assigned)
> b) metadata.xml priority element (can be opt-in or opt-out)
> c) order of elements in metadata.xml
> 
> I'm personally not keen on the order of elements, since adding meaning
> to the order might mean a fair number of misassignments until people fix
> the metadata.xml files.
How many metadata files have the ordering wrong to start with?
Of the packages I maintain, just looking at a handful, very few have it
bad enough that I'd bother complaining rather than just changing them.

> The herds.xml element isn't very specific, but if the herd-first rules
> apply to the whole herd, then it's probably the least-impact solution.
> 
> Finally, if we think we'll ever need something more specific than
> herds.xml, we could add an extra element.  <priority type="herd"> or
> <priority type="maintainer"> could be added to the minority case (I'm
> not sure which has fewer ebuilds, but if there's hard and fast rules
> this should be relatively automatable).
Neither set of rules is ideal. Ordering makes a lot of sense when you
just read it. Consider metadata with multiple maintainers and multiple
herds. Either you have to start assigning explicitly (requires editing
metadata.xml), or you need to fall back to ordering. If you're going to
do ordering further down, why not do it from the start and be done with
it.

For anybody that wants to complain that XML is unordered - it isn't,
consider an HTML document that is also well-formed XML and validates
against a DTD. You wouldn't want your paragraphs changing order on you.

Count of total <herd>+<mainteiner> elements and how many metadata.xml files
have the count:
1  7842
2  4958
3   290
4    35

By number of herds:
0    26
1 12720
2   359
3    19
4     1

By number of maintainers:
0  8135
1  4730
2   241
3    19

If we assume that every metadata.xml with 2 or more items is wrong, thats at
most 40% of the tree.  I say go with ordering. I think it will affect less than
10% of packages in the end, and for large swaths it won't matter (dev-perl and
dev-$LANG in general, which account for some 20% of the tree).

Also, maintainers that don't want dupe assignments (normally because they in
the herd) are going to be editing anyway, and I think that will cover a lot of
the required edit cases as well.

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@g.o
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85