Prioritising contact information in metadata.xml

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Prioritising contact information in metadata.xml

Jeroen Roovers-3
     Hi developers and other users,


since jakub[1] went completely missing a few weeks ago a few others and
I have been wrangling the bugs. I've heard rumours that this isn't
working smoothly yet. Of course most of that can be fully blamed on
bugzilla itself, but there are some things that need to be pointed out
or discussed.

One thing I'd like to point out is that if you don't agree with a
specific mangle, just CC whoever did it on the bug and explain.
If you don't give me the feedback, I can never know how you would
rather have wanted to get bugs delivered.

One other thing is that it is sometimes difficult to figure out to
whom a bug should be assigned, because metadata.xml for many packages
simply isn't clear. If you list a few developers as well as a herd,
does that mean you want bugs assigned to the herd or to a single
developer who happens to be in that list? Some packages list several
herds in metadata.xml. Bugs can be assigned to just one address
(or you get "Assignee: [hidden email],[hidden email] did not
match anything").

[2] has nothing explicit to say on this subject, sadly. It seems some
editors of metadata.xml use the file as a sort of CREDITS or AUTHORS.
While that may seem OK, the file is intended to give information about
ebuilds. ChangeLog is intended to credit authors (specifically
mentioning ebuild authors and contributors[3]).

So maybe this needs to be layed out more specifically in the Developer
Handbook, or maybe this needs to be discussed more. I can tell that
from my end, and possibly from the viewpoint of any user who is seeking
support contacts, listing more than one contact in metadata.xml is
rather pointless, unless descriptions are added so that it's clear
which component of a package is supported by whom.

All in all I guess we need to make the rules up as we go and decide
policy later. I suggest the first herd/address in the list should be
the primary contact. If you don't agree with that, please consult
metadata.xml for the package or reassign to bug-wranglers with an
explanation (and perhaps a promise to quickly change metadata.xml. :)


Kind regards,
     JeR


[1] Where is the old bugger? Anyone know? On a strictly human level, I
am getting quite worried.
[2]
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=4
[3]
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1#doc_chap3_sect6
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Prioritising contact information in metadata.xml

Luis Francisco Araujo
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeroen Roovers wrote:
|      Hi developers and other users,
|
|
| since jakub[1] went completely missing a few weeks ago a few others and
| I have been wrangling the bugs. I've heard rumours that this isn't
| working smoothly yet. Of course most of that can be fully blamed on
| bugzilla itself, but there are some things that need to be pointed out
| or discussed.
|
| One thing I'd like to point out is that if you don't agree with a
| specific mangle, just CC whoever did it on the bug and explain.
| If you don't give me the feedback, I can never know how you would
| rather have wanted to get bugs delivered.
|
| One other thing is that it is sometimes difficult to figure out to
| whom a bug should be assigned, because metadata.xml for many packages
| simply isn't clear. If you list a few developers as well as a herd,
| does that mean you want bugs assigned to the herd or to a single
| developer who happens to be in that list? Some packages list several
| herds in metadata.xml. Bugs can be assigned to just one address
| (or you get "Assignee: [hidden email],[hidden email] did not
| match anything").
|

I'd say that in the case of a herd listed , the bug should be sent
there. If it doesn't specify a herd but several developers, sending the
bug to any or all of them should be the rule.

| All in all I guess we need to make the rules up as we go and decide
| policy later. I suggest the first herd/address in the list should be
| the primary contact. If you don't agree with that, please consult

I agree.


- --

Luis F. Araujo "araujo at gentoo.org"
Gentoo Linux

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkgRBIoACgkQNir3WYj9aLp8UwCfeiHyHDQCDXd1nw0/oauctVVc
UWkAn0Y4b1Be65A0ThXqDQIbTXRGbKSv
=YVb7
-----END PGP SIGNATURE-----
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Prioritising contact information in metadata.xml

Mike Frysinger
In reply to this post by Jeroen Roovers-3
On Thursday 24 April 2008, Jeroen Roovers wrote:
> One other thing is that it is sometimes difficult to figure out to
> whom a bug should be assigned, because metadata.xml for many packages
> simply isn't clear. If you list a few developers as well as a herd,
> does that mean you want bugs assigned to the herd or to a single
> developer who happens to be in that list? Some packages list several
> herds in metadata.xml.

unfortunately this is dependent on the herd/developers.  debating which is
correct is pointless.  let's add a priority or some other marker to the dtd
so people updating the xml can indicate the preference themselves.

> Bugs can be assigned to just one address
> (or you get "Assignee: [hidden email],[hidden email] did not
> match anything").

that's why the CC list exists

> [2] has nothing explicit to say on this subject, sadly. It seems some
> editors of metadata.xml use the file as a sort of CREDITS or AUTHORS.
> While that may seem OK, the file is intended to give information about
> ebuilds. ChangeLog is intended to credit authors (specifically
> mentioning ebuild authors and contributors[3]).

agreed. metadata.xml is certainly not the place for giving credit.  use the
ChangeLog file.
-mike

signature.asc (844 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Prioritising contact information in metadata.xml

Robin H. Johnson-2
In reply to this post by Jeroen Roovers-3
On Thu, Apr 24, 2008 at 10:05:35PM +0200, Jeroen Roovers wrote:
> All in all I guess we need to make the rules up as we go and decide
> policy later. I suggest the first herd/address in the list should be
> the primary contact. If you don't agree with that, please consult
> metadata.xml for the package or reassign to bug-wranglers with an
> explanation (and perhaps a promise to quickly change metadata.xml. :)
Review the posts I made on the list last year about how to do assignment
in a sane fashion. I'll link them tonight when I'm back from the party
I'm hitting up.

They do describe all the cases that people came up with, including where
herds are too-specific or too broad.

--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : [hidden email]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

attachment0 (337 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Prioritising contact information in metadata.xml

Ulrich Mueller-2
In reply to this post by Luis Francisco Araujo
>>>>> On Thu, 24 Apr 2008, Luis Francisco Araujo wrote:

> | One other thing is that it is sometimes difficult to figure out to
> | whom a bug should be assigned, because metadata.xml for many packages
> | simply isn't clear. If you list a few developers as well as a herd,
> | does that mean you want bugs assigned to the herd or to a single
> | developer who happens to be in that list? Some packages list several
> | herds in metadata.xml. Bugs can be assigned to just one address

> I'd say that in the case of a herd listed , the bug should be sent
> there.

A common case is a herd plus a specific maintainer, and I think then
it should be assigned to the maintainer, with a CC to the herd's team.

> If it doesn't specify a herd but several developers, sending the bug
> to any or all of them should be the rule.

In this case, it should be assigned to the first developer listed, and
all others in CC.

Ulrich
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Prioritising contact information in metadata.xml

Luis Francisco Araujo
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ulrich Mueller wrote:
|>>>>> On Thu, 24 Apr 2008, Luis Francisco Araujo wrote:
|
|> | One other thing is that it is sometimes difficult to figure out to
|> | whom a bug should be assigned, because metadata.xml for many packages
|> | simply isn't clear. If you list a few developers as well as a herd,
|> | does that mean you want bugs assigned to the herd or to a single
|> | developer who happens to be in that list? Some packages list several
|> | herds in metadata.xml. Bugs can be assigned to just one address
|
|> I'd say that in the case of a herd listed , the bug should be sent
|> there.
|
| A common case is a herd plus a specific maintainer, and I think then
| it should be assigned to the maintainer, with a CC to the herd's team.
|
|> If it doesn't specify a herd but several developers, sending the bug
|> to any or all of them should be the rule.
|
| In this case, it should be assigned to the first developer listed, and
| all others in CC.
|

If this is the case, I think this should be stated somewhere in the docs
, since the order of listed maintainers don't have any priority, and I
personally would prefer to keep it so.


- --

Luis F. Araujo "araujo at gentoo.org"
Gentoo Linux

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkgRUVIACgkQNir3WYj9aLoEjQCeIvFaInENgCOhz65K9CaywFa4
C7gAnjjQAT82gerNwWmModYBVEpVHBrF
=V6VD
-----END PGP SIGNATURE-----
--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Prioritising contact information in metadata.xml

Tiziano Müller-3
In reply to this post by Jeroen Roovers-3
Jeroen Roovers wrote:
> All in all I guess we need to make the rules up as we go and decide
> policy later. I suggest the first herd/address in the list should be
> the primary contact. If you don't agree with that, please consult
> metadata.xml for the package or reassign to bug-wranglers with an
> explanation (and perhaps a promise to quickly change metadata.xml. :)

We're using XML 1.0 and as far as I know (please correct me if I'm wrong)
does the specification not guarantee element order. And because of this I
don't understand why we're not introducing a new attribute (let's call
it "primary_maintainer") which can be set to "true" for the primary
herd/maintainer (and which is being interpreted as "false" if not present).
Then it's clear which address has to be put in Bugzilla's "Assigned To:"
field...

Cheers,
Tiziano


--
[hidden email] mailing list

Reply | Threaded
Open this post in threaded view
|

Re: Re: Prioritising contact information in metadata.xml

Robin H. Johnson-2
On Thu, May 01, 2008 at 07:34:51AM +0200, Tiziano M?ller wrote:

> Jeroen Roovers wrote:
> > All in all I guess we need to make the rules up as we go and decide
> > policy later. I suggest the first herd/address in the list should be
> > the primary contact. If you don't agree with that, please consult
> > metadata.xml for the package or reassign to bug-wranglers with an
> > explanation (and perhaps a promise to quickly change metadata.xml. :)
> We're using XML 1.0 and as far as I know (please correct me if I'm wrong)
> does the specification not guarantee element order. And because of this I
> don't understand why we're not introducing a new attribute (let's call
> it "primary_maintainer") which can be set to "true" for the primary
> herd/maintainer (and which is being interpreted as "false" if not present).
> Then it's clear which address has to be put in Bugzilla's "Assigned To:"
> field...
Here was the original discussion and proposal on how to handle this:
http://thread.gmane.org/gmane.linux.gentoo.devel/48485

Why didn't it happen? No time to implement it basically.

--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : [hidden email]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

attachment0 (337 bytes) Download Attachment