Michael Schwendt wrote:
Which is no better or worse than what we deal with now. (ie: the pkggdb doesn't have build or watchbuild acls because koji lacks the former and has its own idea about the latter). If someone wanted to build up a notification sync process similar to what we do for bugzilla, we could make this work. Patches would be cheerfully accepted for this.On Sat, 26 Jul 2008 10:38:11 -0700, Toshio Kuratomi wrote:(A side note: I don't think we can control koji, unfortunately. I think it uses its own idea of pkg owners coupled with who submitted a build to send out notification)Which shows that the new %{name}-owner email addresses are insufficient. In particular, koji would need to learn about package owners elsewhere (the separate list in koji of which pkgs to monitor is not connected to the pkgdb either). Theoretically, koji *could* simply mail to those new -owner addresses in addition to the person who requested a build (so all pkg co-maintainers learn about the build job), but that doesn't take into account multiple projects (such as olpc, epel) unless there will be more email addresses. Like epel-%{name}-owner once epel pkgs will be built in koji.
After we solve the criteria issue, we have to solve the UI issue: making more acls makes the current UI more and more cluttered. I've been thinking that we want to have a single button for most things.This topic is an example of where bottom-up and top-down don't meet eachother. We want to support co-maintainership. We've got several pieces of infrastructure (including web UIs), some of which don't communicate with eachother [yet]. Simple co-maintenance: multiple persons get exactly the same privileges with regard to a package in various places: cvs : commit pkgdb : give privileges (in "admin" role) koji : permission to build pkg bodhi : permission to release builds as updates bz : either be the assignee or in Cc (and be able to modify tickets)
I notice that you only have the active privileges listed here. The passive privileges (being notified of changes in an area) need to be available as well so that upstreams, users, and other people who are not Fedora packagers can be aware of what's going on with packages.
A simple way of communicating (besides irc or private mail) is to commit messages to a README file in pkg cvs. All pkg co-owners receive the commit diff via private mail. It's like a pinboard. It's not a substitute for a mailing-list and not suitable for long discussions. With that design of co-maintenance, however, it takes extra effort to distribute work-load among the co-maintainers. One co-maintainer might want to be the release master (and take care of issueing updates in bodhi). Another one would focus on bug triaging. Even another two can't handle the bz traffic and prefer spending time on actual assignments done by the bug triager. And what about pkg-specific testers? Do they fit into the scheme at all? Or does it need privately maintained email lists to notify them of version upgrades or updates? One can easily see that sending all sorts of notifications to all co-maintainers is suboptimal.
I would love a better designed UI and better designed acls. So please, give me a design to implement instead of merely criticising what's there. Don't take me wrong, I love that you're criticising it because it's horrible. But without a notion of what the better system looks like we're never going to replace what we have.
-Toshio "I posted my strawman of a new UI, now how 'bout you?" Kuratomi
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
