[gentoo-dev] Re: About herds and their non-existant use
Marius Mauch wrote: Moving the discussion to -dev per leios request. On Wed, 21 May 2008 23:42:19 +0200 Marius Mauch [EMAIL PROTECTED] wrote: As this topic jus came up in #-dev, and most people there seemed to agree with me I thought it might be worth to bring this topic up again. The topic is that I think that the whole 'herd' concept we're using is a huge mess and should be removed. Now before eveyone starts screaming, lets look at what this concept actually is, as many people are quite confused by it: 1) a herd is a group of packages (not a group of people) 2) the herds.xml file is used to assign people and mail aliases as maintainers of a given herd. Unfortuntely the syntax there give the impression that those people/mail aliases actually form the herd 3) the herd tag in metadata.xml is used to assign a package to a certain group. 4) the maintainer tag in metadata.xml can be used to assign individual maintainers for a package in addition to/instead of the herd maintainers 5) the combination of 2), 3) and 4) is used to determine the maintainers of a given package Now most people will be familiar with 5) to some degree, and that is actually the only valid use case for the herd concept that I'm aware of. Or has anyone some use case where you'd like to know what herd a package belongs to, but don't care about by whom that herd is maintained? If we can agree that this is the only real use case for the herd concept, then I think the concept is quite useless as it's just a redundant layer of indirection. You could just list mail aliases directly as maintainers, without having to consult herds.xml first. While I think the herds concecpt is somewhat useless, I'd rather like to see something like this instead: maintainer teamfoobar/team /maintainer This makes it clear that it is a team instead of a person (where name would have been used) And the herds.xml isn't completely useless, but I'd rather name it teams.xml and list the teams there. This way we can validated the team mentioned in team.../team against the list of available teams and make sure the complete thing is valid (can be done in the current metadata.dtd or in a future metadata.xsd). (If we're gonna re-use the email.../email element for the herd-alias, we can never validate it. And I'm personally for the: if something can be automatically validated, it should be) This would have a number of benefits: - you no longer have to look at herds.xml to determine the actual maintainers of a given package (as herd-name and associated mail alias don't always match) I don't consider this much of a problem. You just have to know xsl/xpath to cope with this as generating the list of mail-aliases to assign this bug to is a simple xsl-transformation... When we use XML we can also use the right tools to handle them, can't we? - it would simplify bug assignment rules, as the current case where a package has both a herd and a maintainer tag in metadata.xml no longer exists It doesn't. You can still have more than one maintainer in there. We'd have to introduce an attribute to mark the primary maintainer. - eliminate confusion about what a herd actually is ++ - only have one location where members of a given team are listed, currently it's possible and quite likely that herds.xml and the mail alias files get out of sync Well, we need one location where the name of the team is mapped to the actual mail-alias. But I don't get what you're trying to say... Cheers, Tiziano -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: About herds and their non-existant use
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tiziano Müller wrote: | Marius Mauch wrote: | | Moving the discussion to -dev per leios request. | | On Wed, 21 May 2008 23:42:19 +0200 | Marius Mauch [EMAIL PROTECTED] wrote: | | As this topic jus came up in #-dev, and most people there seemed to | agree with me I thought it might be worth to bring this topic up | again. The topic is that I think that the whole 'herd' concept we're | using is a huge mess and should be removed. Now before eveyone starts | screaming, lets look at what this concept actually is, as many people | are quite confused by it: | | 1) a herd is a group of packages (not a group of people) | 2) the herds.xml file is used to assign people and mail aliases as | maintainers of a given herd. Unfortuntely the syntax there give | the impression that those people/mail aliases actually form the herd | 3) the herd tag in metadata.xml is used to assign a package to a | certain group. | 4) the maintainer tag in metadata.xml can be used to assign | individual maintainers for a package in addition to/instead of the | herd maintainers | 5) the combination of 2), 3) and 4) is used to determine the | maintainers of a given package | | Now most people will be familiar with 5) to some degree, and that is | actually the only valid use case for the herd concept that I'm aware | of. Or has anyone some use case where you'd like to know what herd a | package belongs to, but don't care about by whom that herd is | maintained? | If we can agree that this is the only real use case for the herd | concept, then I think the concept is quite useless as it's just a | redundant layer of indirection. You could just list mail aliases | directly as maintainers, without having to consult herds.xml first. | While I think the herds concecpt is somewhat useless, I'd rather like to see | something like this instead: | | maintainer | teamfoobar/team | /maintainer | | This makes it clear that it is a team instead of a person (where name | would have been used) | | And the herds.xml isn't completely useless, but I'd rather name it teams.xml | and list the teams there. This way we can validated the team mentioned in | team.../team against the list of available teams and make sure the | complete thing is valid (can be done in the current metadata.dtd or in a | future metadata.xsd). | (If we're gonna re-use the email.../email element for the herd-alias, we | can never validate it. And I'm personally for the: if something can be | automatically validated, it should be) | I am also for renaming or making clear that these are 'teams' instead f 'herds'[0]. Unless a team can maintain several herds, I find the term 'herd' confusing and better understood as 'team' instead. My 2 cents. [0]http://www.gentoo.org/proj/en/metastructure/herds/herds.xml - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkg1HX4ACgkQNir3WYj9aLp6xQCghXkp7wZS4XMjx/xKtinOMzRk xpkAoI9TqpYukYUQZ8FD3HmiyLSFs8W+ =xAMS -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: About herds and their non-existant use
Luis Francisco Araujo [EMAIL PROTECTED] writes: Unless a team can maintain several herds, I find the term 'herd' confusing and better understood as 'team' instead. +1 on this. I always thought that if almost every dev misuses the term herd, it was because the term had to be changed, rather than the devs corrected... -- Diego Flameeyes Pettenò http://blog.flameeyes.eu/ pgpFE7rWRh6si.pgp Description: PGP signature
Re: [gentoo-dev] Re: About herds and their non-existant use
On Thu, May 22, 2008 at 2:34 PM, Diego 'Flameeyes' Pettenò
[EMAIL PROTECTED] wrote:
Luis Francisco Araujo [EMAIL PROTECTED] writes:
Unless a team can maintain several herds, I find the term 'herd'
confusing and better understood as 'team' instead.
+1 on this. I always thought that if almost every dev misuses the term
herd, it was because the term had to be changed, rather than the devs
corrected...
Till very recently, I too misunderstood the meaning of the term. I
think one problem is that the term really hasn't been defined anywhere
(at least I couldn't find a proper definition on [1]).
I really do like the herds terminology because it is unique and has
become a Gentoo-ism of sorts. It also is reminiscent of Larry, in some
sense (herds - grazing - moo - cow - larry). :)
[1] http://www.gentoo.org/proj/en/metastructure/herds/
Just my ${currency} 0.02,
--
Arun Raghavan
(http://nemesis.accosted.net)
v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056
e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com
--
gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] removal of old selinux masking from profiles
I still see that masking of SELinux packages that I made back in 2006 have propagated out to current profiles: arch/mips/package.mask arch/sparc/package.mask default/linux/package.mask default-linux/alpha/no-nptl/package.mask default-linux/mips/package.mask default-linux/sparc/sparc64/package.mask default-linux/x86/no-nptl/package.mask features/no-nptl/package.mask The masking is only required if the profile does not have a working/stable glibc = 2.4. Would the relevant herds please remove the masking from the profiles (assuming there is an appropriate glibc)? If there isn't an appropriate glibc, I'd ask that you make a comment in the file so you remember to remove the mask in the future :) Thanks -- Chris PeBenito [EMAIL PROTECTED] Developer, Hardened Gentoo Linux Public Key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE6AF9243 Key fingerprint = B0E6 877A 883F A57A 8E6A CB00 BC8E E42D E6AF 9243 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: PostgreSQL: Bug for collecting changed ebuilds for postgresql packaging change?
Am Mittwoch, 21. Mai 2008 schrieb ext Tiziano Müller: Hi Dirk Dirk Heinrichs wrote: is there a bug to which one could attach ebuilds which require dependency changes to adapt to the new postgresql packaging scheme? I already have some in my local overlay which I would like to share. Please resync, all done besides the php eclasses :-) Yeah, seen it meanwhile. Great work! Bye... Dirk -- Dirk Heinrichs | Tel: +49 (0)162 234 3408 Configuration Manager | Fax: +49 (0)211 47068 111 Capgemini Deutschland | Mail: [EMAIL PROTECTED] Wanheimerstraße 68 | Web: http://www.capgemini.com D-40468 Düsseldorf | ICQ#: 110037733 GPG Public Key C2E467BB | Keyserver: wwwkeys.pgp.net signature.asc Description: This is a digitally signed message part.
