On Thu, 2006-04-27 at 09:22 +0200, Kevin F. Quinn (Gentoo) wrote: > I must admit I've assumed that the herd entry in metadata.xml is a > reasonable fall-back if the maintainer entry is missing or the listed > maintainer is away/not responding. This is implied by > http://www.gentoo.org/proj/en/metastructure/herds/index.xml which > requires <herd> but not <maintainer> - also the description of > <maintainer> says "Besides being a member of a herd, a package can also > be maintained directly" which implies the herd is the default maintainer > if maintainer is not present.
Well, the herd listing shows what herd that it belongs to, not the team that manages that herd. I think that this is the confusion. For example, catalyst has livecd listed as its herd. However, there is not a "livecd" project, nor team. Instead, the "livecd" herd is maintained by myself, solely, except for genkernel and catalyst, that have alternate maintainers. In the case of catalyst, an alias is listed as the maintainer, since there *is* a catalyst team, albeit small. > The herds project description says, "The herds project aims to ensure > that the growing number of ebuilds do not overwelm (sic) the gentoo > project. To this end the herds project aims for the development of > infrastructure that will help manage the collection of ebuilds". This > clearly indicates herds are supposed to have a maintainer role. Where? I can see how you can interpret it like that, but it is anything but clear in stating it. In fact, it mentions nothing about maintaining any packages, but rather to "manage the collection" of them, which leads me to read it as it is there solely for creating a logical grouping of specific packages, much like how categories work in the tree itself. For example, look at openal. It is a package in the "sound" herd, yet the sound *team* does not maintain it. I do. > A quick scan of the tree shows that some 6k+ packages have no > maintainer entry. Well, ~700 of those are games, which belong to the games herd, and have no specific maintainer. The games *team* maintains all packages in the games herd that does not have a specific maintainer listed. It just so happens that in *many* cases, the project (or team) has the same name as the herd to which the package belongs. I think that this has been the cause of the confusion, more than the definitions. > It would be useful to know how many people think herds are not > maintainers - if only a few people think this then I suggest it would > be better to accept the common interpretation of herd as a group of > people who can maintain a package. I definitely do not think that herds are maintainers. At the same time, I understand that many people do think this, so I'm willing to change *my* definition to match what the in practice definition ends up being, if necessary. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
