On Sunday 19 October 2008, Robin H. Johnson wrote: > Now into it's Nth great year, I bring you the fourth edition of the > automatic assignment proposal. </truman-show>
Yay! > 5. Javascript then appends the server results into the "Additional > Comments" box: a suggested assignee and suggested CC values, with > logic as to why. > 6. The wrangler can copy and paste the data into the fields, editing > further as desired. It would be nice if we had a checkbox "Accept Changes" or of that "Suggest" button would fill in the fields itself. Two more copy and paste actions less. > 2. If the summary line contains a package atom for a package that > does not exist, but a category that does exist, use the metadata.xml > for that category. We have three alternatives here: If at least one valid atom is found, but other atoms are present that only have an existing category... (1) ignore metadata for that category (2) treat category as regular metadata (3) append categtory metadata to the end of maintainer list For example, "dev-java/ibm-jkd-bin breaks with x11-base/xorg-server-1.3.0.0" With the typo in ibm-jdk-bin, the ordered list of maintainers to assign/cc would* be (1) [EMAIL PROTECTED] (2) [EMAIL PROTECTED],[EMAIL PROTECTED] (3) [EMAIL PROTECTED],[EMAIL PROTECTED] * if java herd maintained dev-java category > 3. If a maintainer element contains the non-default 'ignoreauto=1' > attribute AND a non-empty role element (describing why this > maintainer should not be contacted), delete it from the list. The role element is not present for maintainers in metadata.xml, only in herds.xml. Should we leave this out, or do you mean the description element? > 1. For handling <herd>no-herd</herd>, we should add an entry into > herds.xml to catch it (maintainer-needed <at> g.o). Every herd listed > in an ebuild MUST be in herds.xml. I agree for consistency reasons, the "no-herd" should be listed on herds.xml. However, it should not implicate maintainer-needed, as a lot of maintained ebuilds carry no-herd and all maintainer-needed ebuilds carry a "[EMAIL PROTECTED]" maintainer in their own metadata.xml > Effects on metadata.xml syntax > ============================== > - Category metadata is now permitted to have herd and maintainer > elements. - New attribute under maintainer, 'ignoreauto'. Just to add a rationale here: This entry is used to assign / cc to ebuild submissions, i.e. "Add dev-perl/Some-CPAN-Module to the tree" could figure out [EMAIL PROTECTED] automatically. Robert
signature.asc
Description: This is a digitally signed message part.
