Hi
I was wondering what the policy is for the right to merge into core, i.e. for being able to give +2 and "publish and submit" on gerrit. There sooms to be total confusion about the policy for that.
To me this seems more or less equivalent to commit access to svn, no?
Anyway. I pretty much need it for the core/Wikidata branch, and wouldn't mind to have it for core/master, too.
-- daniel
On Fri, Jun 15, 2012 at 7:52 AM, Daniel Kinzler daniel@brightbyte.de wrote:
Hi
I was wondering what the policy is for the right to merge into core, i.e. for being able to give +2 and "publish and submit" on gerrit. There sooms to be total confusion about the policy for that.
To me this seems more or less equivalent to commit access to svn, no?
Anyway. I pretty much need it for the core/Wikidata branch, and wouldn't mind to have it for core/master, too.
The equivalence of having commit access to /trunk/phase3, at least. Right now the process is to ask on-wiki[0]. People have a chance to give a quick yay/nay, and it's given out. I can't see any reason to say nay :)
-Chad
[0] https://www.mediawiki.org/wiki/Git/Gerrit_project_ownership
On 15.06.2012 14:41, Chad wrote:
The equivalence of having commit access to /trunk/phase3, at least.
Yea... so I would have thought that anyone who had that level of access would have gotten merge rights automatically. Oh, well.
Right now the process is to ask on-wiki[0]. People have a chance to give a quick yay/nay, and it's given out. I can't see any reason to say nay :)
Will do!
-- daniel
On 06/15/2012 08:41 AM, Chad wrote:
On Fri, Jun 15, 2012 at 7:52 AM, Daniel Kinzler daniel@brightbyte.de wrote:
Hi
I was wondering what the policy is for the right to merge into core, i.e. for being able to give +2 and "publish and submit" on gerrit. There sooms to be total confusion about the policy for that.
To me this seems more or less equivalent to commit access to svn, no?
Anyway. I pretty much need it for the core/Wikidata branch, and wouldn't mind to have it for core/master, too.
The equivalence of having commit access to /trunk/phase3, at least. Right now the process is to ask on-wiki[0]. People have a chance to give a quick yay/nay, and it's given out. I can't see any reason to say nay :)
-Chad
[0] https://www.mediawiki.org/wiki/Git/Gerrit_project_ownership
The "who gets merge privileges" policy is in this mailing list post from March: http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/59681 and I encourage anyone to {{sofixit}} and paste it into a relevant place onwiki.
If you merge into mediawiki/core.git, your change is considered safe for inclusion in a wmf branch. The wmf branch is just branched out of master and then deployed. We don't review it again. Because we're deploying more frequently to WMF sites, the code review for merging into MediaWiki's core.git needs to be more like deployment/shell-level review, and so we gave merge access to people who already had deployment access. We have since added some more people. The current list: https://gerrit.wikimedia.org/r/#/admin/groups/11,members
This is why we didn't just give merge rights to anyone who had core commit access in Subversion. More explanation at http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/59681 .
I talked to Daniel in IRC and it turns out a lot of people are confused about this;
Daniel replied:
Yea... so I would have thought that anyone who had that level of access would have gotten merge rights automatically. Oh, well.
We did give merge rights automatically to the people who already had the desired level of access. But that level was deployment, not SVN commit.
Daniel brought up some more thoughts on IRC:
If i want to be able to commit to extension X. i first have to file a
request on the "developer access" page, and then another request for "project membership"? on a page that is named "project ownership"?
Just have *one* page for all requests. gerrit account, group
membership, project ownership, gerrit repo... one request queue, at least for all things that need feedback/voting
Maybe it would help to have a page that briefly describes the
different roles, and which responsibilities and abilities they entail in terms of git and gerrit, how to request the respective permissions, and which policies govern the granting of these.
I can't follow up on these today because I'm swamped with other work, but anyone else who wants to follow up, please do!
On Fri, Jun 15, 2012 at 8:48 AM, Sumana Harihareswara sumanah@wikimedia.org wrote:
If i want to be able to commit to extension X. i first have to file a
request on the "developer access" page, and then another request for "project membership"? on a page that is named "project ownership"?
Membership != ownership. If you have a Gerrit account, you can submit commits for review to any repository in the system, including your favorite extension. What you seem to want is not to be able to *commit* to extension X, but to *review* and *merge* proposed commits. Obviously that's a higher level of trust and responsibility (because there is no second level of review like there used to be, this *is* the is-this-safe-for-deployment review), so it's not given out to just anyone.
The ability to approve and merge is called ownership. There is no such thing as extension membership, only global membership (by having a Gerrit account) you're either an owner with special access to a certain repo, or just another contributor with the same level of access as anyone else.
Just have *one* page for all requests. gerrit account, group
membership, project ownership, gerrit repo... one request queue, at least for all things that need feedback/voting
Maybe it would help to have a page that briefly describes the
different roles, and which responsibilities and abilities they entail in terms of git and gerrit, how to request the respective permissions, and which policies govern the granting of these.
Yes, documentation would be useful. It's simpler than you seem to think, but since it's not really documented anywhere it can seem complex.
Roan
On 15/06/12 17:48, Sumana Harihareswara wrote:
Just have *one* page for all requests. gerrit account, group membership, project ownership, gerrit repo... one request queue, at least for all things that need feedback/voting
They have different needs. - project ownership is watched by many people for +1/-1 the requester. - gerrit accounts are watched by people handing gerrit accounts. - New repositories are acted on just by Chad ('repo creators' now)
I don't think anyone is on the three groups. So, the separation itself seems right. The issue would be improving navigation.
What about adding a "Requests index" plus a template at the bottom of these pages for navigating them?
wikitech-l@lists.wikimedia.org