Last week, I announced the MediaWiki 1.20 release candidate that I created on wikitech-l (http://lists.wikimedia.org/pipermail/wikitech-l/2012-September/063226.html shortened: http://hexm.de/lo).
A few people have downloaded it and, so far, I don't know of any problem reports, but maybe that is because the people on wikitech-l are already using newer versions MediaWiki.
Today I'd like to get more people looking at it, so I'm announcing it on mediawiki-l and mwusers.com.
Download: http://mah.everybody.org/mediawiki-1.20.0beta0.tar.gz
Release Notes: https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob_plain;f=RE... shortened: http://hexm.de/ln
GPG signatures: http://mah.everybody.org/mediawiki-1.20.0beta0.tar.gz.sig
Public key: http://mah.everybody.org/contact-info http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x7956EE477F901A30
(If there there is anyone with a PGP key in the Philadelphia/New York City area who can sign my key, let me know. I have to get some more signatures.)
On 21 September 2012 05:37, Mark A. Hershberger mah@everybody.org wrote:
Last week, I announced the MediaWiki 1.20 release candidate that I created on wikitech-l (http://lists.wikimedia.org/pipermail/wikitech-l/2012-September/063226.html shortened: http://hexm.de/lo).
Earlier you wrote that it is based on 1.20wmf11 branch. I didn't check the tarball but there were pretty severe i18n issues with plurals around that time. Do you know whether fixes for those issues are already included or not? Most important is https://gerrit.wikimedia.org/r/#/c/23900/ -Niklas
On 09/21/2012 03:57 AM, Niklas Laxström wrote:
Earlier you wrote that it is based on 1.20wmf11 branch. I didn't check the tarball but there were pretty severe i18n issues with plurals around that time. Do you know whether fixes for those issues are already included or not? Most important is https://gerrit.wikimedia.org/r/#/c/23900/
That commit is not included. I can merge it in or make a second RC with 1.20wmf12.
What do you think is the better way to go?
On Sep 21, 2012, at 4:13 PM, Mark A. Hershberger mah@everybody.org wrote:
On 09/21/2012 03:57 AM, Niklas Laxström wrote:
Earlier you wrote that it is based on 1.20wmf11 branch. I didn't check the tarball but there were pretty severe i18n issues with plurals around that time. Do you know whether fixes for those issues are already included or not? Most important is https://gerrit.wikimedia.org/r/#/c/23900/
That commit is not included. I can merge it in or make a second RC with 1.20wmf12.
What do you think is the better way to go?
I'd say re-branch from master.
-- Krinkle
On 09/22/2012 02:50 PM, Krinkle wrote:
On Sep 21, 2012, at 4:13 PM, Mark A. Hershberger mah@everybody.org wrote:
That commit is not included. I can merge it in or make a second RC with 1.20wmf12.
What do you think is the better way to go?
I'd say re-branch from master.
My thinking was to branch from a point that was known -- something whose issues we knew. I think this worked pretty well.
For instance, the issue Niklas raised was because I used a WMF branch.
I'm now thinking that I'll just stick with the 1.20wmf12 and just apply the patch he pointed to. This is in the vein of sticking to known issues.
What do you think?
Mark.
On Sep 22, 2012, at 10:54 PM, Mark A. Hershberger mah@everybody.org wrote:
On 09/22/2012 02:50 PM, Krinkle wrote:
On Sep 21, 2012, at 4:13 PM, Mark A. Hershberger mah@everybody.org wrote:
That commit is not included. I can merge it in or make a second RC with 1.20wmf12.
What do you think is the better way to go?
I'd say re-branch from master.
My thinking was to branch from a point that was known -- something whose issues we knew. I think this worked pretty well.
For instance, the issue Niklas raised was because I used a WMF branch.
I'm now thinking that I'll just stick with the 1.20wmf12 and just apply the patch he pointed to. This is in the vein of sticking to known issues.
What do you think?
Mark.
I think master is more stable then whatever wmf branch. I know because of commits recently merged and whatnot.
If there are problems we'll find them in the release candidate period. And by that time we'll have had a new wmf branch as well to see how the latest code performs on wmf.
Also, this bugzilla query should be empty before release as well (either by fixing bugs, or reviewing/merging pending commits that claim to fix stuff, or deferring the bug to a later release etc.). People assign and block things usually for a reason:
https://bugzilla.wikimedia.org/buglist.cgi?query_format=advanced&target_...
-- Krinkle
On 09/23/2012 12:54 PM, Krinkle wrote:
I think master is more stable then whatever wmf branch. I know because of commits recently merged and whatnot.
This feels like a strange statement to me. I'm willing to believe that bugs found in the WMF branch have been fixed on master, but it seems obvious that new bugs would also have been introduced.
Still, the pre-merge review + rapid release cycle would probably make master more stable than it was for other releases.
If there are problems we'll find them in the release candidate period. And by that time we'll have had a new wmf branch as well to see how the latest code performs on wmf.
Good point.
Also, this bugzilla query should be empty before release as well (either by fixing bugs, or reviewing/merging pending commits that claim to fix stuff, or deferring the bug to a later release etc.). People assign and block things usually for a reason:
Link shortened: http://hexm.de/lp
This is a very good point.
I think the thing to do is to make a new RC from master (as you suggest) and organize a triage of 1.20 bugs.
I'll also put a comment on all those bugs inviting people to participate in the triage so that we have a way to gauge interest and have people test them against the beta cluster (or a 1.20 installation on labs).
I can hold a triage for blockers at UTC1100 on Tue, October 2 (http://hexm.de/lr). At this point, there are over 100 non-enhancment bugs marked for 1.20. Please help trim the list before then.
Mark.
On Mon, Sep 24, 2012 at 4:03 AM, Mark A. Hershberger mah@everybody.org wrote:
On 09/23/2012 12:54 PM, Krinkle wrote:
Link shortened: http://hexm.de/lp
There is no need to shorten urls in emails, Please don't.
On 09/23/2012 06:33 PM, K. Peachey wrote:
On Mon, Sep 24, 2012 at 4:03 AM, Mark A. Hershberger mah@everybody.org wrote:
On 09/23/2012 12:54 PM, Krinkle wrote:
Link shortened: http://hexm.de/lp
There is no need to shorten urls in emails, Please don't.
I've personally seen mail readers and MTAs that mangle long URLs. Since this sort of mangling happens, I see a need for a way to make URLs usable. I use a shortener for those URLS as a precautionary measure and to help me communicate with others.
Mark.
On Sep 23, 2012, at 8:03 PM, Mark A. Hershberger mah@everybody.org wrote:
On 09/23/2012 12:54 PM, Krinkle wrote:
Also, this bugzilla query should be empty before release as well (either by fixing bugs, or reviewing/merging pending commits that claim to fix stuff, or deferring the bug to a later release etc.). People assign and block things usually for a reason:
https://bugzilla.wikimedia.org/buglist.cgi?query_format=advanced&target_...
[..]
I can hold a triage for blockers at UTC1100 on Tue, October 2 (http://hexm.de/lr). At this point, there are over 100 non-enhancment bugs marked for 1.20. Please help trim the list before then.
Actually, there are ~ 65 (as my link reflected), the shortened link forgot to exclude resolved bugs.
-- Krinkle
On 09/25/2012 09:40 AM, Krinkle wrote:
On Sep 23, 2012, at 8:03 PM, Mark A. Hershberger mah@everybody.org wrote:
On 09/23/2012 12:54 PM, Krinkle wrote:
https://bugzilla.wikimedia.org/buglist.cgi?query_format=advanced&target_...
I can hold a triage for blockers at UTC1100 on Tue, October 2 (http://hexm.de/lr). At this point, there are over 100 non-enhancment bugs marked for 1.20. Please help trim the list before then.
Actually, there are ~ 65 (as my link reflected), the shortened link forgot to exclude resolved bugs.
Thanks for pointing this out, this is a perfect example of link mangling by a mail reader.
When I click on your url, Thunderbird does not include the ending "---" and I see 155 bugs. I didn't realize this was happening until now.
Screenshot of the bug in Thunderbird: http://mah.everybody.org/image/tbird-url-bug.png
Mark
Krinkle <krinklemail <at> gmail.com> writes:
On Sep 22, 2012, at 10:54 PM, Mark A. Hershberger <mah <at> everybody.org>
wrote:
On 09/22/2012 02:50 PM, Krinkle wrote:
On Sep 21, 2012, at 4:13 PM, Mark A. Hershberger <mah <at> everybody.org>
wrote:
That commit is not included. I can merge it in or make a second RC with 1.20wmf12.
What do you think is the better way to go?
I'd say re-branch from master.
My thinking was to branch from a point that was known -- something whose issues we knew. I think this worked pretty well.
For instance, the issue Niklas raised was because I used a WMF branch.
I'm now thinking that I'll just stick with the 1.20wmf12 and just apply the patch he pointed to. This is in the vein of sticking to known issues.
What do you think?
Mark.
I think master is more stable then whatever wmf branch. I know because of
commits
recently merged and whatnot.
If there are problems we'll find them in the release candidate period. And by that time we'll have had a new wmf branch as well to see how the latest
code
performs on wmf.
Also, this bugzilla query should be empty before release as well (either by
fixing bugs,
or reviewing/merging pending commits that claim to fix stuff, or deferring the
bug to
a later release etc.). People assign and block things usually for a reason:
query_format=advanced&target_milestone=1.20.0%20release&product=MediaWiki&resolu tion=---
Those reasons for using master can be used in the counter argument. The counter argument has the fact that we've been using said branch in production for upto 2 weeks - we know it works (mostly).
Yes, master will have had numerous bugfixes brought into it, but there are also likely "new features" and other bugs introduced.
I think using a branch (though, not specifically the WMF branches "as is", due to WMF specific modifications. They want reverting out. Same goes for we don't want any of the extension update to master commits) is the best idea. Branching a REL1_20 branch from say the point that 1.20wmf12 branched, and then also backporting any relevant fixes from master makes sense. Pretty much how we did it for SVN, hopefully without the months and months of merging hell.
If we create a REL1_20 release branch now, we should then go through the usual process of bumping $wgVersion, creating RELEASE-NOTES-1.21 and new WMF branches can go back to wmf1 etc as a prefix.
Sam
On Wed, Sep 26, 2012 at 3:24 PM, Sam Reed reedy@wikimedia.org wrote:
Krinkle <krinklemail <at> gmail.com> writes:
On Sep 22, 2012, at 10:54 PM, Mark A. Hershberger <mah <at> everybody.org>
wrote:
On 09/22/2012 02:50 PM, Krinkle wrote:
On Sep 21, 2012, at 4:13 PM, Mark A. Hershberger <mah <at> everybody.org>
wrote:
That commit is not included. I can merge it in or make a second RC with 1.20wmf12.
What do you think is the better way to go?
I'd say re-branch from master.
My thinking was to branch from a point that was known -- something whose issues we knew. I think this worked pretty well.
For instance, the issue Niklas raised was because I used a WMF branch.
I'm now thinking that I'll just stick with the 1.20wmf12 and just apply the patch he pointed to. This is in the vein of sticking to known issues.
What do you think?
Mark.
I think master is more stable then whatever wmf branch. I know because of
commits
recently merged and whatnot.
If there are problems we'll find them in the release candidate period. And by that time we'll have had a new wmf branch as well to see how the latest
code
performs on wmf.
Also, this bugzilla query should be empty before release as well (either by
fixing bugs,
or reviewing/merging pending commits that claim to fix stuff, or deferring the
bug to
a later release etc.). People assign and block things usually for a reason:
query_format=advanced&target_milestone=1.20.0%20release&product=MediaWiki&resolu tion=---
Those reasons for using master can be used in the counter argument. The counter argument has the fact that we've been using said branch in production for upto 2 weeks - we know it works (mostly).
Yes, master will have had numerous bugfixes brought into it, but there are also likely "new features" and other bugs introduced.
I think using a branch (though, not specifically the WMF branches "as is", due to WMF specific modifications. They want reverting out. Same goes for we don't want any of the extension update to master commits) is the best idea. Branching a REL1_20 branch from say the point that 1.20wmf12 branched, and then also backporting any relevant fixes from master makes sense. Pretty much how we did it for SVN, hopefully without the months and months of merging hell.
If we create a REL1_20 release branch now, we should then go through the usual process of bumping $wgVersion, creating RELEASE-NOTES-1.21 and new WMF branches can go back to wmf1 etc as a prefix.
I agree with Sam on all counts here (and actually suggested this as well). Since we're getting ready to land ContentHandler, it would be nice to have this branched before that happens. That way 1.20 can remain stable and be near a release.... ContentHandler will just be the first big thing to land in 1.21 :)
-Chad
On 09/26/2012 03:24 PM, Sam Reed wrote:
Branching a REL1_20 branch from say the point that 1.20wmf12 branched, and then also backporting any relevant fixes from master makes sense. Pretty much how we did it for SVN, hopefully without the months and months of merging hell.
Sam emailed me about this -- I missed it yesterday -- and I agree whole-heartedly.
Let's get this done.
There are still some 60 bugs marked for the 1.20.0 release and I'd like to have them cleared out before we make a final release. If you can poke at the list, please do.
I'll put a notice for the next Tuesday's 1.20.0 triage as a comment on any remaining bugs this weekend to give interested people a chance to comment, so *now* is the time to clear any that obviously do not belong.
For the bugs with the 1.20.0 milestone, see http://hexm.de/lt or https://bugzilla.wikimedia.org/buglist.cgi?query_format=advanced&target_...
Mark.
wikitech-l@lists.wikimedia.org