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

[Chani]

On November 28, 2009 20:06:20 ComputerDruid wrote:
> 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.

perhaps. but I don't need to ask an administrator for permission to join the 
kwin mailing list.

wouldn't it make a lot more sense if *any* gitorious user could sign 
themselves up to follow the merge requests of a project, without needing 
anyone's permission? they're public to view, so gettting notiications should 
be publicly available.

hrrrm. there is an rss feed. I wonder if the rss feed is updated when merge 
requests change or only shows new requests...


> 
> > so no, this is not a solution. :(
> 
> I guess not completely, but I still think it helps.

only in that whoever's the admin of amarok can now turn off the merge request 
mail (pretty please?), and neither amarok developers nor innocent bystanders 
will get those damn merge mails any more. and then I can *finally* turn 
gitorious mail back on and be able to get notification of my qt merge 
request...  well, until some other gitorious project adds kde-developers to 
itself and forgets to turn off merge requests. yay spam!

> 
> > 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?

yeah. I'm in the kde-developers group, so I get instant commit access to any 
random gitorious project that decides to add the kde-developers group - and 
instant spam too unless they uncheck that new "review" checkbox. it's not even 
something the kde-developers group admins can control, from the looks of it; 
it's up to the admin of the *project* who they choose to spam or not spam.

> 
> 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.

useful is an understatement.
don't you remember the days when getting an account on some website often 
meant signing up for lots of unsolicited email? yeah, spam. this is *spam*. 
and it's mixed in with rare *important* emails from gitorious.

it is really not nice of gitorious to burden my email server with the 
responsibility of filtering out their spam when they could easily give me the 
chance to do it at the source.

> 
> > 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.

except signing up for a mailing list is entirely automated. some poor kde 
administrator doesn't have to manually approve everyone who wants to subscribe 
to kde-games or kde-edu or kwin or kde-special-topic-of-the-month. even more 
importantly, not one mailing list anywhere requires a human administrator to 
take someone *off* the list. I can go and unsubscribe from any mailing list at 
any moment, instantly. I can remove myself from the plasma group on 
reviewboard right now if I wish. I can't do that for gitorious merge requests.

> 
> 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.
> 

convenient? *convenient*? no, it would not be convenient.
if I ask someone for a soup spoon, and they give me a fork, I do not go "oh 
well I think this will help". I tell them again that it's a spoon I need.

*sigh*

sorry, you're just the messenger here... I should go talk to johan. but he's 
not online. damn timezones...

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.com
-------------- 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/a752f95b/attachment.sig