[gentoo-dev] irregular metdata.xml check

[gentoo-dev] irregular metdata.xml check

[Thilo Bangert]

[-- Attachment #1: Type: text/plain, Size: 2812 bytes --]

Welcome to this years edition of the metadata check.

Todays fingerpointing

herd without email: secure-tunneling
herd without email: middle-east

app-admin/eselect-audicle               <herd> empty
app-admin/eselect-chuck                 <herd> empty
app-admin/eselect-miniaudicle           <herd> empty
app-admin/eselect-sndpeek               <herd> empty
net-im/minbif                           <herd> empty
sys-kernel/dracut                       <herd> empty
x11-libs/libvdpau                       <herd> empty
x11-misc/vdpauinfo                      <herd> empty
virtual/perl-Filter                     <herd> empty
virtual/perl-i18n-langtags              <herd> empty
virtual/perl-Package-Constants          <herd> empty
virtual/perl-parent                     <herd> empty
virtual/perl-Parse-CPAN-Meta            <herd> empty

app-office/homebank                     <herd> missing
dev-libs/faxpp                          <herd> missing
dev-libs/librelp                        <herd> missing
dev-libs/ossp-uuid                      <herd> missing
dev-util/cucumber                       <herd> missing
dev-util/hg-git                         <herd> missing
games-rpg/sacred-gold                   <herd> missing
gnome-extra/gnome-color-chooser         <herd> missing
media-gfx/engauge                       <herd> missing
media-gfx/greycstoration                <herd> missing
media-plugins/gimp-greycstoration       <herd> missing
net-dialup/dgcmodem                     <herd> missing
net-irc/irssi-xmpp                      <herd> missing
net-libs/udns                           <herd> missing
net-misc/openswan                       <herd> missing
sys-apps/edac-utils                     <herd> missing


Statistics
==================================================================

Total number of packages:                    13623

metadata.xml missing                             0
<herd> missing                                  16
<herd> empty                                    13
<herd> unknown                                   0
<herd>=no-herd                                1999

<maintainer> missing                          8383
<maintainer> retired                             0
<maintainer> is a herd                        1187
<maintainer> unknown                           203
<maintainer>=maintainer-needed                 715

Proxy maintainer without gentoo association        10
Unmaintained packages                          731

You will find the complete log at [1].
The script that generated above logfile can be found at [2].

As usual, feedback is highly appreciated.
Warm regards
Thilo

[1] Full metadata-check.log
http://dev.gentoo.org/~bangert/metadata-check.log
[2] Metadata checking script.
http://overlays.gentoo.org/dev/bangert/browser/scripts/check-metadata.rb

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] irregular metdata.xml check

[Ulrich Mueller]

>>>>> On Mon, 7 Dec 2009, Thilo Bangert wrote:

> Welcome to this years edition of the metadata check.
> [...]

> You will find the complete log at [1].

Hmm, eselect is not known:

| unknown maintainer: eselect@gentoo.org

But it's in good company:

| unknown maintainer: catalyst@gentoo.org
| unknown maintainer: dev-portage@gentoo.org
| unknown maintainer: genkernel@gentoo.org
| unknown maintainer: gnap@gentoo.org
| unknown maintainer: portage-utils@gentoo.org
| unknown maintainer: sandbox@gentoo.org

> As usual, feedback is highly appreciated.

Could you make your script recognise Gentoo hosted projects as valid
maintainers?

Ulrich

Re: [gentoo-dev] irregular metdata.xml check

[Thilo Bangert]

[-- Attachment #1: Type: Text/Plain, Size: 851 bytes --]

Ulrich Mueller <ulm@gentoo.org> said:
> >>>>> On Mon, 7 Dec 2009, Thilo Bangert wrote:
> >
> > Welcome to this years edition of the metadata check.
> > [...]
> >
> > You will find the complete log at [1].
> 
> Hmm, eselect is not known:
> | unknown maintainer: eselect@gentoo.org
> 
> But it's in good company:
> | unknown maintainer: catalyst@gentoo.org
> | unknown maintainer: dev-portage@gentoo.org
> | unknown maintainer: genkernel@gentoo.org
> | unknown maintainer: gnap@gentoo.org
> | unknown maintainer: portage-utils@gentoo.org
> | unknown maintainer: sandbox@gentoo.org
> |
> > As usual, feedback is highly appreciated.
> 
> Could you make your script recognise Gentoo hosted projects as valid
> maintainers?

are these availabe somewhere? AFAICT we dont have them systematically 
available...

> 
> Ulrich
> 


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] irregular metdata.xml check

[Hans de Graaff]

[-- Attachment #1: Type: text/plain, Size: 456 bytes --]

On Mon, 2009-12-07 at 12:56 +0100, Thilo Bangert wrote:
> Welcome to this years edition of the metadata check.

> dev-util/cucumber                       <herd> missing

Fixed, but this is really a bug in metadata.dtd, which specifies 
<!ELEMENT pkgmetadata ( (herd|maintainer|longdescription|use|
upstream)* )>

That should probably be:

<!ELEMENT pkgmetadata ( (herd)+ (maintainer|longdescription|use|
upstream)* )>

Kind regards,

Hans

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] irregular metdata.xml check

[Thilo Bangert]

[-- Attachment #1: Type: Text/Plain, Size: 598 bytes --]

Hans de Graaff <graaff@gentoo.org> said:
> On Mon, 2009-12-07 at 12:56 +0100, Thilo Bangert wrote:
> > Welcome to this years edition of the metadata check.
> >
> > dev-util/cucumber                       <herd> missing
> 
> Fixed, but this is really a bug in metadata.dtd, which specifies
> <!ELEMENT pkgmetadata ( (herd|maintainer|longdescription|use|
> upstream)* )>
> 
> That should probably be:
> 
> <!ELEMENT pkgmetadata ( (herd)+ (maintainer|longdescription|use|
> upstream)* )>
> 

indeed:
http://bugs.gentoo.org/show_bug.cgi?id=279206

> Kind regards,
> 
> Hans
> 


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] metdata.dtd should require <herd/>

[Peter Volkov]

В Пнд, 07/12/2009 в 21:20 +0100, Thilo Bangert пишет:
> Hans de Graaff <graaff@gentoo.org> said:
> > On Mon, 2009-12-07 at 12:56 +0100, Thilo Bangert wrote:
> > > dev-util/cucumber                       <herd> missing
> > 
> > Fixed, but this is really a bug in metadata.dtd, which specifies
> > <!ELEMENT pkgmetadata ( (herd|maintainer|longdescription|use|
> > upstream)* )>

> indeed: http://bugs.gentoo.org/show_bug.cgi?id=279206

So what we will do with this? It'll be great to fix dtd to follow our
requirements, but there is a problem:

if we change dtd like this:

<!ELEMENT pkgmetadata ( herd+, (maintainer|longdescription|use|upstream)* )>

we will force all metadata.xml files have strict order of tags: first
<herd/> then other tags. Currently there are about 200 ebuilds with
different order http://bugs.gentoo.org/show_bug.cgi?id=279206#c4 .

Hans's suggestion http://bugs.gentoo.org/show_bug.cgi?id=279206#c7 works
but it is not nice and prohibits another order: herd, other tags, herd.

Personally I'd kept dtd simple and forced ordering.

So actually two questions here:

1. How should we fix dtd?
2. Are there any problems if we fix dtd first and let maintainers fix
metadata.xml on bumps (iow, what will became broken if metadata.xml
became not valid)?

-- 
Peter.

Re: [gentoo-dev] metdata.dtd should require <herd/>

[Alex Alexander]

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

On Tue, Dec 15, 2009 at 06:19:00PM +0300, Peter Volkov wrote:
> So what we will do with this? It'll be great to fix dtd to follow our
> requirements, but there is a problem:
> 
> if we change dtd like this:
> 
> <!ELEMENT pkgmetadata ( herd+, (maintainer|longdescription|use|upstream)* )>
> 
> we will force all metadata.xml files have strict order of tags: first
> <herd/> then other tags. Currently there are about 200 ebuilds with
> different order http://bugs.gentoo.org/show_bug.cgi?id=279206#c4 .

Forced ordering looks fine to me... we could announce the change, let
devs fix their metadata during a short period of time (say, 2 weeks),
then force-fix the ones left (200 is a small number) and apply the dtd fix.

-- 
Alex Alexander :: wired
Gentoo Developer
www.linuxized.com

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] metdata.dtd should require <herd/>

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 849 bytes --]

On Tuesday 15 December 2009 10:19:00 Peter Volkov wrote:
> we will force all metadata.xml files have strict order of tags: first
> <herd/> then other tags. Currently there are about 200 ebuilds with
> different order http://bugs.gentoo.org/show_bug.cgi?id=279206#c4 .
> 
> Hans's suggestion http://bugs.gentoo.org/show_bug.cgi?id=279206#c7 works
> but it is not nice and prohibits another order: herd, other tags, herd.
> 
> Personally I'd kept dtd simple and forced ordering.

+1 ... i dont see any need/reason to have fields scattered

> So actually two questions here:
> 
> 1. How should we fix dtd?
> 2. Are there any problems if we fix dtd first and let maintainers fix
> metadata.xml on bumps (iow, what will became broken if metadata.xml
> became not valid)?

write a script to fix the tree and then update the dtd
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[gentoo-dev] Re: metdata.dtd should require <herd/>

[Jonathan Callen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Volkov wrote:
> В Пнд, 07/12/2009 в 21:20 +0100, Thilo Bangert пишет:
>> Hans de Graaff <graaff@gentoo.org> said:
>>> On Mon, 2009-12-07 at 12:56 +0100, Thilo Bangert wrote:
>>>> dev-util/cucumber                       <herd> missing
>>> Fixed, but this is really a bug in metadata.dtd, which specifies
>>> <!ELEMENT pkgmetadata ( (herd|maintainer|longdescription|use|
>>> upstream)* )>
> 
>> indeed: http://bugs.gentoo.org/show_bug.cgi?id=279206
> 
> So what we will do with this? It'll be great to fix dtd to follow our
> requirements, but there is a problem:
> 
> if we change dtd like this:
> 
> <!ELEMENT pkgmetadata ( herd+, (maintainer|longdescription|use|upstream)* )>
> 
> we will force all metadata.xml files have strict order of tags: first
> <herd/> then other tags. Currently there are about 200 ebuilds with
> different order http://bugs.gentoo.org/show_bug.cgi?id=279206#c4 .
> 
> Hans's suggestion http://bugs.gentoo.org/show_bug.cgi?id=279206#c7 works
> but it is not nice and prohibits another order: herd, other tags, herd.
> 
> Personally I'd kept dtd simple and forced ordering.
> 
> So actually two questions here:
> 
> 1. How should we fix dtd?
> 2. Are there any problems if we fix dtd first and let maintainers fix
> metadata.xml on bumps (iow, what will became broken if metadata.xml
> became not valid)?
> 

One way to allow for any ordering, would be:

<!ELEMENT pkgmetadata (
   (maintainer|longdescription|use|upstream)*,
   herd,
   (herd|maintainer|longdescription|use|upstream)*
)>

- --
Jonathan Callen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.13 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksnzAcACgkQOypDUo0oQOo3TQCgnvrr5r54RE5q2LVRYoT+Q2nR
6Q4AniRGhT0Tq1KnY1wAoZt7c+ZEfBvQ
=Inet
-----END PGP SIGNATURE-----

Re: [gentoo-dev] metdata.dtd should require <herd/>

[Rémi Cardona]

Le 15/12/2009 16:19, Peter Volkov a écrit :
> we will force all metadata.xml files have strict order of tags: first
> <herd/>  then other tags. Currently there are about 200 ebuilds with
> different order http://bugs.gentoo.org/show_bug.cgi?id=279206#c4 .

Others and I actually make use of the order in metadata.xml. The first 
entry is the one that will get bugs assignment in bugzilla, and the 
others will get CCed.

So if we're really going with herds first in metadata.xml, could we have 
an optional attribute - or whatever else you see fit - to convey that 
_this_ herd/maintainer is the "main" herd/maintainer?

Thanks

Rémi

Re: [gentoo-dev] metdata.dtd should require <herd/>

[Paul de Vrieze]

On Wed, Dec 16, 2009 at 7:49 AM, Rémi Cardona <remi@gentoo.org> wrote:
> Le 15/12/2009 16:19, Peter Volkov a écrit :
>>
>> we will force all metadata.xml files have strict order of tags: first
>> <herd/>  then other tags. Currently there are about 200 ebuilds with
>> different order http://bugs.gentoo.org/show_bug.cgi?id=279206#c4 .
>
> Others and I actually make use of the order in metadata.xml. The first entry
> is the one that will get bugs assignment in bugzilla, and the others will
> get CCed.
>
> So if we're really going with herds first in metadata.xml, could we have an
> optional attribute - or whatever else you see fit - to convey that _this_
> herd/maintainer is the "main" herd/maintainer?
>
> Thanks
>

Perhaps we should create a schema to validate the file. XMLSchema (or
any of the other standards) allows for much more flexibility in
specifying these things. Btw. I did not design the metadata DTD for
order to be significant. The only priority is that maintainer goes
before herd, that's all.

Paul

-- 
Paul de Vrieze

Re: [gentoo-dev] metdata.dtd should require <herd/>

[Richard Freeman]

On 12/23/2009 01:36 PM, Paul de Vrieze wrote:
>
> Perhaps we should create a schema to validate the file. XMLSchema (or
> any of the other standards) allows for much more flexibility in
> specifying these things. Btw. I did not design the metadata DTD for
> order to be significant. The only priority is that maintainer goes
> before herd, that's all.
>

I think we should definitely have some way of designating which should 
be the contact for bugs.  I've had some bugs sit around for a while 
without being noticed because they were assigned to the herd the package 
is in, and not to me personally, and I don't generally work with that 
herd, and the project associated with the herd doesn't generally 
maintain the package.

I'm sure there are many cases where a similar situation exists.

Another way to handle this is at least CC EVERYBODY in the metadata in 
new bugs, and not assume that copying the project will get all the 
maintainers.

Re: [gentoo-dev] metdata.dtd should require <herd/>

[Jeroen Roovers]

On Thu, 24 Dec 2009 07:37:26 -0500
Richard Freeman <rich0@gentoo.org> wrote:

> I think we should definitely have some way of designating which
> should be the contact for bugs.  I've had some bugs sit around for a
> while without being noticed because they were assigned to the herd
> the package is in, and not to me personally, and I don't generally
> work with that herd, and the project associated with the herd doesn't
> generally maintain the package.

That means the bug wasn't properly assigned... I've set up some rules
[1] that might help there. It comes down to this:

1) If one or more <maintainer> tags are listed, assign to the first one
mentioned.
2) If no <maintainer> tag is listed, assign to the first <herd>
mentioned.
3) CC everyone else listed (<maintainer>s and <herd>s).

The rationale is that if one or more <maintainer>s are listed as well as
one or more <herd>s, a bug wrangler shouldn't need to go find out if
that maintainer happens to be on the <herd>'s alias as well (otherwise,
why would it mention those maintainers separately?).

The order in which <maintainer> and <herd> tags are listed isn't
special, because <maintainer> goes before <herd> for the reason set out
above. The order of multiple <maintainer> tags (or multiple <herd> tags)
does matter: the first one you find is the Assignee, the others are
CC'd.


Regards,
     jer


[1] http://www.gentoo.org/proj/en/qa/bug-wranglers/index.xml#doc_chap4