[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Slight change in how cvs notifications work



Michael Schwendt wrote:
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.

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.

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]