> > As far as I know the typical way to edit metadata.xml files for all of us > > is still by hand in a text editor, and I prefer a lot typing > > > > <herd>kde</herd> > > > > over > > > > <maintainer type="herd">kde</maintainer> > > <maintainer type="herd"> > <email>k...@gentoo.org</email> > <name>Lovely KDE herd</name> > </maintainer> > > to be more precise.
Ugh. Even more ugly stuff from the department of redundancy department. (Yeah usually I just copy an existing file too...) Keep it simple. The only result of stuffing more and more requirements into auxiliary files is that noone will fill them out completely. > 1. valid <email/> is much more useful than semi-ambiguous <herd/>, > > 2. bug assignment in order is simpler than magical rules like > 'maintainer first, herd second unless description says otherwise', > > 3. herds.xml is global, metadata.xml is per-repo. > > Many of us *read* metadata.xml via cat or simple text editor, and don't > want to be forced to use slow tools like 'equery' to make > semi-meaningful output out of it. So the solution is to duplicate all information into every package directory. Great. (And if I want to send an e-mail to the postgresql team I still have to figure out how their alias looks like or find a package that they maintain first.) Why not instead come up with a new set of rules (and maybe new tags) that simplify? As example, scratch <herd/>, add <project/> with a 1:1 transformation of argument to mail address. As example, always assign bugs to first entry. -- Andreas K. Huettel Gentoo Linux developer kde, council
signature.asc
Description: This is a digitally signed message part.