Re: [Wikitech-l] Who is responsible for accepting backported patch sets for maintained versions?
Hi Greg. Thanks for the reply. Unfortunately the references to Robla's e-mail clarify nothing: It only addresses things outside of the scope of my original questions, since, interpreting the text literally, you will only be responsible for code that is to be deployed on Wikimedia websites, which is always master, never a release branch meant for use by third parties. For the sake of clarity, I think it may be useful to repeat the original questions from this thread: A. Who can and will review and approve [..] submitted for backporting? (for clarity sake: to branches of supported point releases of MediaWiki, for example MediaWiki 1.19 and MediaWiki 1.20, which are not in use by Wikimedia). I thank Chad for doing that, and I acknowledge that many have the technical right to merge code into these branches, but that's not what I'm asking here. B. Who is MediaWiki's release manager, and what can we expect of the person who has that role? Given the information provided by Rob Lanphier, it's not the Wikimedia Release Manager Greg Grossmeier, as he's responsible for managing the deployment process for the Wikimedia websites. Siebrand On Thu, Feb 21, 2013 at 5:59 AM, Greg Grossmeier g...@wikimedia.org wrote: (apologies for the none-theading of this; I wasn't subscribed to wikitech-l with this address when this message/thread was sent) quote name=Mark A. Hershberger date=2013-02-19 time=23:09:18 On Tue 19 Feb 2013 04:39:25 PM EST, Sumana Harihareswara wrote: My longer term question is: Who is MediaWiki's release manager, and what can we expect of the person who has that role? I think the answer is now that Greg Grossmeier fills the role of MediaWiki's release manager so he will have to answer this. :-) This subject has come up a couple of times in the past week so I look forward to working with Greg to implement some policy around MediaWiki releases -- especially the point releases for 1.19, the LTS release. There is a lot to discuss and I look forward to those conversations. Hello! To make this explicit: Everyone: please do feel free to contact me (email or on IRC, I'm greg-g) with any ideas, concerns, breakthroughs, gotchas, whatever dealing with this topic. I might not be able to do anything about it now, and I might not be the right person to deal with it in all cases, but I can help route things and keep notes so that we don't lose track of good ideas. Generally, what can you expect from me in this new role? I hope the email robla sent announcing my position can clarify much of it: http://lists.wikimedia.org/pipermail/wikitech-l/2013-February/066672.html Quoting robla: Greg will be managing the deployment process for the Wikimedia websites, focusing at first on improving release notes and outbound communication, freeing up folks like Sam to focus the engineering aspects of the role. He'll help our Bug Wrangler (Andre) figure out how to deal with high priority deployment-related issues; Andre will continue to broadly manage the flow of all bugs, while Greg will narrowly focus on very high priority issues through fix deployment. He'll also take over coordination of our deployment calendar[1], and will likely be a little nosier than many of us have had the time to do. Over time, Greg will look more holistically at our deployment practice, and potentially lead a change over to a more continuous deployment model. Best, Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | [[User:Greg G (WMF)]] A18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Siebrand Mazeland Product Manager Language Engineering Wikimedia Foundation M: +31 6 50 69 1239 Skype: siebrand Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] EasyRDF dependency
After evaluating different options, we want to use for generating Wikidata's RDF export the EasyRDF library: http://www.easyrdf.org/ We only need a part of it -- whatever deals with serializers. We do not need parsers, anything to do with SPARQL, etc. In order to minimize reviewing and potential security holes, is there an opinion on what is the better approach: * just use it as a dependency, review it all, and keep it up to date? * fork the library, cut out what we do not need, and keep up with work going on the main branch, backporting it, but reducing the used code size thus? How is this handled with other libraries, like Solarium, as a reference? Cheers, Denny -- Project director Wikidata Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. +49-30-219 158 26-0 | http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Corrupt pages on English Wikipedia
On Wed, 2013-02-20 at 08:59 -0500, Sumana Harihareswara wrote: Brian, would you take a look at https://www.mediawiki.org/wiki/How_to_report_a_bug and maybe update it to clarify what sorts of information to try to hold on to for debugging purposes? I'd like to keep How_to_report_a_bug a generic, high-level page. Case-specific debug information is very welcome on a separate page though (similar to http://www.mediawiki.org/wiki/Manual:How_to_debug for MediaWiki), and could be linked to from How_to_report_a_bug. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Who is responsible for accepting backported patch sets for maintained versions?
On 02/21/2013 04:13 AM, Siebrand Mazeland (WMF) wrote: B. Who is MediaWiki's release manager, and what can we expect of the person who has that role? I had a conversation with Maria Miteva (Robla at least got copies of these emails) last week when she asked if I was planning on doing the release of MW 1.21 and whether https://www.mediawiki.org/wiki/MediaWiki_1.21 could point to me as the release manager for MediaWiki. I told her I was still planning on doing that release, probably shortly before going to Amsterdam. I think a lot of the confusion here (including my own) comes from the decisions that have been made outside of the Foundation surrounding the future of MediaWiki itself. As these decisions have been made (LTS, MW's Release Schedule, etc.), it appears that the Foundation has become more focused on its goals -- Wikipedia and its sister sites -- and less concerned with the logistics of MediaWiki outside of the Foundations use. As Siebrand pointed out, this seems to extend to the description of the duties of the newly hired release manager. Absent an explicit statement from anyone inside Foundation, we've been a bit confused. So, I'll WP:Bold and answer Siebrand's question: I am MediaWiki's release manager. Here is what you can expect of me: * Manage the release schedule. At least initially, I will be making the releases. * Work to get bugfixes backported to 1.19. I don't have Gerrit rights to commit to the REL1_19 branch, but that will keep me from fixing bugs by fiat. * Champion features that non-WMF users want. This includes things like searching inside a category and a WYSIWYG editor. * Work with community members to triage non-security bugs in released versions of MediaWiki. Is there something else the MW release manager should be doing? Let me know. Is there anyone in the WMF who disagrees with this assessment? Now is the time to speak up. Mark -- http://hexmode.com/ There is no path to peace. Peace is the path. -- Mahatma Gandhi, Non-Violence in Peace and War ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Who is responsible for accepting backported patch sets for maintained versions?
* Work to get bugfixes backported to 1.19. I don't have Gerrit rights to commit to the REL1_19 branch, but that will keep me from fixing bugs by fiat. I think we should give you such rights. --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Nominating Mark Hershberger as core maintainer
I've nominated Mark Hershberger as MediaWiki core maintainer in Gerrit. Please provide your feedback at the following URL: https://www.mediawiki.org/wiki/Git/Gerrit_project_ownership#hexmode_.2F_Mark_Hershberger_for_MediaWiki_core Cheers! -- Siebrand Mazeland Product Manager Language Engineering Wikimedia Foundation M: +31 6 50 69 1239 Skype: siebrand Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Who is responsible for accepting backported patch sets for maintained versions?
On Thu, Feb 21, 2013 at 4:19 PM, Mark A. Hershberger m...@everybody.orgwrote: On 02/21/2013 04:13 AM, Siebrand Mazeland (WMF) wrote: B. Who is MediaWiki's release manager, and what can we expect of the person who has that role? I had a conversation with Maria Miteva (Robla at least got copies of these emails) last week when she asked if I was planning on doing the release of MW 1.21 and whether https://www.mediawiki.org/wiki/MediaWiki_1.21 could point to me as the release manager for MediaWiki. I told her I was still planning on doing that release, probably shortly before going to Amsterdam. Yay! Thanks for that plan. I think a lot of the confusion here (including my own) comes from the decisions that have been made outside of the Foundation surrounding the future of MediaWiki itself. Yes, I agree. As these decisions have been made (LTS, MW's Release Schedule, etc.), it appears that the Foundation has become more focused on its goals -- Wikipedia and its sister sites -- and less concerned with the logistics of MediaWiki outside of the Foundations use. As Siebrand pointed out, this seems to extend to the description of the duties of the newly hired release manager. Absent an explicit statement from anyone inside Foundation, we've been a bit confused. So, I'll WP:Bold and answer Siebrand's question: I am MediaWiki's release manager. That makes me very happy, and creates at least some clarity. Thank you, Mark. Here is what you can expect of me: * Manage the release schedule. At least initially, I will be making the releases. * Work to get bugfixes backported to 1.19. I don't have Gerrit rights to commit to the REL1_19 branch, but that will keep me from fixing bugs by fiat. We also have REL1_20, of course. I have just nominated you to be added as a MediaWiki core maintainer. Feedback is requested at http://hexm.de/MarkForCore. * Champion features that non-WMF users want. This includes things like searching inside a category and a WYSIWYG editor. As a non-native speaker I sometimes have to look things up in a dictionary. In this case I found out that to champion means to fight for or defend a cause. Very noble of you. Please do ask for help, because those fights can be very lonely otherwise :). * Work with community members to triage non-security bugs in released versions of MediaWiki. Will it help if you get access to the Security area of bugzilla, or at least are informed of upcoming security fixes by Wikimedia employees on Mediawiki master? Up to now, Chris Steipp has done backports and made security releases when security issues were fixed on master and in Wikimedia deployments, but it is unclear to me if this support will continue. It's probably a good idea demand clarity on this, Mark. Is there something else the MW release manager should be doing? Let me know. We probably now expect the world of you, but there's nothing explicit I can think of at the moment. Is there anyone in the WMF who disagrees with this assessment? Now is the time to speak up. The above are my own opinions, and not necessarily those of any of my clients. Cheers! -- Siebrand M: +31 6 50 69 1239 Skype: siebrand ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Who is responsible for accepting backported patch sets for maintained versions?
On 21 February 2013 16:02, Siebrand Mazeland (WMF) smazel...@wikimedia.org wrote: On Thu, Feb 21, 2013 at 4:19 PM, Mark A. Hershberger m...@everybody.orgwrote: * Champion features that non-WMF users want. This includes things like searching inside a category and a WYSIWYG editor. As a non-native speaker I sometimes have to look things up in a dictionary. In this case I found out that to champion means to fight for or defend a cause. Very noble of you. Please do ask for help, because those fights can be very lonely otherwise :). Speaking as a tarball user, I'd expect from an LTS like 1.19: * Security maintenance. This is the main thing for me. * Preservation of internal and external APIs. We were actually caught by the API change between 1.15.3 and 1.15.4 - which was necessary for security reasons, but I'd expect no other reason for an API change. And the internal API-like things that extension users use, so that an extension written to 1.19 would keep working. * Last: new features, a visual editor, etc. I would expect that new things would require a later version. So basically as a sysadmin I'm after stability. How do others' expectations measure up? - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Who is responsible for accepting backported patch sets for maintained versions?
On 02/21/2013 07:19 AM, Mark A. Hershberger wrote: Is there something else the MW release manager should be doing? Let me know. Is there anyone in the WMF who disagrees with this assessment? Now is the time to speak up. Ok, just a question as humble 3rd party MediaWiki user and technical volunteer coordinator at the WMF: is there a possibility to consider having a regular free software release process? master/unstable --- (testing releases?) --- stable releases Having English Wikipedia using whatever version they have the muscle to pull and maintain, but moving them out of the very middle of the release process. Potential benefits? * Not so direct connection between getting +2 rights and breaking Wikipedia, makes it easier to non-WMF contributors to work on non-WMF priorities. * MediaWiki development not so dependent from (English) Wikipedia immediate needs, 3rd parties involved earlier in the testing process. * Reduction of the risk of a mid-term fork, or abandonment of MediaWiki out of Wikimedia projects. Potential disadvantages? * Changing the process takes work: inertia, resistance and actual changes. * Perhaps WMF maintainers having to discuss and lobby more with the rest to push / rush features into releases. * Perhaps English Wikipedia having to wait some more weeks for certain features. I think the current process is ok-ish in the short term: non-WMF contributors are getting +2 and 3rd parties are getting tarballs. However, I'm more concerned about the mid term future of MediaWiki out of the Wikimedia projects. And the complexity to maintain all this software and this community all by ourselves as opposed of doing it as part of a wider... ecosystem (I said it) including many 3rd party professionals earning their salaries thanks to MediaWiki. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Who is responsible for accepting backported patch sets for maintained versions?
On Thu, Feb 21, 2013 at 11:55 AM, Quim Gil q...@wikimedia.org wrote: Ok, just a question as humble 3rd party MediaWiki user and technical volunteer coordinator at the WMF: is there a possibility to consider having a regular free software release process? master/unstable --- (testing releases?) --- stable releases We already do have that. Except you're assuming Wikipedia would run on the testing or stable release rather than on master/unstable. In other words, you want to go back in time a few years. That's about how it used to be a few years ago, although it got to the point of waiting many months rather than a few extra weeks to get anything fixed that wasn't a major security bug or performance issue. And then the upgrades were huge deals with hundreds of bugs having to be tracked down. Most people seem to be happy to have gotten away from that and to the point where it's at most 3.5 weeks[1] between something being merged and it being live on all the sites. And there's talk about increasing the pace further. Now the main problem seems to be finding someone to +2 patches in Gerrit. Having English Wikipedia using whatever version they have the muscle to pull and maintain, but moving them out of the very middle of the release process. You're focusing too much on the English Wikipedia, IMO. All the sites get updated on the same cycle. Potential disadvantages? * Changing the process takes work: inertia, resistance and actual changes. * Perhaps WMF maintainers having to discuss and lobby more with the rest to push / rush features into releases. * Perhaps English Wikipedia having to wait some more weeks for certain features. * Everything has to be reviewed once for inclusion in MediaWiki and then again for it to be launched to WMF sites, which takes away time for WMF contributors to work on improvements. [1]: Example: If something were merged on Feb 4 just after wmf9 was branched, it would go up on Feb 25 (3 weeks later) to enwiki with wmf10 and Feb 27 to the other Wikipedias. And Feb 20 for all the non-Wikipedia sites. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Do we need to change the MW release process to better involve the non-WMF community?
(Adding a couple of mailing lists so others can weigh in. Changing subject so those added aren't completely lost.) On 02/21/2013 11:55 AM, Quim Gil wrote: Ok, just a question as humble 3rd party MediaWiki user and technical volunteer coordinator at the WMF: is there a possibility to consider having a regular free software release process? master/unstable --- (testing releases?) --- stable releases ... I think the current process is ok-ish in the short term: non-WMF contributors are getting +2 and 3rd parties are getting tarballs. As you say, I think the current process is Ok(ish) for now. We need to get others in the MediaWiki ecosystem involved in core before this becomes something we really need to do. It would be great to have developers from other significant MediaWiki sites (like Referata, Wikia, Citizendium, etc) become more involved and start introducing features or hooks that they use into core or making the extensions available. Of course, some of those developers have already been involved. But right now, I don't sense a huge amount of friction between the WMF's needs and the non-WMF MediaWiki-using community. The most that can be said is that the WMF is focused on its sites and doesn't make third party use a priority. This doesn't stop support for other databases, though: Oracle, MS SQL, PostgreSQL, SQLite, or even my recent changes to separate out DB schema changes in MySQL. That said, I'm very interested in this conversation. As MZ will remind you, I did advocate for the formation of the MediaWiki Foundation. Mark. -- http://hexmode.com/ There is no path to peace. Peace is the path. -- Mahatma Gandhi, Non-Violence in Peace and War ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Do we need to change the MW release process to better involve the non-WMF community?
On 2013-02-21 1:40 PM, Mark A. Hershberger m...@everybody.org wrote: (Adding a couple of mailing lists so others can weigh in. Changing subject so those added aren't completely lost.) On 02/21/2013 11:55 AM, Quim Gil wrote: Ok, just a question as humble 3rd party MediaWiki user and technical volunteer coordinator at the WMF: is there a possibility to consider having a regular free software release process? master/unstable --- (testing releases?) --- stable releases ... I think the current process is ok-ish in the short term: non-WMF contributors are getting +2 and 3rd parties are getting tarballs. As you say, I think the current process is Ok(ish) for now. We need to get others in the MediaWiki ecosystem involved in core before this becomes something we really need to do. It would be great to have developers from other significant MediaWiki sites (like Referata, Wikia, Citizendium, etc) become more involved and start introducing features or hooks that they use into core or making the extensions available. Of course, some of those developers have already been involved. But right now, I don't sense a huge amount of friction between the WMF's needs and the non-WMF MediaWiki-using community. The most that can be said is that the WMF is focused on its sites and doesn't make third party use a priority. This doesn't stop support for other databases, though: Oracle, MS SQL, PostgreSQL, SQLite, or even my recent changes to separate out DB schema changes in MySQL. That said, I'm very interested in this conversation. As MZ will remind you, I did advocate for the formation of the MediaWiki Foundation. Mark. -- http://hexmode.com/ There is no path to peace. Peace is the path. -- Mahatma Gandhi, Non-Violence in Peace and War ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Having wikipedia use unstable versions helps to catch many bugs. Not only are wikimedians great testers (they (ab)use the software in insane ways), by in large bugs encountered by wikimedians get reported effectively. Thus the use of unstablish releases on wikimedia allows for much more stable core releases. -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Do we need to change the MW release process to better involve the non-WMF community?
On 02/21/2013 12:50 PM, Brian Wolff wrote: Thus the use of unstablish releases on wikimedia allows for much more stable core releases. Thanks for pointing this out. I meant to say this, too. I guess the question I want other MediaWiki users to answer is: Are there any concerns that mitigate this benefit? Mark. -- http://hexmode.com/ There is no path to peace. Peace is the path. -- Mahatma Gandhi, Non-Violence in Peace and War ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Do we need to change the MW release process to better involve the non-WMF community?
On Thu, Feb 21, 2013 at 11:39 AM, Mark A. Hershberger m...@everybody.org wrote: But right now, I don't sense a huge amount of friction between the WMF's needs and the non-WMF MediaWiki-using community. The most that can be said is that the WMF is focused on its sites and doesn't make third party use a priority. This doesn't stop support for other databases, though: Oracle, MS SQL, PostgreSQL, SQLite, or even my recent changes to separate out DB schema changes in MySQL. Yes, unfortunately schema changes and other DB related changesets tend to only get applied to MySQL/SQLite, and the other DBs tend to get ignored or lag behind by a few months. That's about my only gripe, that, and that setting jenkins up for these other backends was never completed. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: [Wmfall] Luis Villa joins WMF as Deputy General Counsel
El 20/02/13 00:49, Luis Villa escribió: Hah... I think calling me a developer is, at this point, a bit of a stretch, but I look forward to working with the tech team :) ¡Welcome, Luis! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] EasyRDF dependency
On 21/02/13 10:18, Denny Vrandečić wrote: After evaluating different options, we want to use for generating Wikidata's RDF export the EasyRDF library: http://www.easyrdf.org/ We only need a part of it -- whatever deals with serializers. We do not need parsers, anything to do with SPARQL, etc. In order to minimize reviewing and potential security holes, is there an opinion on what is the better approach: * just use it as a dependency, review it all, and keep it up to date? * fork the library, cut out what we do not need, and keep up with work going on the main branch, backporting it, but reducing the used code size thus? How is this handled with other libraries, like Solarium, as a reference? Cheers, Denny I would use it as a dependency, avoiding to fork our own version from upstream. That said, not exposing the files to web requests is probably a good idea. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] NEW version Extension:RSS 2.18 released
Manual https://www.mediawiki.org/wiki/Extension:RSS Code tree https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/RSS.git;a=tree Release Notes https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/RSS.git;a=blob_plain;f=RELEASE-NOTES;hb=HEAD This is the submission to git after review has finished. The patch introduces all previously pending and unreviewed changes since the migration of E:RSS from SVN to git. These changes have now been code reviewed and also corrected. The new version introduces the features which were already available in my fork (https://github.com/Wikinaut/mediawiki-extension-RSS) which became obsolete by this submission. Bugs should be filed in https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensionscomponent=RSS . signature.asc Description: OpenPGP digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Who is responsible for accepting backported patch sets for maintained versions?
On Thu, Feb 21, 2013 at 7:19 AM, Mark A. Hershberger m...@everybody.org wrote: On 02/21/2013 04:13 AM, Siebrand Mazeland (WMF) wrote: B. Who is MediaWiki's release manager, and what can we expect of the person who has that role? [..] Absent an explicit statement from anyone inside Foundation, we've been a bit confused. So, I'll WP:Bold and answer Siebrand's question: I am MediaWiki's release manager. Here is what you can expect of me: * Manage the release schedule. At least initially, I will be making the releases. * Work to get bugfixes backported to 1.19. I don't have Gerrit rights to commit to the REL1_19 branch, but that will keep me from fixing bugs by fiat. * Champion features that non-WMF users want. This includes things like searching inside a category and a WYSIWYG editor. * Work with community members to triage non-security bugs in released versions of MediaWiki. Is there something else the MW release manager should be doing? Let me know. Is there anyone in the WMF who disagrees with this assessment? Not that I'm aware of. Thank you, Mark, for taking this on! Re: Greg's title as Release Manager. Wikimedia Foundation is relatively unique in having both releases and deployments that are distinct. Most of the industry uses these terms interchangeably. When we went to advertise this position, we could have more accurately (by MediaWiki dev community standards) called this position a Deployment Manager, but that's not what the role is typically called in other organizations, so we went with Release Manager. Greg is largely going to be focused on Wikimedia cluster issues in his role. He'll be responsible for making sure *someone* is on the task of publishing a release tarball, and may get more involved if there are widespread concerns about quality or a rethinking of our current strategy, but for the forseeable future, the role is largely supportive. Greg may well have cycles to help Mark with the release process, but Mark will take the lead on it. One potential grey area is security releases, which need simultaneous release and deployment. That's an area we'll need to work in close collaboration. This all make sense? Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Do we need to change the MW release process to better involve the non-WMF community?
I'd like to see MediaWiki gain a more stable release process as well. I think some of the primary things that we're lacking are: - Where is QA? I mean, I know somewhere somebody is probably doing some sort of testing, but having worked as a QA engineer I haven't seen anything in MW that would resemble proper and traditional testing (excluding the unit testing). Where's the list of test cases that need to be performed for each release? How can one make new test cases and add them? etc. Maybe this already exists, but if it does it's definitely not documented well enough. - Stable sets of expected release features. In most companies I've worked in, every single bug upon being reported is immediately scheduled for a release, even if it just means deferring it to an unknown Future Release. But doing a quick search in Bugzilla shows MW has 5000+ bugs that are not scheduled, some of which are even high priority bugs. I've probably said this before, but it'd be good if consumers knew beforehand what they may expect in the next MW release (even if it's only tentative) so that they can debate whether or not to prepare for an upgrade. I've been told before that that's what the release notes are for, but that's not the point. Release notes currently only include stuff that's already done. - Faster review process. This is something that's not at all easy, and I know many are aware, but it takes a while to get reviews. I mean, there are people like me who get notifications for every new change in gerrit, and thus I'll see everything even if I wasn't added as a reviewer, but not everybody does that, which leaves the question of how to get your stuff reviewed and who to go to. There's a list of MW.org that has some people, but I've found it's usually not helpful until you're more involved and actually know who those people are. Other than those process issues, there are a few feature issues that IMO I think are holding people back: - As said, DB support, especially for high-use systems like Postgres and MSSQL. - Enterprise platforms. What if I want to deploy MW onto AWS or VMWare? Many companies have pre-packaged systems for this. For example, at the company I'm working at now, deploying their product to AWS is as easy as copying the ID number into the web GUI and clicking deploy. Also, is there any tracking on HipHop support? - Non-PHP. This is probably far off in the future, but eventually it'd be nice to be able to setup MW without having to deal with PHP at all, i.e., have a configuration file in YAML or something. Even PHP frameworks like Symfony have abstracted out the PHP, and that's a case where you're actually developing *in* PHP. :P *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Thu, Feb 21, 2013 at 1:01 PM, OQ overlo...@gmail.com wrote: On Thu, Feb 21, 2013 at 11:39 AM, Mark A. Hershberger m...@everybody.org wrote: But right now, I don't sense a huge amount of friction between the WMF's needs and the non-WMF MediaWiki-using community. The most that can be said is that the WMF is focused on its sites and doesn't make third party use a priority. This doesn't stop support for other databases, though: Oracle, MS SQL, PostgreSQL, SQLite, or even my recent changes to separate out DB schema changes in MySQL. Yes, unfortunately schema changes and other DB related changesets tend to only get applied to MySQL/SQLite, and the other DBs tend to get ignored or lag behind by a few months. That's about my only gripe, that, and that setting jenkins up for these other backends was never completed. ___ 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
Re: [Wikitech-l] Who is responsible for accepting backported patch sets for maintained versions?
On 02/21/2013 04:26 PM, Rob Lanphier wrote: This all make sense? Yes, I appreciate you weighing in. -- http://hexmode.com/ There is no path to peace. Peace is the path. -- Mahatma Gandhi, Non-Violence in Peace and War ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Installing Mediawiki SourceCode
Hi Guys, I am a newbie to mediawiki, I was following the instructions on this page http://www.mediawiki.org/wiki/Download_from_Git After cloning the gir repository on my desktop, there is no .git folder in it. Henceforth any of the following commands on that page like git branch -r | sort -V or git checkout -b RELrelease number origin/RELrelease number are returning error. Can some body please guide me through these errors ? Cheers, Anubhav Anubhav Agarwal| 4rth Year | Computer Science Engineering | IIT Roorkee ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Installing Mediawiki SourceCode
On Thursday, February 21, 2013 at 2:14 PM, anubhav agarwal wrote: Hi Guys, I am a newbie to mediawiki, I was following the instructions on this page http://www.mediawiki.org/wiki/Download_from_Git After cloning the gir repository on my desktop, there is no .git folder in it. Henceforth any of the following commands on that page like git branch -r | sort -V or git checkout -b RELrelease number origin/RELrelease number Anubhav, you have to 'cd' into the directory created by git-clone. -- Ori Livneh ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Who is responsible for accepting backported patch sets for maintained versions?
On Feb 21, 2013, at 4:51 PM, bawolff bawolff...@gmail.com wrote: * Work to get bugfixes backported to 1.19. I don't have Gerrit rights to commit to the REL1_19 branch, but that will keep me from fixing bugs by fiat. I think we should give you such rights. --bawolff Though it is probably obvious, just to point out (and to be corrected if I misunderstood): You wouldn't single-handedly fix bugs. The bug fix is first submitted in master (where submission and review happen by two different people where Mark could be the writer of a patch or the reviewer/merger, but never both). And in release branches (as far as I know) we only tolerate self-merges if the change is a cherry-pick of an already-merged change in master. If the change is e.g. a bug fix of something that occurred due to combination of backports in the release branch, it should be reviewed and written by two different people like any other change. And for others looking to help out in back porting fixes: One can submit a backport without merge access. It is the same process (cherry-pick to another branch, submit back to Gerrit with the same change id). Except that you'd ask for someone to approve the merge instead of self-merging right away. -- Krinkle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Installing Mediawiki SourceCode
Really Sorry, I didn't notice they were there. On Fri, Feb 22, 2013 at 3:50 AM, Ori Livneh o...@wikimedia.org wrote: On Thursday, February 21, 2013 at 2:14 PM, anubhav agarwal wrote: Hi Guys, I am a newbie to mediawiki, I was following the instructions on this page http://www.mediawiki.org/wiki/Download_from_Git After cloning the gir repository on my desktop, there is no .git folder in it. Henceforth any of the following commands on that page like git branch -r | sort -V or git checkout -b RELrelease number origin/RELrelease number Anubhav, you have to 'cd' into the directory created by git-clone. -- Ori Livneh ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Cheers, Anubhav Anubhav Agarwal| 4rth Year | Computer Science Engineering | IIT Roorkee ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Installing Mediawiki SourceCode
I have an alternative question. Why is there -b in the options? Git should automatically create local branches when checking out a remote branch, i.e., doing git checkout REL1_20 should automatically create a branch with that name based on origin/REL1_20. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Thu, Feb 21, 2013 at 5:23 PM, anubhav agarwal anubhav...@gmail.comwrote: Really Sorry, I didn't notice they were there. On Fri, Feb 22, 2013 at 3:50 AM, Ori Livneh o...@wikimedia.org wrote: On Thursday, February 21, 2013 at 2:14 PM, anubhav agarwal wrote: Hi Guys, I am a newbie to mediawiki, I was following the instructions on this page http://www.mediawiki.org/wiki/Download_from_Git After cloning the gir repository on my desktop, there is no .git folder in it. Henceforth any of the following commands on that page like git branch -r | sort -V or git checkout -b RELrelease number origin/RELrelease number Anubhav, you have to 'cd' into the directory created by git-clone. -- Ori Livneh ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Cheers, Anubhav Anubhav Agarwal| 4rth Year | Computer Science Engineering | IIT Roorkee ___ 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] Subclassing HTMLForm Question
Hey, So there's a change (https://gerrit.wikimedia.org/r/48995) that's adding a new subclass to HTMLForm, so I had a quick question for whoever has more experience with HTMLForm than I do. The new subclass will always output a table for the getInputHTML(), even if the parent form is set to div/raw output. Is this OK, i.e., is the table/div/raw only applicable to the form itself, or should the subclass make sure to follow that format as well? Unfortunately, there is no precedent for this because every other field type only puts out an input tag. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Categories in Module namespace
May Lua scripts be categorized? -- Bináris ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Subclassing HTMLForm Question
Hey, The new subclass will always output a table for the getInputHTML(), even if the parent form is set to div/raw output. That very much sounds like a violation of the Liskov substitution pattern. In other words, it sounds like code using an instance of HTMLForm might run into problems when this instance happens to be of the type defined by the new subclass. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Sending 200s for empty user pages of valid users
See: https://bugzilla.wikimedia.org/show_bug.cgi?id=45255 https://gerrit.wikimedia.org/r/#/c/50305/ Just in case this is controversial, I thought I'd bring this topic up on the list. We currently send 404s for empty user pages, even for valid users. It would be ideal to use user page urls as OpenID provider identity urls, but most users never create their user pages. OpenID expects identity urls to be 200s, not 404s. I'd like us to send 200s rather than 404s for any valid user's user pages, whether the page has content or not. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Installing Mediawiki SourceCode
On Thursday, February 21, 2013 at 2:33 PM, Tyler Romeo wrote: I have an alternative question. Why is there -b in the options? Git should automatically create local branches when checking out a remote branch, i.e., doing git checkout REL1_20 should automatically create a branch with that name based on origin/REL1_20. Only if you have branch.autosetupmerge configured to true -- Ori Livneh ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Categories in Module namespace
On Thursday, February 21, 2013 at 2:39 PM, Bináris wrote: May Lua scripts be categorized? Scribunto modules may export multiple functions. IMHO, it makes more sense to group conceptually-related functions by bundling them into single modules, much like the standard libraries of most programming languages are laid out. That makes more sense to me than categories. -- Ori Livneh ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sending 200s for empty user pages of valid users
On Thu, Feb 21, 2013 at 2:59 PM, Ryan Lane rlan...@gmail.com wrote: See: https://bugzilla.wikimedia.org/show_bug.cgi?id=45255 https://gerrit.wikimedia.org/r/#/c/50305/ Just in case this is controversial, I thought I'd bring this topic up on the list. We currently send 404s for empty user pages, even for valid users. It would be ideal to use user page urls as OpenID provider identity urls, but most users never create their user pages. OpenID expects identity urls to be 200s, not 404s. I'd like us to send 200s rather than 404s for any valid user's user pages, whether the page has content or not. No objection for me. We should be showing a nice user dashboard on the user page anyway, regardless of whether the user's filled out any text. Seems to me it might be better to override WikiPage::hasViewableContent() though rather than hardcode that check into Article::showMissingArticle(). -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Categories in Module namespace
On 22/02/13 09:39, Bináris wrote: May Lua scripts be categorized? After https://gerrit.wikimedia.org/r/#/c/50143/ is deployed, it will be possible to add a module to a category by adding a category tag to its /doc subpage. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Do we need to change the MW release process to better involve the non-WMF community?
On Thu, Feb 21, 2013 at 2:01 PM, Tyler Romeo tylerro...@gmail.com wrote: I'd like to see MediaWiki gain a more stable release process as well. I think some of the primary things that we're lacking are: - Where is QA? I mean, I know somewhere somebody is probably doing some sort of testing, but having worked as a QA engineer I haven't seen anything in MW that would resemble proper and traditional testing (excluding the unit testing). Where's the list of test cases that need to be performed for each release? How can one make new test cases and add them? etc. Maybe this already exists, but if it does it's definitely not documented well enough. Two answers, possibly oversimplified: First, supporting Mediawiki for 3rd parties is not a priority for WMF in recent times, so QA efforts have been focused elsewhere. Second, volunteer QA testing in general *is* a priority for WMF right now, so a volunteer QA effort to test Mediawiki releases would be a likely candidate for WMF support. This sort of project would fall naturally into the effort we're calling Features Testing, and we're looking to support that sort of project by way of a Group http://www.mediawiki.org/wiki/Groups/Proposals/Features_testing. -Chris ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Installing Mediawiki SourceCode
Aha, OK thanks. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Thu, Feb 21, 2013 at 6:03 PM, Ori Livneh o...@wikimedia.org wrote: On Thursday, February 21, 2013 at 2:33 PM, Tyler Romeo wrote: I have an alternative question. Why is there -b in the options? Git should automatically create local branches when checking out a remote branch, i.e., doing git checkout REL1_20 should automatically create a branch with that name based on origin/REL1_20. Only if you have branch.autosetupmerge configured to true -- Ori Livneh ___ 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
Re: [Wikitech-l] Wikitech-l Digest, Vol 115, Issue 93
Hi everybody, I want to help about wikimedia's bugs. How can I get wikimedia's bugs ? Can somebody please help me ? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikitech-l Digest, Vol 115, Issue 93
Our bugs are at https://bugzilla.wikimedia.org. Was there anything specific you'd like to help with? On Thu, Feb 21, 2013 at 4:29 PM, Kancer Ezeroğlu ezeroglukan...@gmail.comwrote: Hi everybody, I want to help about wikimedia's bugs. How can I get wikimedia's bugs ? Can somebody please help me ? ___ 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] How to help with bugs (was Re: Wikitech-l Digest, Vol 115, Issue 93)
On 02/21/2013 04:29 PM, Kancer Ezeroğlu wrote: Hi everybody, Hello, welcome! I want to help about wikimedia's bugs. How can I get wikimedia's bugs ? Can somebody please help me ? Are you interested in helping triaging bugs or fixing them? Any specific product or feature? Check these pages: Introduction to bug triaging https://www.mediawiki.org/wiki/Bug_management/Triage_tasks Annoying little bugs to start with https://www.mediawiki.org/wiki/Annoying_little_bugs Join our testing and bug management activities: https://www.mediawiki.org/wiki/QA/Weekly_goals How to contribute https://www.mediawiki.org/wiki/How_to_contribute Feel free replying with further questions. We will do our best connecting you with a task. There is no lack of work to do. :) -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] wfMsg and wfMsgForContent are deprecated. What to use?
On 19 February 2013 19:10, Krenair kren...@gmail.com wrote: See https://www.mediawiki.org/wiki/Manual:Messages_API#Deprecated_wfMsg.2A_functions The whole page is a recommended reading. I refactored it about a week ago to make it more accessible. Thank you to everyone who has already provided feedback or cleaned up after my mistakes. -Niklas -- Niklas Laxström ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Categories in Module namespace
2013/2/22 Tim Starling tstarl...@wikimedia.org After https://gerrit.wikimedia.org/r/#/c/50143/ is deployed, it will be possible to add a module to a category by adding a category tag to its /doc subpage. Thank you! I suppose it will be announced here. Ori: your concept is good and I will try to follow it, but hard to expect it from everyone when many authors write scripts and test. Categories help in searching, and as well as by templates, some of the scripts will be full protected which effect too many pages. So bundling and categories will work together. -- Bináris ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
