Slight change in how cvs notifications work

[Toshio Kuratomi]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080730/8bb25f30/attachment.sig>