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)
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.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
