New Gerrit privilege policy

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

New Gerrit privilege policy

Tim Starling-2
Following approval by TechCom and WMF Interim CTO Erika Bjune, I've
moved the new Gerrit privilege policy page out of my userspace to

https://www.mediawiki.org/wiki/Gerrit/Privilege_policy

This is a merge of two pages: [[Gerrit/+2]] and [[Gerrit/Project
ownership]], with some additional changes. I've now redirected both of
those pages to the new policy page.

The main changes are:

* The wmde LDAP group, representing WMDE staff members, will be given
+2 access to mediawiki/* projects, similar to the rights given to WMF
staff members.

* The ability of ShoutWiki and Hallo Welt! to manage access to the
extensions they maintain is described and formalised.

* The ownership model for extensions is discouraged in favour of
individual requests on Phabricator. An extension owner was able to
promote developers to +2 access at their own discretion.

* The Phabricator projects for requesting access have changed. I'm in
the process of moving the tickets over.

* The revocation policy has been expanded, better describing the
present situation and making several minor changes.

-- Tim Starling


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New Gerrit privilege policy

Physikerwelt
On Wed, Mar 13, 2019 at 5:25 AM Tim Starling <[hidden email]> wrote:

>
> Following approval by TechCom and WMF Interim CTO Erika Bjune, I've
> moved the new Gerrit privilege policy page out of my userspace to
>
> https://www.mediawiki.org/wiki/Gerrit/Privilege_policy
>
> This is a merge of two pages: [[Gerrit/+2]] and [[Gerrit/Project
> ownership]], with some additional changes. I've now redirected both of
> those pages to the new policy page.
>
> The main changes are:
>
> * The wmde LDAP group, representing WMDE staff members, will be given
> +2 access to mediawiki/* projects, similar to the rights given to WMF
> staff members.

Great. This is the first step towards a global movement;-)

>
> * The ability of ShoutWiki and Hallo Welt! to manage access to the
> extensions they maintain is described and formalised.
>
> * The ownership model for extensions is discouraged in favour of
> individual requests on Phabricator. An extension owner was able to
> promote developers to +2 access at their own discretion.

I think this does not harm too much since many people use Microsofts
GitHub to maintain their non-WMF deployed extensions these days.


Physikerwelt

>
> * The Phabricator projects for requesting access have changed. I'm in
> the process of moving the tickets over.
>
> * The revocation policy has been expanded, better describing the
> present situation and making several minor changes.
>
> -- Tim Starling
>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New Gerrit privilege policy

zppix e
Hello,
So what is the process for adding people to +2 on gerrit repos im the primary maintainer of (for example my ZppixBot toolforge gerrit repo)

--
Devin “Zppix” CCENT
Volunteer Wikimedia Developer
Africa Wikimedia Developers Member and Mentor
Volunteer Mozilla Support Team Member (SUMO)
Quora.com Partner Program Member
enwp.org/User:Zppix
**Note: I do not work for Wikimedia Foundation, or any of its chapters. I also do not work for Mozilla, or any of its projects. **

> On Mar 13, 2019, at 12:40 AM, Physikerwelt <[hidden email]> wrote:
>
>> On Wed, Mar 13, 2019 at 5:25 AM Tim Starling <[hidden email]> wrote:
>>
>> Following approval by TechCom and WMF Interim CTO Erika Bjune, I've
>> moved the new Gerrit privilege policy page out of my userspace to
>>
>> https://www.mediawiki.org/wiki/Gerrit/Privilege_policy
>>
>> This is a merge of two pages: [[Gerrit/+2]] and [[Gerrit/Project
>> ownership]], with some additional changes. I've now redirected both of
>> those pages to the new policy page.
>>
>> The main changes are:
>>
>> * The wmde LDAP group, representing WMDE staff members, will be given
>> +2 access to mediawiki/* projects, similar to the rights given to WMF
>> staff members.
>
> Great. This is the first step towards a global movement;-)
>
>>
>> * The ability of ShoutWiki and Hallo Welt! to manage access to the
>> extensions they maintain is described and formalised.
>>
>> * The ownership model for extensions is discouraged in favour of
>> individual requests on Phabricator. An extension owner was able to
>> promote developers to +2 access at their own discretion.
>
> I think this does not harm too much since many people use Microsofts
> GitHub to maintain their non-WMF deployed extensions these days.
>
>
> Physikerwelt
>
>>
>> * The Phabricator projects for requesting access have changed. I'm in
>> the process of moving the tickets over.
>>
>> * The revocation policy has been expanded, better describing the
>> present situation and making several minor changes.
>>
>> -- Tim Starling
>>
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> [hidden email]
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New Gerrit privilege policy

Tim Starling-2
File a task in Phabricator under the Gerrit-Privilege-Requests
project, recommending that the person be given access, giving your
reasons and mentioning that you are the maintainer of the project in
question. Wait for at least a week for comments. Then a Gerrit
administrator should add the person and close the task.

-- Tim Starling

On 13/3/19 11:18 pm, Zppix wrote:

> Hello,
> So what is the process for adding people to +2 on gerrit repos im the primary maintainer of (for example my ZppixBot toolforge gerrit repo)
>
> --
> Devin “Zppix” CCENT
> Volunteer Wikimedia Developer
> Africa Wikimedia Developers Member and Mentor
> Volunteer Mozilla Support Team Member (SUMO)
> Quora.com Partner Program Member
> enwp.org/User:Zppix
> **Note: I do not work for Wikimedia Foundation, or any of its chapters. I also do not work for Mozilla, or any of its projects. **
>
>> On Mar 13, 2019, at 12:40 AM, Physikerwelt <[hidden email]> wrote:
>>
>>> On Wed, Mar 13, 2019 at 5:25 AM Tim Starling <[hidden email]> wrote:
>>>
>>> Following approval by TechCom and WMF Interim CTO Erika Bjune, I've
>>> moved the new Gerrit privilege policy page out of my userspace to
>>>
>>> https://www.mediawiki.org/wiki/Gerrit/Privilege_policy
>>>
>>> This is a merge of two pages: [[Gerrit/+2]] and [[Gerrit/Project
>>> ownership]], with some additional changes. I've now redirected both of
>>> those pages to the new policy page.
>>>
>>> The main changes are:
>>>
>>> * The wmde LDAP group, representing WMDE staff members, will be given
>>> +2 access to mediawiki/* projects, similar to the rights given to WMF
>>> staff members.
>>
>> Great. This is the first step towards a global movement;-)
>>
>>>
>>> * The ability of ShoutWiki and Hallo Welt! to manage access to the
>>> extensions they maintain is described and formalised.
>>>
>>> * The ownership model for extensions is discouraged in favour of
>>> individual requests on Phabricator. An extension owner was able to
>>> promote developers to +2 access at their own discretion.
>>
>> I think this does not harm too much since many people use Microsofts
>> GitHub to maintain their non-WMF deployed extensions these days.
>>
>>
>> Physikerwelt
>>
>>>
>>> * The Phabricator projects for requesting access have changed. I'm in
>>> the process of moving the tickets over.
>>>
>>> * The revocation policy has been expanded, better describing the
>>> present situation and making several minor changes.
>>>
>>> -- Tim Starling
>>>
>>>
>>> _______________________________________________
>>> Wikitech-l mailing list
>>> [hidden email]
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> [hidden email]
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New Gerrit privilege policy

Gergo Tisza
On Wed, Mar 13, 2019 at 5:33 PM Tim Starling <[hidden email]>
wrote:

> File a task in Phabricator under the Gerrit-Privilege-Requests
> project, recommending that the person be given access, giving your
> reasons and mentioning that you are the maintainer of the project in
> question. Wait for at least a week for comments. Then a Gerrit
> administrator should add the person and close the task.
>

Does the policy apply to Toolforge tools at all? The current text says "For
extensions (and other projects) not deployed to the Wikimedia cluster, the
code review policy is up to the maintainer or author of the extension." I'd
assume that by extension managing +2 permissions is also up to them
(although this is not explicitly stated, might be worth clarifying).
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New Gerrit privilege policy

Andre Klapper-2
In reply to this post by Tim Starling-2
On Wed, 2019-03-13 at 15:24 +1100, Tim Starling wrote:
> * The Phabricator projects for requesting access have changed. I'm in
> the process of moving the tickets over.

What is supposed to happen with
https://phabricator.wikimedia.org/tag/repository-ownership-requests/ ?

Do you plan to archive that project as it's superseded by
https://phabricator.wikimedia.org/tag/mediawiki-gerrit-group-requests/
and https://phabricator.wikimedia.org/tag/gerrit-privilege-requests/ ?

andre
--
Andre Klapper | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New Gerrit privilege policy

Tim Starling-2
On 16/3/19 7:53 am, Andre Klapper wrote:

> On Wed, 2019-03-13 at 15:24 +1100, Tim Starling wrote:
>> * The Phabricator projects for requesting access have changed. I'm in
>> the process of moving the tickets over.
>
> What is supposed to happen with
> https://phabricator.wikimedia.org/tag/repository-ownership-requests/ ?
>
> Do you plan to archive that project as it's superseded by
> https://phabricator.wikimedia.org/tag/mediawiki-gerrit-group-requests/
> and https://phabricator.wikimedia.org/tag/gerrit-privilege-requests/ ?

I archived it.

-- Tim Starling



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New Gerrit privilege policy

Tim Starling-2
In reply to this post by Gergo Tisza
On 14/3/19 1:00 pm, Gergo Tisza wrote:

> On Wed, Mar 13, 2019 at 5:33 PM Tim Starling <[hidden email]>
> wrote:
>
>> File a task in Phabricator under the Gerrit-Privilege-Requests
>> project, recommending that the person be given access, giving your
>> reasons and mentioning that you are the maintainer of the project in
>> question. Wait for at least a week for comments. Then a Gerrit
>> administrator should add the person and close the task.
>>
>
> Does the policy apply to Toolforge tools at all? The current text says "For
> extensions (and other projects) not deployed to the Wikimedia cluster, the
> code review policy is up to the maintainer or author of the extension." I'd
> assume that by extension managing +2 permissions is also up to them
> (although this is not explicitly stated, might be worth clarifying).

No, managing +2 permissions is not up to the maintainer of the tool,
that's the whole point of the change.

-- Tim Starling

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New Gerrit privilege policy

Andre Klapper-2
In reply to this post by Tim Starling-2
On Sat, 2019-03-16 at 12:59 +1100, Tim Starling wrote:
> On 16/3/19 7:53 am, Andre Klapper wrote:
> > What is supposed to happen with
> > https://phabricator.wikimedia.org/tag/repository-ownership-requests/ ?
>
> I archived it.

Thanks! I've updated its Phab project description to explain where to
go instead now, in case there are lingering links out there.

andre
--
Andre Klapper | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New Gerrit privilege policy

Merlijn van Deen
In reply to this post by Tim Starling-2
On Sat, 16 Mar 2019 at 03:01, Tim Starling <[hidden email]> wrote:

> No, managing +2 permissions is not up to the maintainer of the tool,
> that's the whole point of the change.
>

I feel that this policy, although well-meaning, and a step forwards for
MediaWiki and other WMF-production software, is unreasonably being applied
as a 'one-size-fits-all' solution to situations where it doesn't make sense.

Two examples where the policy does not fit the Toolforge situation:

1. According to the policy, self-+2'ing is grounds for revocation of Gerrit
privileges. For a Toolforge tool, self +2-ing is common and expected: the
repository is hosted on Gerrit to allow for CI and to make contributions
from others easier, not necessarily for the code review features.

2. Giving someone +2 access to a repository now needs to pass through an
extended process with checks and balances. At the same time, I can *directly
and immediately give someone deployment access to the tool.*

Effectively, this policy forces me to move any tool repositories off Gerrit
and onto GitHub: time and effort better spent otherwise.

Merlijn
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New Gerrit privilege policy

Isarra Yos
On 16/03/2019 13:48, Merlijn van Deen (valhallasw) wrote:

> On Sat, 16 Mar 2019 at 03:01, Tim Starling <[hidden email]> wrote:
>
>> No, managing +2 permissions is not up to the maintainer of the tool,
>> that's the whole point of the change.
>>
> I feel that this policy, although well-meaning, and a step forwards for
> MediaWiki and other WMF-production software, is unreasonably being applied
> as a 'one-size-fits-all' solution to situations where it doesn't make sense.
>
> Two examples where the policy does not fit the Toolforge situation:
>
> 1. According to the policy, self-+2'ing is grounds for revocation of Gerrit
> privileges. For a Toolforge tool, self +2-ing is common and expected: the
> repository is hosted on Gerrit to allow for CI and to make contributions
> from others easier, not necessarily for the code review features.
>
> 2. Giving someone +2 access to a repository now needs to pass through an
> extended process with checks and balances. At the same time, I can *directly
> and immediately give someone deployment access to the tool.*
>
> Effectively, this policy forces me to move any tool repositories off Gerrit
> and onto GitHub: time and effort better spent otherwise.

Similar issues for smaller skins and extensions. Even in those cases
where it doesn't merit a move, we'll probably just wind up self-merging
even more than we already do, and putting even more of the burden of any
actual review on the folks with +2 higher up, because that's just easier.

-I


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New Gerrit privilege policy

Bartosz Dziewoński
In reply to this post by Merlijn van Deen
On 2019-03-16 14:48, Merlijn van Deen (valhallasw) wrote:
> 1. According to the policy, self-+2'ing is grounds for revocation of Gerrit
> privileges. For a Toolforge tool, self +2-ing is common and expected: the
> repository is hosted on Gerrit to allow for CI and to make contributions
> from others easier, not necessarily for the code review features.

The policy calls out this case as acceptable:

"For extensions (and other projects) not deployed to the Wikimedia
cluster, the code review policy is up to the maintainer or author of the
extension. Some non-Wikimedia extensions follow Wikimedia's policy of
prohibiting self-merges, but there is no requirement of that. If you are
the only person writing the extension and have nobody to review your
change, or if the extension is abandoned, it is acceptable to self-merge
your changes."

--
Bartosz Dziewoński

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New Gerrit privilege policy

Isarra Yos
On 16/03/2019 14:35, Bartosz Dziewoński wrote:

> On 2019-03-16 14:48, Merlijn van Deen (valhallasw) wrote:
>> 1. According to the policy, self-+2'ing is grounds for revocation of
>> Gerrit
>> privileges. For a Toolforge tool, self +2-ing is common and expected:
>> the
>> repository is hosted on Gerrit to allow for CI and to make contributions
>> from others easier, not necessarily for the code review features.
>
> The policy calls out this case as acceptable:
>
> "For extensions (and other projects) not deployed to the Wikimedia
> cluster, the code review policy is up to the maintainer or author of
> the extension. Some non-Wikimedia extensions follow Wikimedia's policy
> of prohibiting self-merges, but there is no requirement of that. If
> you are the only person writing the extension and have nobody to
> review your change, or if the extension is abandoned, it is acceptable
> to self-merge your changes."
>
The problem is now it's a lot more difficult to start scaling beyond
that. Perhaps we simply need an exception for this, too, in these cases?

-I


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New Gerrit privilege policy

zppix e
So your basically telling me, I can’t decide who gets the power to +2 on for example a toolforge tool I actively am the primary maintainer of? Instead it has to be requested. I do not disagree with a lot of the changes to technical policies, but with this change it seems to restrict ability to scale projects. I also do believe that this change should of be taken under RfC or some sort of consensus-gaining measure.  I respect the intentions, but I absolutely think the change needs reverted then voted on by the technical community.

--
Devin “Zppix” CCENT
Volunteer Wikimedia Developer
Africa Wikimedia Developers Member and Mentor
Volunteer Mozilla Support Team Member (SUMO)
Quora.com Partner Program Member
enwp.org/User:Zppix
**Note: I do not work for Wikimedia Foundation, or any of its chapters. I also do not work for Mozilla, or any of its projects. **

> On Mar 16, 2019, at 9:57 AM, Isarra Yos <[hidden email]> wrote:
>
>> On 16/03/2019 14:35, Bartosz Dziewoński wrote:
>>> On 2019-03-16 14:48, Merlijn van Deen (valhallasw) wrote:
>>> 1. According to the policy, self-+2'ing is grounds for revocation of Gerrit
>>> privileges. For a Toolforge tool, self +2-ing is common and expected: the
>>> repository is hosted on Gerrit to allow for CI and to make contributions
>>> from others easier, not necessarily for the code review features.
>>
>> The policy calls out this case as acceptable:
>>
>> "For extensions (and other projects) not deployed to the Wikimedia cluster, the code review policy is up to the maintainer or author of the extension. Some non-Wikimedia extensions follow Wikimedia's policy of prohibiting self-merges, but there is no requirement of that. If you are the only person writing the extension and have nobody to review your change, or if the extension is abandoned, it is acceptable to self-merge your changes."
>>
> The problem is now it's a lot more difficult to start scaling beyond that. Perhaps we simply need an exception for this, too, in these cases?
>
> -I
>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New Gerrit privilege policy

Andre Klapper-2
On Sat, 2019-03-16 at 12:40 -0500, Zppix wrote:
> So your basically telling me, I can’t decide who gets the power to +2
> on for example a toolforge tool I actively am the primary maintainer
> of? Instead it has to be requested. I do not disagree with a lot of
> the changes to technical policies, but with this change it seems to
> restrict ability to scale projects. I also do believe that this
> change should of be taken under RfC or some sort of consensus-gaining
> measure.  I respect the intentions, but I absolutely think the change
> needs reverted then voted on by the technical community.

Did you read https://www.mediawiki.org/wiki/Gerrit/Privilege_policy ?

It says "For extensions (and other projects) not deployed to the
Wikimedia cluster, the code review policy is up to the maintainer or
author of the extension."

andre
--
Andre Klapper | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New Gerrit privilege policy

zppix e
Andre, from what im gathering from this thread thats not what I understand, so i redact the part of my last email about toolforge, however my point on this policy change should of been put to a community vote/consensus is valid.

--
Devin “Zppix” CCENT
Volunteer Wikimedia Developer
Africa Wikimedia Developers Member and Mentor
Volunteer Mozilla Support Team Member (SUMO)
Quora.com Partner Program Member
enwp.org/User:Zppix
**Note: I do not work for Wikimedia Foundation, or any of its chapters. I also do not work for Mozilla, or any of its projects. **

> On Mar 16, 2019, at 1:13 PM, Andre Klapper <[hidden email]> wrote:
>
>> On Sat, 2019-03-16 at 12:40 -0500, Zppix wrote:
>> So your basically telling me, I can’t decide who gets the power to +2
>> on for example a toolforge tool I actively am the primary maintainer
>> of? Instead it has to be requested. I do not disagree with a lot of
>> the changes to technical policies, but with this change it seems to
>> restrict ability to scale projects. I also do believe that this
>> change should of be taken under RfC or some sort of consensus-gaining
>> measure.  I respect the intentions, but I absolutely think the change
>> needs reverted then voted on by the technical community.
>
> Did you read https://www.mediawiki.org/wiki/Gerrit/Privilege_policy ?
>
> It says "For extensions (and other projects) not deployed to the
> Wikimedia cluster, the code review policy is up to the maintainer or
> author of the extension."
>
> andre
> --
> Andre Klapper | Bugwrangler / Developer Advocate
> https://blogs.gnome.org/aklapper/
>
>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New Gerrit privilege policy

Yuri Astrakhan
I agree that while possibly made with good intentions, policy changes like
these should go through dev community discussion + vote, not be handed down
from a CTO.  Wikipedia as a movement started that way, and many people
participated in it because of its transparency and community-driven
process. Just because now there is a large split between "community" and
"WMF staff who gets +2 automatically", we should try to keep the original
values.

On Sat, Mar 16, 2019 at 3:33 PM Zppix <[hidden email]> wrote:

> Andre, from what im gathering from this thread thats not what I
> understand, so i redact the part of my last email about toolforge, however
> my point on this policy change should of been put to a community
> vote/consensus is valid.
>
> --
> Devin “Zppix” CCENT
> Volunteer Wikimedia Developer
> Africa Wikimedia Developers Member and Mentor
> Volunteer Mozilla Support Team Member (SUMO)
> Quora.com Partner Program Member
> enwp.org/User:Zppix
> **Note: I do not work for Wikimedia Foundation, or any of its chapters. I
> also do not work for Mozilla, or any of its projects. **
>
> > On Mar 16, 2019, at 1:13 PM, Andre Klapper <[hidden email]>
> wrote:
> >
> >> On Sat, 2019-03-16 at 12:40 -0500, Zppix wrote:
> >> So your basically telling me, I can’t decide who gets the power to +2
> >> on for example a toolforge tool I actively am the primary maintainer
> >> of? Instead it has to be requested. I do not disagree with a lot of
> >> the changes to technical policies, but with this change it seems to
> >> restrict ability to scale projects. I also do believe that this
> >> change should of be taken under RfC or some sort of consensus-gaining
> >> measure.  I respect the intentions, but I absolutely think the change
> >> needs reverted then voted on by the technical community.
> >
> > Did you read https://www.mediawiki.org/wiki/Gerrit/Privilege_policy ?
> >
> > It says "For extensions (and other projects) not deployed to the
> > Wikimedia cluster, the code review policy is up to the maintainer or
> > author of the extension."
> >
> > andre
> > --
> > Andre Klapper | Bugwrangler / Developer Advocate
> > https://blogs.gnome.org/aklapper/
> >
> >
> >
> > _______________________________________________
> > Wikitech-l mailing list
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New Gerrit privilege policy

Amir Sarabadani-2
I just want to point out that this wasn't "handed down by a CTO", it was a
RFC [1] that and was open for discussion to everyone and was discussed
extensively (and the RFC changed because of these discussions, look at the
history of the page), then had an IRC meeting that was also open to
everyone, then had a "last call" period for raising any objections which
was open to everyone too. That passed with no objection being raised and
then it also got approved by the CTO.

I might be wrong, but if I understand the structure of TechCom correctly
(correct me if I'm wrong), it's open and transparent, the CTO can veto
changes (which hasn't happened so far), but it's not like a CTO would just
implement a new policy without discussion. This process is more open and
transparent than most companies and non-profits.

[1]: https://phabricator.wikimedia.org/T216295
Best

On Sat, Mar 16, 2019 at 9:22 PM Yuri Astrakhan <[hidden email]>
wrote:

> I agree that while possibly made with good intentions, policy changes like
> these should go through dev community discussion + vote, not be handed down
> from a CTO.  Wikipedia as a movement started that way, and many people
> participated in it because of its transparency and community-driven
> process. Just because now there is a large split between "community" and
> "WMF staff who gets +2 automatically", we should try to keep the original
> values.
>
> On Sat, Mar 16, 2019 at 3:33 PM Zppix <[hidden email]> wrote:
>
> > Andre, from what im gathering from this thread thats not what I
> > understand, so i redact the part of my last email about toolforge,
> however
> > my point on this policy change should of been put to a community
> > vote/consensus is valid.
> >
> > --
> > Devin “Zppix” CCENT
> > Volunteer Wikimedia Developer
> > Africa Wikimedia Developers Member and Mentor
> > Volunteer Mozilla Support Team Member (SUMO)
> > Quora.com Partner Program Member
> > enwp.org/User:Zppix
> > **Note: I do not work for Wikimedia Foundation, or any of its chapters. I
> > also do not work for Mozilla, or any of its projects. **
> >
> > > On Mar 16, 2019, at 1:13 PM, Andre Klapper <[hidden email]>
> > wrote:
> > >
> > >> On Sat, 2019-03-16 at 12:40 -0500, Zppix wrote:
> > >> So your basically telling me, I can’t decide who gets the power to +2
> > >> on for example a toolforge tool I actively am the primary maintainer
> > >> of? Instead it has to be requested. I do not disagree with a lot of
> > >> the changes to technical policies, but with this change it seems to
> > >> restrict ability to scale projects. I also do believe that this
> > >> change should of be taken under RfC or some sort of consensus-gaining
> > >> measure.  I respect the intentions, but I absolutely think the change
> > >> needs reverted then voted on by the technical community.
> > >
> > > Did you read https://www.mediawiki.org/wiki/Gerrit/Privilege_policy ?
> > >
> > > It says "For extensions (and other projects) not deployed to the
> > > Wikimedia cluster, the code review policy is up to the maintainer or
> > > author of the extension."
> > >
> > > andre
> > > --
> > > Andre Klapper | Bugwrangler / Developer Advocate
> > > https://blogs.gnome.org/aklapper/
> > >
> > >
> > >
> > > _______________________________________________
> > > Wikitech-l mailing list
> > > [hidden email]
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > _______________________________________________
> > Wikitech-l mailing list
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



--
Amir
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New Gerrit privilege policy

Tim Starling-2
In reply to this post by Merlijn van Deen
On 17/3/19 12:48 am, Merlijn van Deen (valhallasw) wrote:

> On Sat, 16 Mar 2019 at 03:01, Tim Starling <[hidden email]> wrote:
>
>> No, managing +2 permissions is not up to the maintainer of the tool,
>> that's the whole point of the change.
>>
>
> I feel that this policy, although well-meaning, and a step forwards for
> MediaWiki and other WMF-production software, is unreasonably being applied
> as a 'one-size-fits-all' solution to situations where it doesn't make sense.
>
> Two examples where the policy does not fit the Toolforge situation:
>
> 1. According to the policy, self-+2'ing is grounds for revocation of Gerrit
> privileges. For a Toolforge tool, self +2-ing is common and expected: the
> repository is hosted on Gerrit to allow for CI and to make contributions
> from others easier, not necessarily for the code review features.

Merging your own code without review is grounds for revocation, with
several exceptions. One of the exceptions is for code that's not
deployed to the Wikimedia cluster. A toolforge tool would fall under
that exception.

In general, if self-merging is normal policy in some repository, we
are not trying to change that here. The +2 policy section is mostly
copied from the previous policy and is meant to be descriptive of the
current situation.

> 2. Giving someone +2 access to a repository now needs to pass through an
> extended process with checks and balances. At the same time, I can *directly
> and immediately give someone deployment access to the tool.*
>
> Effectively, this policy forces me to move any tool repositories off Gerrit
> and onto GitHub: time and effort better spent otherwise.

The reason we wanted to make this change is because we didn't want to
repeat GitHub's mistakes. This case of a malware being added to an NPM
package used by many people was fresh in our minds:

https://github.com/dominictarr/event-stream/issues/115

The original maintainer had stopped caring about this package some
time before the incident. He gave contributor access to the first
person who asked, without any sort of check. Even after the malware
was discovered, the original maintainer was dismissive, leaving it for
others to clean up.

We've had an incident on Gerrit of a known malicious user, a Wikipedia
vandal, submitting code with a security vulnerability, using a
previously unknown pseudonym. We don't really want such a person to be
summarily given +2 access to a repository.

I don't think it's a huge inconvenience to list your proposed
contributors on a Phabricator ticket and then to wait a week.

-- Tim Starling

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: New Gerrit privilege policy

Tim Starling-2
In reply to this post by Amir Sarabadani-2
On 17/3/19 7:43 am, Amir Sarabadani wrote:

> I just want to point out that this wasn't "handed down by a CTO", it was a
> RFC [1] that and was open for discussion to everyone and was discussed
> extensively (and the RFC changed because of these discussions, look at the
> history of the page), then had an IRC meeting that was also open to
> everyone, then had a "last call" period for raising any objections which
> was open to everyone too. That passed with no objection being raised and
> then it also got approved by the CTO.
>
> I might be wrong, but if I understand the structure of TechCom correctly
> (correct me if I'm wrong), it's open and transparent, the CTO can veto
> changes (which hasn't happened so far), but it's not like a CTO would just
> implement a new policy without discussion. This process is more open and
> transparent than most companies and non-profits.

Yes, that's correct. Daniel raised in TechCom the fact that the Gerrit
privilege policy needed a review. I volunteered to lead the project.
We didn't think it was strictly within the purview of TechCom to make
a binding decision on this, which is why we structured it as a
TechCom-facilitated discussion leading to a recommendation presented
for CTO approval.

-- Tim Starling



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
12