[Kde-scm-interest] meeting summary

[Jeff Mitchell]

Marius Mårnes Mathiesen wrote:
> 2009/12/11 Chani <chanika at gmail.com <mailto:chanika at gmail.com>>
> 
>     because svn doesn't email you every project's merge requests (since
>     it doesn't
>     *have* merge requests, but that's besides the point).
>     imagine if suddenly reviewboard started sending all the mail it
>     currently
>     sends to mailing lists and directly-involved people to every person
>     who has an
>     svn account.
> 
> Further, once a merge request is created, reviewers of the repository
> will have this merge request added to their newsfeed. So: no email
> "spamming" of reviewers. 

But reviewers *want* the email. Speaking only for myself, I like getting
relevant merge request emails and don't find RSS nearly as useful, and
considering that many on this thread were arguing that it's now too
difficult to get those merge request emails, I think others want them too.

The situation now, where you can have a group that receives email, is
decent but has a few specific problems:

1) We can use a group to control which people have review access, so
that e.g. +kde-developers can commit to a repository but only
+amarok-developers get email about merge requests. This is good, except
that since the Review permission grants both the merge request emails
*and* the ability to change state of the merges, users (non-developers)
that are interested in tracking development can't be given permission to
receive merge request notifications without also being given the ability
to change the merge request statuses.

We really need these to be separate permissions. In fact, it probably
makes sense to put the permission to change merge request statuses into
the Committers category (since they have permission to modify the code
via pushes, they're the ones that can actually apply the code in the
merge requests), and to have the merge request emails be entirely
standalone.

2) Following on from 1), we need a way for users to both join and leave
groups on their own. Right now a group admin has to subscribe a user --
which could even be against their will -- and to remove them as well --
which means users in groups with unresponsive admins could face a
situation where they can't ever leave a group.

So one basic thing is that users *must* be able to leave groups on their
own. Regardless of how one joins a group-- via their own power (see
below) or an admin -- it should be up to the user to decide when to
leave it, not just the admin.

However, taking it a step further, there should be a settings toggle for
groups that allows any interested parties to join without requiring an
admin to do it. This way users can sign themselves up for the group that
receives merge requests for a repo, without needing to poke an
administrator.

This is less important if users can subscribe themselves onto a
merge-request watchlist for a particular repository -- although I think
that these are actually orthogonal problems and that both would be nice.
For instance, imagine the situation where a particular group is assigned
the ability to get merge requests (but not change merge status!) for
many repositories. This is gold if you want to track all of those
repositories -- just join the one group (without needing to poke an
admin). On the other hand, if you are a user that is just interested in
*one* of the team's repositories, this means you could get lots of
emails you don't want. So I see the ability to assign the
merge-request-email bit to both groups (that users can join themselves)
and individual users to be useful.

I think that summarizes many of the current issues we're up against. The
permissions you guys added are great, but they're not *quite* there yet
for what we really need. And we really do want merge request emails (the
"push" nature of them vs. the "pull" nature of RSS feeds is nicer to
many of our workflows).

Thanks,
Jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20091211/f5dbff8b/attachment.sig