sumanah at wikimedia
Oct 22, 2012, 5:12 PM
Post #6 of 14
My understanding is that creating new repositories becomes WAY easier
with Gerrit 2.5, which is one of many reasons the upgrade to 2.5 is one
of Chad's priorities. (Also GitBlit support, automatic GitHub repo
creation, etc.) We know creating new repos is pretty sub-optimal right
now and are working to fix that. Let's take implementation details to
the other thread.
However, back to the main thread: it is going to be GREAT for our whole
community that we're expanding maintainership. Congratulations to Brian
Wolff, Derk-Jan Hartman, Brad Jorsch, Victor Vasiliev, and Robin
Pepermans, who now have the ability to +2 code into MediaWiki core;
we're grateful for their expertise in JS/CSS, media handling, the API,
our parser, language engineering, and more. They join Platonides and
Alexandre Emsenhuber as volunteers who can review and merge changes into
the codebase that will then be deployed onto WMF sites and into the
tarball. I think that's pretty cool.
You can apply at
https://www.mediawiki.org/wiki/Git/Gerrit_project_ownership - you just
need one approval and no vetoes from the current maintainers to get in.
If you're not ready yet, we'll tell you what you need to do to get there.
Engineering Community Manager
On 10/22/2012 04:37 PM, Tyler Romeo wrote:
> Agreed on what Daniel said. I'd much prefer to keep my extensions on
> Gerrit, but it becomes slightly frustrating when you have to wait two weeks
> for the repository to be created.
> *Tyler Romeo*
> Stevens Institute of Technology, Class of 2015
> Major in Computer Science
> www.whizkidztech.com | tylerromeo [at] gmail
> On Mon, Oct 22, 2012 at 7:21 PM, Daniel Friesen
> <daniel [at] nadir-seen-fire>wrote:
>> Rather than expanding +2 I'm a little more concerned about allowing more
>> people to create repositories.
>> Currently it can take a half week waiting for a new repo just so you can
>> contribute a new extension, and there's typically no notification.
>> We need to make getting multiple new extensions into version control
>> somewhat close to how easy it was for a committer to do it back in svn.
>> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
>> On Mon, 22 Oct 2012 16:01:03 -0700, Erik Moeller <erik [at] wikimedia>
>> Hi folks,
>>> To help accelerate code review, we (WMF) have recently made efforts to
>>> expand the +2 merge right on Git/Gerrit, consistent with the idea that
>>> +2 is an expression of trust and confidence in someone's judgment
>>> rather than an indicator of universal technical competence.
>>> For example, you might have +2 on core, but specialize in front-end
>>> code, or documentation fixes, or test changes. That means you would be
>>> expected to only merge changes relevant to those areas, and we trust
>>> you to exercise good judgment to do so.
>>> Our intent is therefore to grant +2 more broadly than we have in the
>>> past, but to also establish clear parameters under which we would
>>> revoke it.
>>> So we've:
>>> - expanded +2 to all full-time WMF engineers by adding them to a 'wmf'
>>> group which has +2 rights on the following repos: apps, glam,
>>> integration, mediawiki, qa, search, translatewiki, webplatform.org
>>> - been more open in handing out +2 to MediaWiki core. Sumana has been
>>> actively nominating trusted volunteers to ensure that they get merge
>>> rights. Five volunteers have gained maintainership rights in the past
>>> week, and we're encouraging you to apply:
>>> - posted a draft policy for owners of the +2 permission here:
>>> This last bit is the critical part -- as we expand +2, these are the
>>> terms under which reviewers would be expected to operate. Please leave
>>> comments on the talk page if anything strikes you as onerous or
>>> unreasonable, or missing.
>>> Hopefully this will reduce friction introduced with the Git/Gerrit
>>> permissions model and review-related blockers.
>>> All best,
>> Wikitech-l mailing list
>> Wikitech-l [at] lists
> Wikitech-l mailing list
> Wikitech-l [at] lists
Wikitech-l mailing list
Wikitech-l [at] lists