[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 tag in metadata.xml is used to assign a package to a >> certain group. >> 4) the 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: foobar This makes it clear that it is a team instead of a person (where 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 ... 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 ... 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 and a tag in metadata.xml no >> longer exists It doesn't. You can still have more than one 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
[gentoo-dev] Last rites: dev-cpp/libwrapiter
# Mark Loeser <[EMAIL PROTECTED]> (21 May 2008) # Dead upstream and not used by anything # Masked for removal in 30 days dev-cpp/libwrapiter -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com pgpNKrGQ9RCE9.pgp Description: PGP signature
[gentoo-dev] Re: [gentoo-project] About herds and their non-existant use
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 tag in metadata.xml is used to assign a package to a > certain group. > 4) the 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. > > 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) > - it would simplify bug assignment rules, as the current case where a > package has both a and a tag in metadata.xml no > longer exists > - 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 > - as others said in #-dev: it makes sense ;) > > Now there of course are a few things to consider: > - obviously, some tools, docs and processes would have to be updated, > but that's always the case with changes > - someone said that it might no longer be obvious if a package is > maintained by an individual or a group of people. But is that really > necessary? And it's not even obvious now, as some herds are maintained > by a single person. > - when I brought this up several months ago it was mentioned that > sometimes people want to be on the mail alias of a herd, but don't > want to be listed as members (and therefore be responsible). But that > can likely be just implemented by some kind of blacklist in the > relevant tools instead of using this whole indirection layer all the > time. > > So, what do you think? Is there some benefit in keeping this concept, > or can we live without it and make life simpler for everyone? > > Marius > > -- > Public Key at http://www.genone.de/info/gpg-key.pub > > In the beginning, there was nothing. And God said, 'Let there be > Light.' And there was still nothing, but you could see a bit better. -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
[gentoo-dev] Re: PostgreSQL: Bug for collecting changed ebuilds for postgresql packaging change?
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 :-) Cheers, Tiziano -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Goodbye
Alon, Well ignoring the rant that largely ment you'd had enough, I just want to thankyou again. You have been the best of any developer I have seen in terms of responsiveness, gentoo user (customer?) service, upstream collaboratation. In your 1.5 - 2 years of doing gentoo developer work I hope others have picked on your leadership and, at least to themselves, appreciated the countless hours solving problems for Gentoo and upstream packages. Thankyou for the countless hours that you have dedicated to keeping many crypto packages up to date, bug free, and working nicely with others. In the solitude of effectively a one person herd, and i'm largely to blame, you've done exceptionally well. I'm note sure I could of coped as long. I'm hoping at the end of such a dedicated time you have had some fun. Keep well in whatever you do next. -- Daniel Black <[EMAIL PROTECTED]> Gentoo Foundation signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] am I ready to step into Gentoo?
Tue, 20 May 2008 19:20:52 +0200 Federico Ferri <[EMAIL PROTECTED]> kirjoitti: > hi all, Hi, > my computer-related hobbies (or I should say time-killers!) are Tcl > (scripting language) and Pure-Data (multimedia dataflow environment). > I regularly use Pd to create audio/video apps, and Tcl for everything > else that doesn't fit Pd, I've also developed a Tcl-Pd loader, that > allows to code externals for Pd in Tcl. > see my Pd page at [3]. > > perhaps that's the category I should belong to...(?) > I keep occasional contact with Tcl developers, so I could bring some > love to the Tcl/Tk Gentoo herd (yes, I am a Tcl/Tk fan, as you can > see on my wikipage at [4]) > I've also set up an overlay (pd-overlay, [5]) and used to develop > together with ColdWind (actually a Gentoo dev) ebuilds for EVERY pd > external! Bringing PD back sounds like a great idea; last time it had some serious issues with the build system and hardcoded paths which made it rather impossible to install correctly into live filesystem.. > best regards, > Federico Ferri Thanks, Samuli -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] PostgreSQL: Bug for collecting changed ebuilds for postgresql packaging change?
Hi, 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. Thanks... 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.
