The bugzilla conversion is almost complete, except for a few minor issues that need to be figured out (such as who will be owning the bugs initiall when they are submitted). And a few minor cosmetics. Head on over to bugzilla.linsec.ca and check it out. Constructive feedback is welcome and encouraged!
Now the only thing left to do is handle components in a sane fashion (and fix a bugzilla bug that doesn’t respect group memberships for QA contact). The below is a posting to cooker regarding how I think ownership and maintainership of packages should be handled. Not everyone will agree with me, but I think it would work out pretty good.
My personal opinion on package maintainership, is that it does not make much sense for us, except possibly for very important packages. For Debian, package maintainership makes sense, because most packagers actually package what they regularly use, and because they have an acceptable source-packages/maintainers ratio. It is usual for Debian maintainers to step down from maintenance when they stop being users of a package. In Mandriva, we have many packages which are just packaged for users, not the packager, convenience, and so the packager may not really know or care a lot.
Yeah. The problem here is that people package stuff they don’t use. Which is ok, to the extent that we package a lot of stuff, and some things one fellow might use more than another, or it’s just being packaged for the sake of users.
Maintainer groups would solve this (to some extent). For instance, since I mostly care about security/server stuff, it would be logical for me to be part of the Networking and Security groups. Do I want to actually maintain anything? No. I don’t have enough time to be the maintainer for something.
However, having said that, would I like to see the bugs posted to those components? Yes. Do I want to see the bugs for KDE? No, I don’t use it.
So I have two issues here… I can’t possibly filter bugs based on what I use/like in the current scenario. My procmail filter would be crazy trying to filter out everything except bugs on php, apache, openssh, xchat, whatever. So I either get everything, or I get nothing.
Since I could potentially fix (or have already fixed) an issue in, say, openssh, I’d like to at least see bugs that get assigned to it. Or perhaps I’m more knowledgeable than the average person. In this way, I can be a part of the Networking maintainer group, see those bugs, and can jump in and fix/re-assign to me the bugs that I know I can fix quickly (or invalidate them if they’re bogus). This doesn’t mean I all of a sudden maintain openssh, but that I’m aware of what is happening to it, by proxy.
This could actually further be extended to the point of not having one big bug mailing list. We could do something like:
1) cooker ml 2) maintainer groups ml (kde_team@, gnome_team@, security_team@, etc.) and people who want to be a part of those groups either subscribe to those lists or otherwise get added (Andreas had thought about using LDAP to create impromptu mailing lists for teams, so that’s a possibility too) 2a) bugs reported to the Networking group have a QA contact of network_team@ instead of cooker@ or bugs@; this makes the team the QA contact instead of a) one big ml or b) an individual who 1) may not care, 2) be too busy, 3) no longer is involved, or 4) is on holidays; essentially bugs get more coverage this way
The drawback here is that these groups/teams would need to be defined and setup. The logical start to the creation of these teams would be to have them correspond with components (KDE, GNOME, X.org, Printing, etc.).
If someone is unsure about how/what to do something in a package, he may well have better luck just looking up and asking the top entries in changelog, or asking cooker@, than asking a maintainer who just packaged something and forgot about it.
Exactly. Or, with maintainer groups/teams, asking the members of the team (i.e. the networking_team@ alias/ml could be consulted rather than a maintainer or cooker in general).
Some people will argue that maybe this will make cooker@ less useful, but I disagree. Discussion can certainly take place on cooker@, and should. But maintainer teams can facilitate the entire packaging process by making more people able to fix/change/update packages even though they aren’t “the maintainer”.
After all, aren’t we all in favour of (and haven’t we been doing, in fact) the removal of per-user ACLs for most packages in the buildsystem? For what reason do we do this? To allow more people to work on packages (except for some “core” packages, of course). Moving to a team-based model facilitates this even further, and doesn’t reduce the usefulness of current cooker@; there are many people on the list who aren’t maintainers and thus discussion should still be done here. But an internal ml/alias for a team facilitates discussion of things pertaining to the team ((re-)assignment of packages, figuring who will claim a bug, etc.) that the average cooker probably doesn’t care about.