[Kde-scm-interest] Resolution to too many merge request emails

[ComputerDruid]

On Saturday 28 November 2009 22:36:51 Chani wrote:
> On November 28, 2009 07:00:37 ComputerDruid wrote:
> > I just read on the gitorious blog about a solution to the problem we had
> >  about having too many people emailed about merge requests. From the
> >  wording used, it seems that this was done specifically for us (although
> >  perhaps other projects wanted it too).
> >
> > http://blog.gitorious.org/2009/11/26/repository-permissions/
> >
> > I presume this does what we need?
> 
> we don't add users to repositories, we add the kde-developers group.
> I doubt we want to set the option per-group... that would mean *nobody*
>  would get any kde merge requests unless they were also *personally* added
>  to that repository by the administrator of that repository. and any time
>  someone changed their mind about what review requests they wanted, they
>  would have to ask an administrator to go change it for them.

Of course we would add kde-developers group as a committer, but what if we had 
a kde-pim team which got the merge requests for kdepim-related projects. 
Groups as well as users can be added to the lists as well as individual 
people. (I just checked on a project of mine)

It's still a little bit of administrative overhead, but anyone can still SEE 
merge requests, they just wouldn't be emailed about them until they're added 
to the group. Having such groups would probably be useful for other reasons 
anyway, so some process for getting people added would be something to do.

This is pretty similar to the current model, where merge requests/code review 
requests tend to go to the project mailing list.

> so no, this is not a solution. :(

I guess not completely, but I still think it helps.

> what *would* be a solution is allowing users themselves to set such options
> for projects which they are subscribed to, either directly or via a group
> they're in. it shouldn't matter how they got access; if they have access
>  they should be able to decline parts of it (like merge requests) on their
>  own.

Not sure what you mean here by "subscribed" I suppose you mean people who have 
commit access?

Being able to take yourself off the list is useful (although email filters might 
be useful for those that need this immediately)

Something to work on, for sure.

> it's one of the basic foundations of our community really, isn't it? if you
> want to do something you can do it, you don't have to go ask some special
> administrator to give you permission, let alone do it *for* you.

I'm not so sure. There is a process to get an account on svn (kde-developers) 
in git, which grants you access to pretty much everything code-wise. That 
would still be true. This in a way is just signing up for a mailing list, so 
to speak, which may grant the ability to monitor merge requests/etc.

So yeah, this method does have problems, but I do think it will help. We might 
be able to add a dummy account for the mailing lists so that they all got the 
merge requests too. Not sure if this would be a problem for getting duplicate 
mails, but it would be pretty convenient. Basically I think the kde-developers 
group would always have commit access, and the subgroups would have merge 
requests, which is basically how it works with svn atm.

Thanks for taking the time to think about this, Chani. I'm not an official 
spokesperson or anything either, I just like git. But hey, after all, "We are 
kde", right?
-- 
-ComputerDruid
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20091128/d524e3bf/attachment.sig