Commit access requests/Archive 1

May 2009

edit

Well, I sent my request to Wikitech-l just before this page was created, so I'll add my request here as well to be sure.

  • Commit name: robin (my wikiname is SPQRobin but uppercase appears to be not allowed)
  • I want to use it to commit and maintain my extension (see Extension:WikimediaIncubator) to be used on Wikimedia Incubator. Maybe I'll do some general work/maintenance as well, or fix bugs, when I see something I can fix.
  • My key: http://toolserver.org/~robin/publickey.txt
  • I have already worked on SpecialInterwiki extension but I didn't work on it further since I didn't have commit access.. I also used to work a bit on i18n through Translatewiki.net (for example, reporting unused messages, ...) although that's not so important for this :). Also, some patches I submitted, are [1] and [2].

Thank you, SPQRobin 20:20, 17 April 2009 (UTC)[reply]

Done. --brion 18:59, 1 May 2009 (UTC)[reply]

I send my request to brion in April 18,2008/5/20 and 2008/3/23 and no response.Now I post my request in here.

  • Commit name: alexsh (same as my global account name)
  • I want to commit pywikipediabot and help to maintenance zhConversion.I alse works on i18n updates through translatewiki.net.
  • my public Key: http://alexsh.tw.googlepages.com/alexsh-key.pub

Thank you.--Alexsh 22:00, 21 April 2009 (UTC)[reply]

Done. --brion 18:59, 1 May 2009 (UTC)[reply]
  • requested commit name: gerardm
  • Expected area to work in: testing
  • pubkey
  • Gerard keeps generating patches for me to commit. Please save me! :-)
  • Siebrand and I will be keeping an eye on him. I just worry that he might turn into another Siebrand.
  • --Kim Bruning 22:07, 6 June 2009 (UTC)[reply]
  • (Done... )

July 28, 2009

edit
  • Requested commit name: algorithmix
  • Expected area to work in: extensions
  • I am the primary maintainer of Extension:DynamicPageList. At the moment I publish new releases on my own website.
    Somebody was so kind to upload the latest version of DPL to the MW svn. Now I want commit access there to make the MW svn repository the master place for further publications of DPL.
  • link to my Public Key
  • link to DynamicPageList at MediaWiki svn
  • I think that my extension could be very useful on wikipedia installations. I understand that some people might be afraid of DPL being critical in terms of performance. What can I do to prove that you can get the benefits of DPL without risk? Algorithmix 07:45, 21 May 2009 (UTC)[reply]
  • Requested commit name: beckr
  • Expected area to work in: SlippyMap
  • link to public key
  • Past work on MediaWiki - I'm developing the new OSM SlippyMap with Aude & Avar. Our code has now made it into the Wikimedia trunk; my contributions here include externalizing the JavaScript code and making it object-oriented, adding support for image placeholders (i.e. click to get a dynamic map), and lots of refactoring (see our previous external repository).

Beckr 11:21, 7 July 2009 (UTC)[reply]

  • Requested commit name: churchofemacs
  • Expected area to work in: Bug fixes and new features; implementing the ideas I get on Wikipedia.
  • public key on Wikipedia (alternative)
  • I've filed quite some bugs (as church.of.emacs.ml with my gmail account), and commited patches to about eight bug reports [3] (both trivial and non-trivial ones). My first extension: Extension:FlagArticle

Thanks, --Church of emacs 15:23, 30 April 2009 (UTC)[reply]

  • Requested commit name: conrad
  • Expected area to work in: extensions, particularly for Wiktionaries
  • id_rsa.pub
  • Past work on MediaWiki - MetaKeywords extension, Transliterator extension, Extension:CategoryLabel, plenty of javascript. I have a small wiki-farm which runs on a slightly tweaked codebase (mainly to make the category and search pages look nice, and a couple of unpublished extensions).

Conrad.Irwin 23:04, 25 July 2009 (UTC)[reply]

  • Requested commit name: flominator
  • Expected area to work in: WikiBlame (Siebrand told me that this svn might be a better place than this one)
  • pubkey
  • Past work on MediaWiki - some minor extensions, see User:Flominator

Flominator 07:58, 11 June 2009 (UTC)[reply]

GreenReaper 02:09, 28 July 2009 (UTC)[reply]

Firefishy 04:07, 9 July 2009 (UTC)[reply]

  • Requested commit name: happy-melon
  • Expected area to work in: I generally do little tweaks, usually page layout and display of system messages. I'm having a play at a couple of extensions too: another special page to add to Oversight to allow old oversighted edits to be converted over to the new RevDelete format; and a total reboot of the DeleteQueue extension to make it a) work, and b) be suitable for consideration for use on enwiki.
  • link to public key
  • Patches, bugs. I even managed to get a broken patch far enough through code review to bork the live wikis :D. But I now have a test wiki all to myself to destroy test patches on, so that shouldn't be a problem now... honest... Happymelon 17:36, 22 April 2009 (UTC)[reply]
  • Requested commit name: husky
  • Expected area to work in: Wikiportrait
  • Public key
  • See meta:Wikiportrait for more information. Commiting this to SVN would make development and localisation easier, many chapters want the software to set up their own local versions.

Husky 12:50, 5 June 2009 (UTC)[reply]

Jeroen De Dauw 13:27, 22 July 2009 (UTC)[reply]

Your requested username doesn't meet required policy (1) and you need to publish a public key before it will be considered. Peachey88 08:29, 25 July 2009 (UTC)[reply]
Added my key --Jeroen De Dauw 19:47, 28 July 2009 (UTC)[reply]
  • Requested commit name: malvineous
  • Expected area to work in: extensions
  • link to public key
  • Past work on MediaWiki - I have received some requests to put my extensions (Extension:FlvHandler and Extension:MassEditRegex) into SVN. I would like to request commit access so that I can keep them up to date myself.

Malvineous 22:38, 8 July 2009 (UTC)[reply]

  • Requested commit name: questpc
  • Expected area to work in: extensions
  • link to public key
  • Patch (Dmitriy is me), Extension:QPoll I just want to upload my own extension so it can be updated and localized.

QuestPC 06:22, 4 June 2009 (UTC)[reply]

Strainu 18:11, 14 July 2009 (UTC)[reply]

August 4, 2009

edit
Commit names should be all lowercase and can't contain spaces. Try something like "jaime" or "jprilusky" or whatnot. —Simetrical (talk • contribs) 13:56, 19 May 2009 (UTC)[reply]

OverlordQ 15:36, 15 June 2009 (UTC)[reply]

  • Requested commit name: nephele
  • Expected area to work in: mediawiki patches, new extensions, improvements to existing extensions. (First expected commit is a significant upgrade to Extension:ProtectSection)
  • link to public key
  • Past work on MediaWiki - patches for 18751 and 8130 have been committed; patches for 2257 and 18609 need review. I've written several MediaWiki extensions (and modified several others) that are currently being used on UESP, the most significant of which is MetaTemplate.

Nephele 21:41, 26 June 2009 (UTC)[reply]


Emufarmers(T|C) 20:35, 4 August 2009 (UTC)[reply]

September 8, 2009

edit

yar1

edit

yaron.shapira@kaltura.com 11:45, 12 August 2009 (UTC)

October 5, 2009

edit

--Xqt 13:09, 7 September 2009 (UTC)[reply]

Vouched by Siebrand. --brion 18:20, 5 October 2009 (UTC)[reply]

  • Requested commit name: kipcool
  • Expected area to work in: OmegaWiki (so, maybe a bit of Wikidata as well)
  • link to public key
  • Past work on OmegaWiki - These patches are from me: [4], [5], [6].
  • Of course I am working with GerardM and make him and other OW developers try my patches on my public test server before commiting them.

Kipmaster 07:45, 1 September 2009 (UTC)[reply]

Vouched by GerardM & Siebrand. --brion 18:20, 5 October 2009 (UTC)[reply]

October 15-17, 2009

edit
  • Requested commit name: fenzik
  • Expected area to work in: core & extensions
  • this is my public ssh key
  • Past work on MediaWiki - co-ordinating and developing mediawiki integration with jasperforge.org, forge.openbravo.com & monitoringforge.org
  • Interests : Wish to participate as a hardcore developer in mediawiki community.

--Fenzik 15:02, 6 September 2009 (UTC)[reply]

  • Requested commit name: maxsem
  • Expected area to work in: SQLite support. Due to its present state, I strongly doubt that I'll break anything beyond what is already broken :D I have some ideas how to fix many of these problems, but submitting a huge patch and seeing it bitrotting, waiting for review isn't particulary encouraging.
  • public key
  • Past work on MediaWiki - my patches committed by others: 1, 2, 3, 4, 5, 6, 7.

Max Semenik 17:38, 8 September 2009 (UTC)[reply]

  • Requested commit name: juliano
  • Expected area to work in: mainly extensions
  • My public SSH keys
  • Past work on MediaWiki:

--Juliano 20:23, 3 September 2009 (UTC)[reply]

November 2009

edit
Is the code up somewhere to take a peek at first? --brion 21:19, 4 August 2009 (UTC)[reply]

--Thanks. InforMedic 17:13, 01 June 2009 (UTC)[reply]

You need to publish an SSH public key. Happymelon 15:19, 1 June 2009 (UTC)[reply]
  • Your request has been denied at this time. If you still wish to have commit access, please submit another request, with an SSH public key. Also, please enable user-to-user email in your mediawiki.org preferences. -- Tim Starling 23:47, 4 November 2009 (UTC)[reply]

Bile 02:51, 22 July 2009 (UTC)[reply]

This seems to do about the same as the PdfHandler extension; can you take a look and see if there are some different features in each that you might be able to merge into PdfHandler? --brion 21:10, 4 August 2009 (UTC)[reply]

Matěj Grabovský 16:59, 12 August 2009 (UTC)[reply]

Michael Daly2 20:51, 28 August 2009 (UTC)[reply]

Since your request may not be handled by the 1st of setpember, May I suggest putting a copy of your key in your user space (eg: User:Michael Daly2/SSH2PublicKey) and getting that page protected. Peachey88 04:03, 29 August 2009 (UTC)[reply]
  • Requested commit name: erich
  • Expected area to work in: extensions
  • link to public key
  • Past work on MediaWiki: Extension:News2 and some other useful extensions I'd like to share

Erich 11:51, 20 September 2009 (UTC) (signature with date)[reply]

MacMed 19:59, 1 October 2009 (UTC)[reply]

Marco 27 14:15, 25 October 2009 (UTC)[reply]


Note, User:Catrope suggested to apply for commit access with his support. Thanks, Reedy 14:36, 6 November 2009 (UTC)[reply]

  • Requested commit name: abigor
  • Expected area to work in: wikiportrait
  • link to public key
  • After irc conversation with husky

Abigor 21:33, 11 November 2009 (UTC) (signature with date)[reply]

Happyday19c 09:56, 13 November 2009 (UTC)[reply]

January 2010

edit

Bawolff 21:59, 17 December 2009 (UTC)[reply]

JonathanWilliford 05:10, 25 December 2009 (UTC)[reply]

Platonides 00:03, 29 December 2009 (UTC)[reply]

Conrad.Irwin (cirwin on IRC)

edit
  • Requested commit name: conrad
  • Expect to work in core, already have commit access in extensions.
  • Public key.
  • Maintain a small wiki farm with MediaWiki as a CMS, a few extensions for them, [1], and for en.wiktionary [2], [3]. A few patches, e.g. 1, 2, some committed, e.g. 3 4
  • Past programming experience, mainly involved with web stuff, 1, 2, 3, currently in year 3 of a computer science degree.
If you've already got commit access, you don't necessarily need to re-ask for core rights here. Probably can just poke Tim to tweak the authz file. ^demon 11:45, 29 December 2009 (UTC)[reply]
I don't think he has, though...? Happymelon 13:36, 29 December 2009 (UTC)[reply]
He does unless this conrad is someone else and Conrad here is confused about already having access. :) ^demon 01:09, 30 December 2009 (UTC)[reply]
That would be quite confused, I admit! Nothing wrong with having a marker here, though. Happymelon 09:58, 30 December 2009 (UTC)[reply]

11:29, 30 December 2009 (GMT+08:00)

What experience do you have working with the core? Happymelon 09:57, 30 December 2009 (UTC)[reply]
I've implemented a js framework solution, helping on solving js conflict in different extensions, e.g. jquery / prototype / yui / extjs. Ning 13:24, 13 January 2010 (GMT+08:00)

February 2010

edit
  • Requested commit name: tor
  • Expected area to work in: extensions, localization
  • link to public key
  • Past work on MediaWiki - 2.5 years at Wikia, bugfixes, stand-alone extensions (e.g. Extension:EditSimilar), i18n

TOR 12:49, 1 February 2010 (UTC)[reply]

Gabriel Wicke

edit
  • Requested commit name: gwicke
  • Expected area to work in: extensions, core. First concrete need is publishing updates to my catfeed extension and open-sourcing client work.
  • Link to public key: http://dl.wikidev.net/id_dsa.pub
  • Past work on MediaWiki: Long ago (2003/04): Wrote the MonoBook skin, added user styles, Squid caching infrastructure, Parser fixes, user interface work. Since then: miscellaneous client work
  • Past programming experience: Basic pocket calculators, Zope/Plone, PHP content management systems, Squid, libevent/libev network programming, misc C and Python tools, AVR assembler, Haskell dabbling GWicke 09:25, 13 January 2010 (UTC)[reply]
Your previous commit name appears to be gabrielwicke. Max Semenik 09:47, 13 January 2010 (UTC)[reply]
Yep, but that was back in the CVS days, I did not request an SVN account after the switch. If you would prefer me to use the old name feel free to set that up instead. Thanks! GWicke 17:53, 14 January 2010 (UTC)[reply]

Nathanael Thompson

edit
  • Requested commit name: than4213
  • Expected area to work in: parser. I'm interested in improving the architecture of the parser by iteratively seperating it into a data layer and parser engine. For all who's interested, I have a svn diff available for an initial change.
  • Link to public key: http://sites.google.com/site/natesprograms/Home/id_rsa.pub
  • Past work on MediaWiki: None, I'll work on bugs while I'm waiting for access.
  • Past programming experience: Bachelors in Computer Science and 5 years experience as a feature dev at Microsoft. Used the following in either a academic or professional setting: C++, Java, C#, Scheme, Scala, SQL, Batch, Bash, Perl, Javascript, Matlab, Latex. As mentioned above I made a diff for an initial change to the parser and was able to pick up PHP pretty quickly. Than4213 00:20, 15 January 2010 (UTC)[reply]
Please register on this wiki and enable email features in your preferences. Max Semenik 06:32, 15 January 2010 (UTC)[reply]
Do we have an auth group for "branch only"? Or is that supplied by the 'extension' auth? Definitely support giving him some way to work on a new parser in a branch; such a thing would need hundreds of hours of testing before it gets into core anyway. And there are plenty of extension bugs to work on in the meantime. Happymelon 12:46, 15 January 2010 (UTC)[reply]
We have parser tests for a reason. If it can pass all of those, we can do the same as when Tim deployed the preprocessor and check common pages automatically, document any practical changes, etc. However, Than4213, you should be aware that the parser is one of the most complicated and CPU-intensive parts of the code, and it has very stringent compatibility requirements. To ever get accepted, your code would likely have to 1) noticeably change the output only a small fraction of a percent of the millions of pages on Wikimedia wikis (which can be pathologically baroque), and 2) either improve performance significantly or provide some other concrete benefit to Wikimedia. —Simetrical (talk • contribs) 14:42, 15 January 2010 (UTC)[reply]
I registered on this wiki and enabled email. I'm perfectly fine working in a branch and subjecting my changes to extensive parser tests. I do not plan on changing the functionality of the parser. I just want to improve the architecture of the parser so that future changes to the parser won't be as complicated and error prone. I'll work on changes to the functionality of the parser after fixing up the architecture of the parser :). I also realize that a good overhall of the parser's architecture would take at least hundreds of hours and I'm willing to do so. I think my change will benefit Wikimedia by making changes to the parser a much less daunting task. --Than4213 17:21, 15 January 2010 (UTC)[reply]
It would be interesting having a link to your patch. Platonides 17:26, 15 January 2010 (UTC)[reply]
Sure thing. You can find it at http://sites.google.com/site/natesprograms/Home/WMParser1.txt. --Than4213 18:34, 15 January 2010 (UTC)[reply]
I meant that it will take hundreds of hours, at least, to get any new parser to pass the tests. But if someone is genuinely prepared to take a crack at it, they have my full support. If he can write a parser that behaves the same as the existing one, has exactly the same performance characteristics as the exising one, but doesn't fill everyone apart from Tim with supernatural dread, that would definitely qualify as a concrete benefit to MediaWiki/Wikimedia in my book. Have you seen the work at Markup spec/BNF? That's the closest we've ever come to actually describing the parser's grammar. Happymelon 23:32, 15 January 2010 (UTC)[reply]
Thanks for the link, it should be helpful. The solution I'm thinking of will use something like bnf but will also use regular expressions for pattern matching. I think this will make it so that some of the more dysfunctional syntax can still be represented. --Than4213 17:05, 16 January 2010 (UTC)[reply]
Wow, the WikiText syntax is even stranger than I thought. I finally made a replacement for preprocessToXml that uses a simpler parser with a seperate engine and data layer. The new parser passes all 545 tests that the old parser passed. Also, I ran the old and new parser through the profiler and it looks like they take about the same amount of time (Although I should say that the times I was getting fluctuated quite a bit for each). You can see my proposed change at http://sites.google.com/site/natesprograms/Home/WMParser2.txt. When will I know if I can check this in? Should I check this into main or a branch? My next step is to integrate preprocessToObj into the new parser, but I'd like to check this in first. --Than4213 23:11, 27 January 2010 (UTC)[reply]
Once this request is processed, you should check it into a branch so we can all have a proper look at it with syntax highlighting and all. Looks interesting, though. Give me a poke if it hasn't been done by the end of the week and I'll check it in for you. Happymelon 08:42, 28 January 2010 (UTC)[reply]
OK, will do. Thanks. I updated the comments a little bit in the change, here is the new diff: http://sites.google.com/site/natesprograms/Home/MWParser2.txt --Than4213 14:14, 28 January 2010 (UTC)[reply]
It looks like my commit access request has still not been processed. Could you check my change into a branch and let me know which branch. I would greatly appreciate it. --Than4213 20:12, 1 February 2010 (UTC)[reply]
I'll try and do it as soon as possible; I'm afraid I'm totally overloaded with RL work at the moment, but that should ease up by the end of the week. I'll race Tim to the appropriate buttons :D Happymelon 22:50, 1 February 2010 (UTC)[reply]
I have created a branch at /mediawiki/branches/parser-work in Wikimedia's SVN repo, and applied your initial patch, in revs 62082-4. My commiserations that your access request is taking its time; hopefully you won't have to wait as long as I did :D Happymelon 14:24, 7 February 2010 (UTC)[reply]
Just in time, I'm going home from vacation today :). Thank you. You have been very helpfull. --Than4213 21:53, 7 February 2010 (UTC)[reply]

Gurch

edit
  • Requested commit name: gurch
  • Expected area to work in: API (core and extensions)
  • key
  • Past work on MediaWiki: a half-dozen one-line patches, a larger one that, to quote Tim, "may crash the site", some bug/feature requests, some documentation and a fair bit of general familiarity with the technical side of things on Wikimedia projects.
  • Past programming experience: I wrote Huggle, whether that's a good or bad thing is open to interpretation.

Roan and Reedy both insisted I request this. Gurch 13:00, 24 January 2010 (UTC)[reply]

  • Requested commit name: happydog
  • Expected area to work in: CodeReview extension initially. I have a bunch of patches in my local copy, mostly related to using it with multiple repos, and would like to give them back to the community. Also did some work on integrating the namespace manager but that has bit-rot now - would like to pick that up again. In longer term would like to do some work on the core, in particular with relation to easing deployment for new users and simplifying general system management. May also move some of my more stable extensions into the MW repo, if appropriate.
  • link to public key
  • Past work on MediaWiki - Long time hacker of MW (since v1.3) have written multiple extensions, have contributed massively to the documentation on this site, which involved a lot of in-depth investigation of the source code. Have submitted patches but they invariably got fixed by someone else before my patch was reviewed, so I stopped bothering. However have a long-standing familiarity with the code base. Am familiar with the communication channels (wikitech-l, #mediawiki, etc.) and the design philosophies behind the software and the directions it is going in.
  • Past programming experience - Degree in Computer Science. Professional programmer since 1998. PHP main language since 2001. Would class myself as a PHP expert (so not quite at guru level yet...). Work full-time developing PHP-based web applications and use SVN and Bugzilla on a day-to-day basis for our in-house project management. Very familiar with HTML/XHTML/XML and applicable standards, SQL, CSS, JavaScript and many other less-relevant technologies.

HappyDog 14:34, 10 February 2010 (UTC)[reply]