Talk:Commit access requests

Miles long Bugzilla links
Please mention how to make a shorter link to e.g., My Patches, as currently all we know how to do is copy the link from our browser. Jidanni 20:38, 4 June 2009 (UTC)
 * There isn't a shorter way, besides copying that long link into a URL shortening service such as tinyurl. -- Skiz zerz  21:24, 4 June 2009 (UTC)


 * There is; a lot of the parameters in the query string are empty/defaults, so can be omitted. This link will produce the same results. Gurch 23:56, 22 November 2009 (UTC)

What's the timeframe for a response to a commit access request
What sort of timeframe is typical from the time a request for commit access is made until it is granted/denied? --Lhridley 17:51, 14 February 2010 (UTC)
 * Anywhere between a week and two months, depending on where you come in on the processing cycle. Improving response time is an ongoing issue. Happy ‑ melon 18:50, 14 February 2010 (UTC)

Is SVN access needed to fix unsupported extension
I've tried CategorySuggest extension which I found pretty useful. Unfortunately it seems it was half baked and had some bugs, and the author hasn't updated it in a few years. I was able to patch up the extension locally and wanted to post the new version, should I just go and request SVN access? Macsux 17:16, 3 March 2010 (UTC)

What to do when someone else commits your extension and you don't have write access?
Today I found an extension of mine was committed to the trunk.. that's great, except I don't have commit access. So basically I can't update my own extension for anyone who wants to download it via SVN.

I put in a request for commit access a week or two back, but in the meantime what should I do? Can I ask for it to be removed or renamed? I have no idea what changes were made to the source before it was committed, so in my eyes this is effectively a fork of my extension and shouldn't be allowed to occupy "/trunk/extensions/MaintenanceShell". When I get commit access I'm just going to completely overwrite this folder anyways (though I'll make an effort to keep any additional languages which have been added) --Frantik 11:49, 23 May 2010 (UTC)


 * Try not to think of it as "us" taking "your" extension. You've licensed it under the GPL, and in so doing have made a statement "I'm interested in collaborative development, please help me make my work better".  If someone has committed your extension, that is an indication that they think it is useful and important, which is a good thing.  If they have made changes, you should assume (or at least check whether) they are changes for the better, not treat them as an 'unauthorised fork'.  Asserting that your own work is 'the only true code', and that changes and improvements to it "shouldn't be allowed", is not in the spirit of free software; saying that you plan to blanket-revert any work that others have done to the code, is not in the spirit of collaborative development.  Why do you think that only your version of the code should be "allowed"? Happy ‑ melon 12:13, 23 May 2010 (UTC)
 * The main issues I have:
 * No one contacted me before or after the fact.. Surely the "sprit of collaborative development" includes a little communication.
 * I have to spend time investigating changes to determine if they are for the better, then decide to include them in the MAIN TRUNK which is NOT on SVN but on my computer.
 * The version on SVN includes changes but does not indicate those changes are made by someone else, violating the GPL
 * I am the only one who provides support for this extension.. people contact me asking for help.. so i have to keep up on the changes to the extension, which is fine, but I didn't even get the choice or a heads up about it.
 * And honestly, your flippant response about why do i think the extension that I have spent my time writing and supporting should be the "one true code" has made me realize that GNU GPL is not the way to go. I'm happy to share my work, but I don't want the headache of keeping track of other people's changes to my code, and then be expected to provide support for those changes.  I mean, are you going to spend your time helping someone who has a problem with my extension?  It would be different if I could update the SVN myself, but until then, it is a de facto fork.  How about YOU spend the time determining what changes have been made, and also update the code to indicate those changes, in the spirit of collaboration and everything.
 * --Frantik 12:47, 23 May 2010 (UTC)
 * I can delete it from SVN, if you'd like. ^demon

I agree with you that we shouldn't have extensions in Subversion that the original author can't modify. I would suggest that you request commit access to maintain it. I will note that this extension has some significant issues, see. Andrew Garrett 13:29, 23 May 2010 (UTC)
 * Nods. Happy ‑ melon 21:19, 23 May 2010 (UTC)
 * It's great that the code can finally get reviewed properly, but it sucks now I have a XSS vulnerability in the SVN with my name on that I can't even fix. :(.  Also, why is "Devunt" listed as the author of my extension according to that link?  How can I get emails about the problems with this extension? Basically, how can I take ownership of my extension back?
 * I put in a request for commit access to commit-access-requests@wikimedia.org on May 8, maybe someone can just expedite that request? 
 * --Frantik 13:45, 23 May 2010 (UTC)