(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 Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | [[User:Greg G (WMF)]] A18D 1138 8E47 FAC8 1C7D |
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 greg@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 Grossmeier GPG: 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
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
- 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
On Feb 21, 2013, at 4:51 PM, bawolff bawolff+wn@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
On Thu, Feb 21, 2013 at 4:19 PM, Mark A. Hershberger mah@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!
On 21 February 2013 16:02, Siebrand Mazeland (WMF) smazeland@wikimedia.org wrote:
On Thu, Feb 21, 2013 at 4:19 PM, Mark A. Hershberger mah@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.
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.
On Thu, Feb 21, 2013 at 11:55 AM, Quim Gil qgil@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.
(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.
On 2013-02-21 1:40 PM, "Mark A. Hershberger" mah@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.
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
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.
On Thu, Feb 21, 2013 at 11:39 AM, Mark A. Hershberger mah@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.
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 | tylerromeo@gmail.com
On Thu, Feb 21, 2013 at 1:01 PM, OQ overlordq@gmail.com wrote:
On Thu, Feb 21, 2013 at 11:39 AM, Mark A. Hershberger mah@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
On Thu, Feb 21, 2013 at 2:01 PM, Tyler Romeo tylerromeo@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
On Thu, Feb 21, 2013 at 2:01 PM, Tyler Romeo tylerromeo@gmail.com wrote:
- 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.
Disclaimer: I am one of the QA people.
We are testing all the time, but there are just 3-4 of us, as far as I know. We are looking for help. As far as I know, there will be "Write your first Test Scenario in plain English" event[1] on the week of March 11, if you would like to help.
Feel free to add features/scenarios to the backlog[2] in the meantime. Let me know if you need help with that. (Test results for our browser automation project are available[3] to everybody, by the way). As an example, Siebrand provided a few features and scenarios[4] today and Chris and I have automated them[5][6]. (I have just noticed that the tests that we worked on today all failed because we make a mistake. It will be fixed probably on Monday.)
Ċ½eljko -- [1] http://www.mediawiki.org/wiki/QA/Weekly_goals [2] http://www.mediawiki.org/wiki/QA/Browser_testing/Test_backlog [3] https://wmf.ci.cloudbees.com/ [4] http://etherpad.wikimedia.org/i18n-qa [5] https://github.com/wikimedia/qa-browsertests/blob/master/features/accept_lan... [6] https://github.com/wikimedia/qa-browsertests/blob/master/features/universal_...
On Fri, Feb 22, 2013 at 9:32 PM, Ċ½eljko Filipin zfilipin@wikimedia.org wrote:
Feel free to add features/scenarios to the backlog[2] in the meantime. Let me know if you need help with that. (Test results for our browser automation project are available[3] to everybody, by the way).
[snip]
So, I've seen this site tossed around quite a bit recently, and I'm curious: is there any plan to start integrating this jenkins and our other jenkins? More importantly: is there any chance to get the results of these sorts of tests in Gerrit? I think it's great that we're expanding test coverage, but without feedback on people's patches they're usually unaware that they're breaking things.
-Chad
On 02/22/2013 09:38 PM, Chad wrote:
So, I've seen this site tossed around quite a bit recently, and I'm curious: is there any plan to start integrating this jenkins and our other jenkins? More importantly: is there any chance to get the results of these sorts of tests in Gerrit? I think it's great that we're expanding test coverage, but without feedback on people's patches they're usually unaware that they're breaking things.
I agree. I think our goal should be to have all the tests (QUnit, Cucumber, PHPUnit (generally already happens for this one)) result in Jenkins votes on Gerrit.
Matt Flaschen
Matthew Flaschen wrote:
On 02/22/2013 09:38 PM, Chad wrote:
So, I've seen this site tossed around quite a bit recently, and I'm curious: is there any plan to start integrating this jenkins and our other jenkins? More importantly: is there any chance to get the results of these sorts of tests in Gerrit? I think it's great that we're expanding test coverage, but without feedback on people's patches they're usually unaware that they're breaking things.
I agree. I think our goal should be to have all the tests (QUnit, Cucumber, PHPUnit (generally already happens for this one)) result in Jenkins votes on Gerrit.
Tangentially: I've been getting a lot of Gerrit e-mail (G-mail, if you will) from jenkins-bot lately. It can increase the noise from an action to a changeset from one e-mail to three or four in some cases, it seems like.
I nearly filed a bug in Bugzilla about this, but I figured I'd be told off for not simply using local mail filtering rules. And I can. But I'm wondering if there isn't a better way to disable e-mail from a particular user (an ignore feature in Gerrit, perhaps?). Or perhaps Gerrit can only send a jenkins-bot-related e-mail on failure (it currently seems to e-mail no matter what, I think). Any insight into this would be appreciated.
MZMcBride
On 22 February 2013 20:30, MZMcBride z@mzmcbride.com wrote:
Matthew Flaschen wrote:
On 02/22/2013 09:38 PM, Chad wrote:
So, I've seen this site tossed around quite a bit recently, and I'm curious: is there any plan to start integrating this jenkins and our other jenkins? More importantly: is there any chance to get the results of these sorts of tests in Gerrit? I think it's great that we're expanding test coverage, but without feedback on people's patches they're usually unaware that they're breaking things.
I agree. I think our goal should be to have all the tests (QUnit, Cucumber, PHPUnit (generally already happens for this one)) result in Jenkins votes on Gerrit.
Tangentially: I've been getting a lot of Gerrit e-mail (G-mail, if you will) from jenkins-bot lately. It can increase the noise from an action to a changeset from one e-mail to three or four in some cases, it seems like.
I nearly filed a bug in Bugzilla about this, but I figured I'd be told off for not simply using local mail filtering rules. And I can. But I'm wondering if there isn't a better way to disable e-mail from a particular user (an ignore feature in Gerrit, perhaps?). Or perhaps Gerrit can only send a jenkins-bot-related e-mail on failure (it currently seems to e-mail no matter what, I think). Any insight into this would be appreciated.
These e-mails mean something (well, some of them do, namely that you - you the submitter, you the merger/potential merger, or you the bystander that gets these e-mails anyway - screwed up and it's -1'ed for some reason). However, killing off the ones which add no data (the expected outcome is that everything's fine) would be nice.
Clearly we currently suppress e-mails for the internationalisation bot (even though some of us would actually like to get those), but yes being able to kill the valueless ones would be good; being able to switch them back on opt-in for jenkins, and for i18n-bot, might make sense.
J.
On Fri, Feb 22, 2013 at 11:30 PM, MZMcBride z@mzmcbride.com wrote:
Matthew Flaschen wrote:
On 02/22/2013 09:38 PM, Chad wrote:
So, I've seen this site tossed around quite a bit recently, and I'm curious: is there any plan to start integrating this jenkins and our other jenkins? More importantly: is there any chance to get the results of these sorts of tests in Gerrit? I think it's great that we're expanding test coverage, but without feedback on people's patches they're usually unaware that they're breaking things.
I agree. I think our goal should be to have all the tests (QUnit, Cucumber, PHPUnit (generally already happens for this one)) result in Jenkins votes on Gerrit.
Tangentially: I've been getting a lot of Gerrit e-mail (G-mail, if you will) from jenkins-bot lately. It can increase the noise from an action to a changeset from one e-mail to three or four in some cases, it seems like.
I nearly filed a bug in Bugzilla about this, but I figured I'd be told off for not simply using local mail filtering rules. And I can. But I'm wondering if there isn't a better way to disable e-mail from a particular user (an ignore feature in Gerrit, perhaps?). Or perhaps Gerrit can only send a jenkins-bot-related e-mail on failure (it currently seems to e-mail no matter what, I think). Any insight into this would be appreciated.
Not really possible. There's no way to filter e-mail sending based on its content. All we can do is disable e-mail sending per group (which is what we did for L10n-bot).
I know you probably don't want to hear it--but if you're wanting to filter Gerrit mail, the best option is to do it locally. That's really the main reason all the e-mails contain those Gerrit-* lines at the end--to enable easier filtering.
-Chad
On 2013-02-23 1:15 AM, "Chad" innocentkiller@gmail.com wrote:
On Fri, Feb 22, 2013 at 11:30 PM, MZMcBride z@mzmcbride.com wrote:
Matthew Flaschen wrote:
On 02/22/2013 09:38 PM, Chad wrote:
So, I've seen this site tossed around quite a bit recently, and I'm curious: is there any plan to start integrating this jenkins and our other jenkins? More importantly: is there any chance to get the results of these sorts of tests in Gerrit? I think it's great that we're expanding test coverage, but without feedback on people's patches they're usually unaware that they're breaking things.
I agree. I think our goal should be to have all the tests (QUnit, Cucumber, PHPUnit (generally already happens for this one)) result in Jenkins votes on Gerrit.
Tangentially: I've been getting a lot of Gerrit e-mail (G-mail, if you will) from jenkins-bot lately. It can increase the noise from an action
to
a changeset from one e-mail to three or four in some cases, it seems
like.
I nearly filed a bug in Bugzilla about this, but I figured I'd be told
off
for not simply using local mail filtering rules. And I can. But I'm wondering if there isn't a better way to disable e-mail from a
particular
user (an ignore feature in Gerrit, perhaps?). Or perhaps Gerrit can only send a jenkins-bot-related e-mail on failure (it currently seems to
no matter what, I think). Any insight into this would be appreciated.
Not really possible. There's no way to filter e-mail sending based on its content. All we can do is disable e-mail sending per group (which is what we did for L10n-bot).
I know you probably don't want to hear it--but if you're wanting to filter Gerrit mail, the best option is to do it locally. That's really the main reason all the e-mails contain those Gerrit-* lines at the end--to enable easier filtering.
-Chad
Could we make jenkins post with a different account depending on if the test results are positive or negative and then filter based on that?
-bawolff
On Sat, Feb 23, 2013 at 12:19 AM, Brian Wolff bawolff@gmail.com wrote:
On 2013-02-23 1:15 AM, "Chad" innocentkiller@gmail.com wrote:
On Fri, Feb 22, 2013 at 11:30 PM, MZMcBride z@mzmcbride.com wrote:
Matthew Flaschen wrote:
On 02/22/2013 09:38 PM, Chad wrote:
So, I've seen this site tossed around quite a bit recently, and I'm curious: is there any plan to start integrating this jenkins and our other jenkins? More importantly: is there any chance to get the results of these sorts of tests in Gerrit? I think it's great that we're expanding test coverage, but without feedback on people's patches they're usually unaware that they're breaking things.
I agree. I think our goal should be to have all the tests (QUnit, Cucumber, PHPUnit (generally already happens for this one)) result in Jenkins votes on Gerrit.
Tangentially: I've been getting a lot of Gerrit e-mail (G-mail, if you will) from jenkins-bot lately. It can increase the noise from an action
to
a changeset from one e-mail to three or four in some cases, it seems
like.
I nearly filed a bug in Bugzilla about this, but I figured I'd be told
off
for not simply using local mail filtering rules. And I can. But I'm wondering if there isn't a better way to disable e-mail from a
particular
user (an ignore feature in Gerrit, perhaps?). Or perhaps Gerrit can only send a jenkins-bot-related e-mail on failure (it currently seems to
no matter what, I think). Any insight into this would be appreciated.
Not really possible. There's no way to filter e-mail sending based on its content. All we can do is disable e-mail sending per group (which is what we did for L10n-bot).
I know you probably don't want to hear it--but if you're wanting to filter Gerrit mail, the best option is to do it locally. That's really the main reason all the e-mails contain those Gerrit-* lines at the end--to enable easier filtering.
-Chad
Could we make jenkins post with a different account depending on if the test results are positive or negative and then filter based on that?
But if we omit the e-mails from being sent, how will the people who want the e-mails get them?
-Chad
On 2013-02-23 1:24 AM, "Chad" innocentkiller@gmail.com wrote:
On Sat, Feb 23, 2013 at 12:19 AM, Brian Wolff bawolff@gmail.com wrote:
On 2013-02-23 1:15 AM, "Chad" innocentkiller@gmail.com wrote:
On Fri, Feb 22, 2013 at 11:30 PM, MZMcBride z@mzmcbride.com wrote:
Matthew Flaschen wrote:
On 02/22/2013 09:38 PM, Chad wrote:
So, I've seen this site tossed around quite a bit recently, and I'm curious: is there any plan to start integrating this jenkins and our other jenkins? More importantly: is there any chance to get the
results
of these sorts of tests in Gerrit? I think it's great that we're expanding test coverage, but without feedback on people's patches they're usually unaware that they're breaking things.
I agree. I think our goal should be to have all the tests (QUnit, Cucumber, PHPUnit (generally already happens for this one)) result in Jenkins votes on Gerrit.
Tangentially: I've been getting a lot of Gerrit e-mail (G-mail, if
you
will) from jenkins-bot lately. It can increase the noise from an
action
to
a changeset from one e-mail to three or four in some cases, it seems
like.
I nearly filed a bug in Bugzilla about this, but I figured I'd be
told
off
for not simply using local mail filtering rules. And I can. But I'm wondering if there isn't a better way to disable e-mail from a
particular
user (an ignore feature in Gerrit, perhaps?). Or perhaps Gerrit can
only
send a jenkins-bot-related e-mail on failure (it currently seems to
no matter what, I think). Any insight into this would be appreciated.
Not really possible. There's no way to filter e-mail sending based on its content. All we can do is disable e-mail sending per group (which is what we did for L10n-bot).
I know you probably don't want to hear it--but if you're wanting to filter Gerrit mail, the best option is to do it locally. That's really the main reason all the e-mails contain those Gerrit-* lines at the end--to enable easier filtering.
-Chad
Could we make jenkins post with a different account depending on if the test results are positive or negative and then filter based on that?
But if we omit the e-mails from being sent, how will the people who want the e-mails get them?
-Chad
I was assuming that no one wanted emails for the all unit tests passed situation.
-bawolff
On Sat, Feb 23, 2013 at 12:27 AM, Brian Wolff bawolff@gmail.com wrote:
On 2013-02-23 1:24 AM, "Chad" innocentkiller@gmail.com wrote:
On Sat, Feb 23, 2013 at 12:19 AM, Brian Wolff bawolff@gmail.com wrote:
On 2013-02-23 1:15 AM, "Chad" innocentkiller@gmail.com wrote:
On Fri, Feb 22, 2013 at 11:30 PM, MZMcBride z@mzmcbride.com wrote:
Matthew Flaschen wrote:
On 02/22/2013 09:38 PM, Chad wrote: >So, I've seen this site tossed around quite a bit recently, and I'm >curious: is there any plan to start integrating this jenkins and our >other jenkins? More importantly: is there any chance to get the
results
>of these sorts of tests in Gerrit? I think it's great that we're >expanding test coverage, but without feedback on people's patches >they're usually unaware that they're breaking things.
I agree. I think our goal should be to have all the tests (QUnit, Cucumber, PHPUnit (generally already happens for this one)) result in Jenkins votes on Gerrit.
Tangentially: I've been getting a lot of Gerrit e-mail (G-mail, if
you
will) from jenkins-bot lately. It can increase the noise from an
action
to
a changeset from one e-mail to three or four in some cases, it seems
like.
I nearly filed a bug in Bugzilla about this, but I figured I'd be
told
off
for not simply using local mail filtering rules. And I can. But I'm wondering if there isn't a better way to disable e-mail from a
particular
user (an ignore feature in Gerrit, perhaps?). Or perhaps Gerrit can
only
send a jenkins-bot-related e-mail on failure (it currently seems to
no matter what, I think). Any insight into this would be appreciated.
Not really possible. There's no way to filter e-mail sending based on its content. All we can do is disable e-mail sending per group (which is what we did for L10n-bot).
I know you probably don't want to hear it--but if you're wanting to filter Gerrit mail, the best option is to do it locally. That's really the main reason all the e-mails contain those Gerrit-* lines at the end--to enable easier filtering.
-Chad
Could we make jenkins post with a different account depending on if the test results are positive or negative and then filter based on that?
But if we omit the e-mails from being sent, how will the people who want the e-mails get them?
-Chad
I was assuming that no one wanted emails for the all unit tests passed situation.
Well, maybe I'm alone :\
-Chad
(anonymous) wrote:
[...]
I was assuming that no one wanted emails for the all unit tests passed situation.
Well, maybe I'm alone :\
No :-). It's nice to get positive feedback (and not have to wonder if ten minutes and no croaking means they passed, or better twenty minutes, etc.).
What I would like to see combined (and I think this is also MZMcBride's petitum) are the different "steps" Jenkins takes: A commit causes (depending on the status of the com- mitter) "Checked", "Verified", "Starting gate-and-submit jobs.", and "submitted this change and it was merged." mes- sages (and I'm not sure that these are all).
"Checked" and "Verified" (for trusted committers) should be one message, and "Starting gate-and-submit jobs." is proba- bly more adequate for a log file.
Tim
On Fri, Feb 22, 2013 at 7:06 PM, Matthew Flaschen mflaschen@wikimedia.orgwrote:
On 02/22/2013 09:38 PM, Chad wrote:
So, I've seen this site tossed around quite a bit recently, and I'm
curious:
is there any plan to start integrating this jenkins and our other
jenkins?
Depends on what you mean by "integrate". Right now the sweet spot for browser tests shown at https://wmf.ci.cloudbees.com/ is to track the deployment schedule over individual code commits and to target integrated institutional test environments like test2wiki and beta cluster, while https://integration.mediawiki.org/ci/ mostly targets unit-type tests run on the Jenkins host itself. There are a lot of builds there right now already.
In the longer term we want to have browser tests targeting more specialized test environments and more granular code commits. There are lots of ways that Jenkins instances can share data, so when that sort of activity comes along we'll figure out the details at that time.
More importantly: is there any chance to get the results of these sorts of
tests in Gerrit? I think it's great that we're expanding test coverage,
but
without feedback on people's patches they're usually unaware that they're breaking things.
As of today browser test status changes are being reported to #wikimedia-dev by a bot named "wmf-jenkins-bot", e.g.:
(09:30:18 AM) wmf-jenkins-bot-: Project _debug-irc build #17: SUCCESS in 90 ms: https://wmf.ci.cloudbees.com/job/_debug-irc/17/
Integration with Gerrit as well as Jenkins is certainly feasible, and as the information provided by these tests becomes more closely tied to the code itself rather than the environments in which the code is deployed, we can put that integration in place as it becomes valuable.
On Fri, Feb 22, 2013 at 6:38 PM, Chad innocentkiller@gmail.com wrote:
So, I've seen this site tossed around quite a bit recently, and I'm curious: is there any plan to start integrating this jenkins and our other jenkins?
Plans exist, but I am pretty sure there are no deadlines.
More importantly: is there any chance to get the results of these sorts of tests in Gerrit?
I am not a Jenkins ninja, so I am probably not the right person to answer.
Ċ½eljko
(anonymous) 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.
JFTR: AFAICS Jenkins is still not set up for MySQL :-) (cf. https://bugzilla.wikimedia.org/35912).
Tim
On Thu, Feb 21, 2013 at 7:19 AM, Mark A. Hershberger mah@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
On 02/21/2013 04:26 PM, Rob Lanphier wrote:
This all make sense?
Yes, I appreciate you weighing in.
Wonderful! So, now that we have a release manager for MediaWiki, is the release manager the person who writes/approves the policy for what sort of things are worth a 1.x.y release and how they're tracked on bugzilla, and will Chris be able to make and push tarballs for those even if they're not (only) security-related? Last news I have is that Chris was going to discuss said policy with RobLa (and maybe also Greg), but this looks superseded. I have a list of about a dozen (?) critical bugs in 1.20.2 that make me not so proud (and perhaps ashamed) of suggesting people to upgrade to it, at least for some use cases. Another thing that would be nice to have on https://www.mediawiki.org/wiki/Version_lifecycle or elsewhere is what are reasonable expectations about the stable releases. For instance, we know that 1.x.0 releases are always a nightmare: they're practically untested; branch point is pseudo-random and we have no info whatsoever about the bugs that MediaWiki (and extensions) had at any given revision. It would be nice to write somewhere that, say, 5 months after the 1.x.0 release came out, it's reasonable to think that most of its critical bugs/regressions are fixed in the last 1.x.y release; while of course 1.(x-1).* and 1.(x+1).* will have different bugs.
Nemo
On 22 February 2013 12:03, Federico Leva (Nemo) nemowiki@gmail.com wrote:
Another thing that would be nice to have onhttps://www.mediawiki.org/wiki/Version_lifecycle or elsewhere is what are reasonable expectations about the stable releases. For instance, we know that 1.x.0 releases are always a nightmare: they're practically untested; branch point is pseudo-random and we have no info whatsoever about the bugs that MediaWiki (and extensions) had at any given revision. It would be nice to write somewhere that, say, 5 months after the 1.x.0 release came out, it's reasonable to think that most of its critical bugs/regressions are fixed in the last 1.x.y release; while of course 1.(x-1).* and 1.(x+1).* will have different bugs.
Sounds LibreOffice-ish - they release a x.x.0 and schedule x.x.1 for a month after, with bug fixes, even if there's no security problems forcing a release.
- d.
On 02/22/2013 07:03 AM, Federico Leva (Nemo) wrote:
will Chris be able to make and push tarballs for those even if they're not (only) security-related?
I can make and push tarballs without involving Chris.
But yes, we need to discuss policy, and start setting expectations, etc.
Can we build off the conversation you've started? That is, can you drive this conversation?
Does anyone else have thoughts about Nemo's ideas for release expectations?
On Fri, Feb 22, 2013 at 8:24 AM, Mark A. Hershberger mah@everybody.org wrote:
On 02/22/2013 07:03 AM, Federico Leva (Nemo) wrote:
will Chris be able to make and push tarballs for those even if they're not (only) security-related?
I can make and push tarballs without involving Chris.
And further, I'm planning *not* to push tarballs unless they are security related (unless for some reason Mark needs me to help out on a particular release, which I'm always happy to do).
But yes, we need to discuss policy, and start setting expectations, etc.
Can we build off the conversation you've started? That is, can you drive this conversation?
Does anyone else have thoughts about Nemo's ideas for release expectations?
I don't have much to add, other than after the last security release, we've been planning to keep security and feature releases reasonably separate. This is so a user who only wants security patches doesn't have to find the security relevant parts of the patch. It also keeps changes to a minimum with security fixes, so it's less likely that an admin will need to revert the security fix if it breaks their install. But, this means more updates for users to install in general. Is that the preferred trade-off? Currently, all of our tools build the tarballs from the git REL branches, so keeping security releases entirely separate means we have to be more careful about what we push into that branch, to make sure it's always ready to have a release made if we need to do a security release.
On 2013-02-22 2:37 PM, "Chris Steipp" csteipp@wikimedia.org wrote:
On Fri, Feb 22, 2013 at 8:24 AM, Mark A. Hershberger mah@everybody.org
wrote:
On 02/22/2013 07:03 AM, Federico Leva (Nemo) wrote:
will Chris be able to make and push tarballs for those even if they're not (only) security-related?
I can make and push tarballs without involving Chris.
And further, I'm planning *not* to push tarballs unless they are security related (unless for some reason Mark needs me to help out on a particular release, which I'm always happy to do).
But yes, we need to discuss policy, and start setting expectations, etc.
Can we build off the conversation you've started? That is, can you drive this conversation?
Does anyone else have thoughts about Nemo's ideas for release
expectations?
I don't have much to add, other than after the last security release, we've been planning to keep security and feature releases reasonably separate. This is so a user who only wants security patches doesn't have to find the security relevant parts of the patch. It also keeps changes to a minimum with security fixes, so it's less likely that an admin will need to revert the security fix if it breaks their install. But, this means more updates for users to install in general. Is that the preferred trade-off? Currently, all of our tools build the tarballs from the git REL branches, so keeping security releases entirely separate means we have to be more careful about what we push into that branch, to make sure it's always ready to have a release made if we need to do a security release.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I still would like to see critical bug fixes in next point releases including security releases. For example I would like to see the fix for the bug where wfSuppressWarnings turns on warnings that werent previously enabled, in php 5.4, instead of turning off the warnings to be included in the next point release. (Since the breakage is quite significant imo)
I personally would also like to see up to date i18n files in every release regardless of type. Otherwise third parties will never see i18n fixes.
-bawolff
On 02/22/2013 01:46 PM, Brian Wolff wrote:
For example I would like to see the fix for the bug where wfSuppressWarnings turns on warnings that werent previously enabled, in php 5.4,
Where is this reported in Bugzilla? Since I'm not following Bz as closely as I was when I was Bugmeister, I don't know about this.
On Sat, 2013-02-23 at 13:41 -0500, Mark A. Hershberger wrote:
On 02/22/2013 01:46 PM, Brian Wolff wrote:
For example I would like to see the fix for the bug where wfSuppressWarnings turns on warnings that werent previously enabled, in php 5.4,
Where is this reported in Bugzilla?
https://bugzilla.wikimedia.org/show_bug.cgi?id=43594
andre
On Fri, 2013-02-22 at 11:24 -0500, Mark A. Hershberger wrote:
I can make and push tarballs without involving Chris.
But yes, we need to discuss policy, and start setting expectations, etc.
<tl;dr>: There's now a "Backport_to_Stable" dropdown in Bugzilla for backporting requests. Set it to "?" if you strongly feel that a fix should be backported.
Long version:
As a first step, I've set up a dropdown menu (a "flag" in Bugzilla terminology) called "Backport_to_Stable" for the Bugzilla products "MediaWiki" and "MediaWiki extensions" which can be seen in bug reports below the "Web browser" and "Mobile Platform" dropdown menus.
A backport request to a stable branch for an existing bugfix can be demanded by anybody who has "editbugs" permissions in Bugzilla (that's most of the users) by setting that flag to "?". Somebody can then either refuse the request by setting the flag to "-", or backport the bugfix and afterwards set the flag to "+". This is entirely independent from the status of the bug report.
As searching for flags is not trivial I have also shared saved queries for all three flag states. If interested, you can get these queries displayed in your Bugzilla sidebar under "Saved Searches" by going to https://bugzilla.wikimedia.org/userprefs.cgi?tab=saved-searches , searching for the three "Backport_Stable" queries, enabling the "Show in Footer" checkbox, and clicking the "Submit Changes" button at the bottom.
Obviously there are still several open policy questions to sort out, but we've got to start somewhere.
andre
On 03/11/2013 08:12 AM, Andre Klapper wrote:
On Fri, 2013-02-22 at 11:24 -0500, Mark A. Hershberger wrote:
But yes, we need to discuss policy, and start setting expectations, etc.
<tl;dr>: There's now a "Backport_to_Stable" dropdown in Bugzilla for backporting requests. Set it to "?" if you strongly feel that a fix should be backported.
Thank you for taking care of this, Andre.
wikitech-l@lists.wikimedia.org