Last modified: 2014-02-04 00:08:26 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T62412, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 60412 - ldap/wmf group should not have +2 in Gerrit
ldap/wmf group should not have +2 in Gerrit
Status: NEW
Product: Wikimedia
Classification: Unclassified
Git/Gerrit (Other open bugs)
wmf-deployment
All All
: Unprioritized normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-01-25 00:14 UTC by MZMcBride
Modified: 2014-02-04 00:08 UTC (History)
11 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description MZMcBride 2014-01-25 00:14:53 UTC
As I understand it, any Wikimedia Foundation employee can +2 code in Gerrit. This is a flawed design and should be corrected.
Comment 1 Chad H. 2014-01-25 00:16:48 UTC
Gerrit is a flawed design.
Comment 2 Dan Garry 2014-01-25 00:24:16 UTC
(In reply to comment #0)
> As I understand it, any Wikimedia Foundation employee can +2 code in Gerrit.
> This is a flawed design and should be corrected.

Not automatically. I can't +2 code. Not that I actually want the ability to be able to, though.
Comment 3 MZMcBride 2014-01-25 00:30:38 UTC
(In reply to comment #1)
> Gerrit is a flawed design.

Perhaps, but it's the current code review tool. :-)

Further information about the technical details behind the current implementation would be really helpful here. It has something to do with LDAP and user groups or something, I think, maybe.
Comment 4 Chad H. 2014-01-25 00:32:13 UTC
(In reply to comment #0)
> As I understand it, any Wikimedia Foundation employee can +2 code in Gerrit.
> This is a flawed design and should be corrected.

Rephrase this: any full time WMF engineer is entitled to access to the ldap/wmf group (ops has +2 on all repos). Like Dan says: non engineers don't usually get this (and actually this is a nice reminder--I need to remove some former staffers and hadn't gotten around to it)

ldap/wmf is given review permissions over most non-operations stuff. Specifically wikimedia/* mediawiki/* and analytics/*. This is mostly done out of convenience as there's lots of deployed things that an engineer could need access to.

If a given repo has a desire to deny default group permissions from inheriting, they can in their ACL(s).
Comment 5 Chad H. 2014-01-25 00:33:28 UTC
(In reply to comment #4)
> (In reply to comment #0)
> > As I understand it, any Wikimedia Foundation employee can +2 code in Gerrit.
> > This is a flawed design and should be corrected.
> 
> Rephrase this: any full time WMF engineer is entitled to access to the
> ldap/wmf
> group (ops has +2 on all repos).
>

That should say "entitled... on request." It's not automatically granted, and it typically *doesn't* get granted until an engineer finds themselves needing it and ask :)
Comment 6 MZMcBride 2014-01-25 00:37:55 UTC
(In reply to comment #4)

Thanks for the clarification!

> Rephrase this: any full time WMF engineer is entitled to access to the
> ldap/wmf group (ops has +2 on all repos).

Is there a way to see the members of the ldap/wmf group?

As I understand it, this ldap/wmf group includes more than just full-time Wikimedia Foundation engineers. There are contractors in this group. There are non-engineers in this group.

Related: https://gerrit.wikimedia.org/r/#/admin/groups/11,members
Comment 7 MZMcBride 2014-01-25 00:50:54 UTC
(In reply to comment #6)
> Is there a way to see the members of the ldap/wmf group?

https://gerrit.wikimedia.org/wmf-20140124.txt
Comment 8 MZMcBride 2014-01-25 00:54:35 UTC
I tried to clarify the bug summary.

Why are we relying on the ldap/wmf group? Can't we simply be explicit (i.e., <https://gerrit.wikimedia.org/r/#/admin/groups/11,members>)?

This would be much more transparent.
Comment 9 Chad H. 2014-01-25 01:00:22 UTC
(In reply to comment #8)
> I tried to clarify the bug summary.
> 
> Why are we relying on the ldap/wmf group? Can't we simply be explicit (i.e.,
> <https://gerrit.wikimedia.org/r/#/admin/groups/11,members>)?
> 

Because as far as I know, it's also used for access to some other services too (I think the test logstash is an example, as it's still under development and contains private logs). It's modeled after the ldap/ops group, which has existed since labs launched.

It's used in gerrit mostly out of convenience, but I could be convinced otherwise if we can't do this \/

> This would be much more transparent.

I would love to make the ldap groups (and everything about ldap) much much more accessible on wikitech. There's not a whole lot of private data there.
Comment 10 Nemo 2014-01-31 11:48:52 UTC
(In reply to comment #8)
> Can't we simply be explicit (i.e.,
> <https://gerrit.wikimedia.org/r/#/admin/groups/11,members>)?

With or without the current [[+2]] approval process that currently entails? (Both cases would require process changes...)

(In reply to comment #9)
> Because as far as I know, it's also used for access to some other services
> too
> (I think the test logstash is an example, as it's still under development and
> contains private logs). It's modeled after the ldap/ops group, which has
> existed since labs launched.

I don't think there's any need to rethink this LDAP group from scratch. I think most if not all the people in the group who ever used +2 also had such permission via other groups (particularly for "their" extensions). It would be nice to have
1) a list of group members who ever used +2,
2) a list for the subset of (1) which could perform said +2 thanks to wmf group only.
From that we can understand how big a change this would be. We might discover we only need a handful tweaks to some more specific groups' membership.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links