On Sun, Oct 19, 2008 at 03:29:46PM +0200, Robert Buchholz wrote: > > 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. It's much harder to edit in the CC and assigned-to input boxes than in the comment area.
> > 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 #2 is the best result here, and I think most summary sentences will be structured such that the broken thing is the first atom, so we shouldn't re-order the category meta to the end. > > 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? Sorry, I did mean description. My diff to metadata.dtd was right, just this text was wrong. > > 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 I'll handle this in the other subthread. -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpBWlICXWBv5.pgp
Description: PGP signature
