On Thu, 2006-04-27 at 19:54 +0200, Kevin F. Quinn (Gentoo) wrote: > > Where? > > Two places. First, in the description of maintainer: > > "Besides being a member of a herd, a package can also be maintained > directly" > > which implies packages can be maintained by being a member of a herd and
No, it doesn't. It *plainly* states that a package is a member of a herd, *or* it can also be maintained by a person. The problem is that there's nothing stating that a herd is maintained by a team or a project. > secondly where it says: > > "[herds] help manage the collection of ebuilds" > > I interpreted "manage" to include "maintain", since I couldn't think > of any other management that needs to be done. We read this differently. I read this as: manage the collection ... of ebuilds You read it as: manage the ... collection of ebuilds I can see where that can be confusing. Perhaps some better wording there would clear it up. > If we're to distinguish between herds and teams, and it seems that we > should, clearly something needs to define which teams maintain which > herds. Most are on the project pages, already. The biggest failure here is that there aren't project pages for all of the projects (or teams) out there maintaining packages. As an example, look at the output from the following piece of GuideXML from the http://www.gentoo.org/proj/en/desktop/games/index.xml page. <herd name="games"/> This gives the following output on the page: 4. Herds The Games project maintains the following herds: Herd Members Description games Mr_Bones_, Tupone, genstef, vapier, wolf31o2 Gentoo Games Team This clearly shows the relationship of a project to a herd, yet *also* helps in confusing the issue by listing the developers responsible for the herd, as *members* of the herd. > I do think that metadata.xml should always indicate who maintains a > package, whether it's a single maintainer or a team of maintainers - > including who is the backup should the primary maintainer be > unavailable for an urgent change. If the herd is nothing to do with who > maintains a package, then the maintainer entry should be mandatory; > there can be multiple entries and it's easy enough to set up team mail > aliases. I also think it should be clear in metadata.xml who the > "backup" maintainers are if such exist - i.e. someone who can process > stuff in the absence of the primary maintainer. I'd tend to agree with you here. The main thing is that in most cases, the project/team maintaining the packages has the exact same name as the herd it maintains, which would make the extra data a bit redundant. After all, do we really need: <herd>games</herd> <maintainer>[EMAIL PROTECTED]</maintainer> The data is fairly redundant, in this case. Perhaps what we need more is a single location that maps the list of projects/teams to packages? > Maybe other people were assuming, like me, that if maintainer is > missing then the herd was the mail alias to write to. I can see from > what you're saying that the herd name is not a mail alias (since it > doesn't refer to people). I would venture a bet that in most, if not all cases in the tree, that you are absolutely correct. The herd name generally corresponds with the team name. I can think of a few exceptions to this rule, such as portage bugs go to dev-portage, rather than portage. There are also examples of project/team email aliases being listed as the maintainer, such as with catalyst or sandbox. > It definitely seems that we need to define somewhere which teams > maintain which herds. The games example is perhaps obvious, but in > general that won't be the case. It's listed on the games project page, as is the case in quite a few other projects, and should be the case in *all* projects/teams. > Perhaps for simplicity (and to save having to edit 6k+ metadata.xml > files), we could rule that if the maintainer entry is missing, and the > herd name is the same as a team name, that team is the maintainer for > the package. That would be fine and tends to match what we are currently using, meaning there's no change in behavior required. The only files that would/should need editing are ones where the herd name does not directly correspond with the project/team alias, such as my given portage example. > > > 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. > > So what are the herds supposed to achieve? It would be useful to see > some examples of what herds are/could be useful for. I'm happy to go > with the intended definition of herd, but it certainly could be clearer > in the documentation. Well, the idea was to group like packages together. For example, we could have a "qmail" herd, that would encompass packages in any and all categories in the tree. That herd could be maintained by a team (or teams). Truthfully, we have some very large herds of fairly diverse packages. For example, we have the "net-mail" herd that is responsible for both postfix and sendmail, which are *very* different packages. They end up not being maintained by the same people, at all. Of course, both of these packages have individual maintainers listed, but it gets the point across. A better solution here would probably be to split up net-mail into smaller herds, and have a single "mail" project/team that is responsible, as a whole, for the multiple mail-related herds. Members within a team can have specific responsibilities within that team, so this isn't an issue. There are few examples of a single team maintaining multiple herds, but it could be done. As an example, we could take all of the games that require people to actually buy something, and create a "games-commercial" herd, which would be maintained by a team of developers that actually owned the games. In practice, this is exactly what happens. It just happens internal to the games team and isn't formalized, though it is listed on our project page. ;] -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
