Re: [gentoo-dev] metadata.xml un<herd/>-ization, v2

[Michał Górny]

Dnia 2014-12-09, o godz. 17:17:35
"Andreas K. Huettel" <dilfridge@g.o> napisał(a):

>
> > > 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>kde@g.o</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.

I'm all for keeping it simple. However, backwards compatibility makes
it hard to keep things simple. I'd love to do, say, metadata.yml
supporting stuff like:

- maintainer: foo@g.o, bar@g.o

- maintainer:
  - name: Foo Bar
    email: foo@g.o
  - bar@g.o

(pseudo-code, not sure if it's 100% valid YAML)

But that's another topic, and a lot of work to support, and most
of the tools will never be fixed to support it.

> > 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.

Just the e-mail.

> (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.)

How about just using the e-mail? You don't CC all the team members, do
you?

> 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.

That is *precisely the goal* of this. We scratch <herd/> and <project/>,
and just use well-supported <maintainer/> tag. type="" is entirely
optional, unobtrusive and backwards-compatible with existing apps.
And yes, with just <maintainer/> tag the rule in bug assignment is
always to the first entry.

-- 
Best regards,
Michał Górny