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
On Wed, Mar 13, 2019 at 5:25 AM Tim Starling tstarling@wikimedia.org 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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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 wiki@physikerwelt.de wrote:
On Wed, Mar 13, 2019 at 5:25 AM Tim Starling tstarling@wikimedia.org 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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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 wiki@physikerwelt.de wrote:
On Wed, Mar 13, 2019 at 5:25 AM Tim Starling tstarling@wikimedia.org 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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Mar 13, 2019 at 5:33 PM Tim Starling tstarling@wikimedia.org 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).
On 14/3/19 1:00 pm, Gergo Tisza wrote:
On Wed, Mar 13, 2019 at 5:33 PM Tim Starling tstarling@wikimedia.org 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
On Sat, 16 Mar 2019 at 03:01, Tim Starling tstarling@wikimedia.org 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
On 16/03/2019 13:48, Merlijn van Deen (valhallasw) wrote:
On Sat, 16 Mar 2019 at 03:01, Tim Starling tstarling@wikimedia.org 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:
- 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.
- 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
On 2019-03-16 14:48, Merlijn van Deen (valhallasw) wrote:
- 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."
On 16/03/2019 14:35, Bartosz Dziewoński wrote:
On 2019-03-16 14:48, Merlijn van Deen (valhallasw) wrote:
- 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
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 zhorishna@gmail.com wrote:
On 16/03/2019 14:35, Bartosz Dziewoński wrote:
On 2019-03-16 14:48, Merlijn van Deen (valhallasw) wrote:
- 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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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, 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 aklapper@wikimedia.org 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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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 megadev44s.mail@gmail.com 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 aklapper@wikimedia.org
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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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 yuriastrakhan@gmail.com 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 megadev44s.mail@gmail.com 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 aklapper@wikimedia.org
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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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
Hello,
Would https://www.mediawiki.org/wiki/Topic:Uvuzn1y39ik2f7ko still be acceptable?
Creating repos also involve self-merging stuff (.gitreview files mostly; also sometimes importing from GitHub).
Best regards, M.
On 17/3/19 11:25 pm, MA wrote:
Hello,
Would https://www.mediawiki.org/wiki/Topic:Uvuzn1y39ik2f7ko still be acceptable?
Creating repos also involve self-merging stuff (.gitreview files mostly; also sometimes importing from GitHub).
If you're doing it already and nobody cares, it's probably fine. To repeat, the section on self merging is merely descriptive of the current situation. It has plenty of wiggle room to allow things that are happening already.
I also want to emphasize that we're not going to suddenly revoke +2 access of a valued contributor for violating some narrowly interpreted clause in the policy. I can't speak for all situations or all committee members, but if someone complains that you shouldn't be doing a particular variety of self merges, the obvious outcome of that is to ask you to stop doing it.
The policy defines an escalation path for complaints which allows them to be handled with common sense and without needless public humiliation.
-- Tim Starling
Am 16.03.19 um 18:40 schrieb Zppix:
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.
The relevant part of the policy reads:
| If there is a consensus of trusted developers on the Phabricator task, any of | the Gerrit administrators can resolve the request. The task must remain open | for at least a week, to allow interested developers to comment. Additional | time should be allowed if the request is open during travel or holiday | periods.
So, if you are the one trusted developer on the project, and nobody else cares, +2 will generally be given after a week.
The rationale for requiring a request instead of allowing the owners of git repos to gran permissions themselves is two-fold:
1) limiting the impact of compromised volunteer accounts. A compromised account that can give +2 rights is more problematic than a compromised account that has +2 rights. It's much easier for WMF to ensure the security of staff accounts.
2) allowing the developer community to raise objections against individuals they have had bad experiences with in the past. The person asking you for +2 rights may seem nice enough to you, but giving others an opportunity to chime in seems prudent.
Both are potential issues for granting maintainer rights on a toolforge project as well. And perhaps the policy for that should also be revised - perhaps there should be a distinction between "high impact" and "regular" tools. But that is beyond the scope of this policy, and this discussion.
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.
That would be the case if the above requests were not handled in a timely manner. If this should be the case, please complain loudly so we can fix it.
Or do you think one week is an unreasonably long time?
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.
It did go though the RFC process, including an IRC discussion and a last call period. Do you have a suggestion for how and where we could have publicized this more, to gather more feedback?
On 17/3/19 12:48 am, Merlijn van Deen (valhallasw) wrote:
On Sat, 16 Mar 2019 at 03:01, Tim Starling tstarling@wikimedia.org 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:
- 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.
- 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
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
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
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
wikitech-l@lists.wikimedia.org