Wikimedia's copy of MediaWiki has been updated to r51904 (r51864 for extensions). There were lots of fun bugs, the most exciting of which are now fixed.
Developers, please check the bug tracker for bugs reported against code that you maintain, or bugs that you can otherwise fix. Users, please report any bugs you notice there, after doing a search for duplicates, even if you also report them in other places such as IRC or [[WP:VPT]].
https://bugzilla.wikimedia.org/
Please do not discourage users from reporting "known issues", point them to the bug report so that they can give us a priority hint in a comment. It's hard to prioritise bug fixes when we don't know how many people are affected or how severe the issue is.
-- Tim Starling
On 6/15/09 7:30 AM, Tim Starling wrote:
Wikimedia's copy of MediaWiki has been updated to r51904 (r51864 for extensions). There were lots of fun bugs, the most exciting of which are now fixed.
Awesome, thanks Tim!
Developers, please check the bug tracker for bugs reported against code that you maintain, or bugs that you can otherwise fix. Users, please report any bugs you notice there, after doing a search for duplicates, even if you also report them in other places such as IRC or [[WP:VPT]].
https://bugzilla.wikimedia.org/
Please do not discourage users from reporting "known issues", point them to the bug report so that they can give us a priority hint in a comment. It's hard to prioritise bug fixes when we don't know how many people are affected or how severe the issue is.
*nod* We're all trying to make sure we use the bug tracker more effectively and keep up with both new and old issues. Don't be afraid to bug people, but always bug them _with_ the bug tracker so we can keep a "paper trail" of what's at issue and how it affects you!
-- brion
We always run the latest trunk and encounter few if any issues. The problems we do encounter usually involve extensions breaking.
I had implemented a policy of keeping up to date with Wikipedia using this cute bit of code:
svn update -r $(($(wget -q -O- http://en.wikipedia.org/wiki/Special:Version%7C grep pathrev | sed -r 's/.*pathrev=([0-9]{5,}).*/\1/')+10))
But WMF became so out of date that it became very problematic. What happens is that MediaWiki's newer code breaks an extension. The extension maker then fixes their extension which breaks backwards compatibility with previous versions of MediaWiki. But this means using a version of MediaWiki that has bugs. It really is kind of a nightmare trying to find a tradeoff between working versions of MediaWiki and working versions of your extensions and sometimes the only solution is to disable an extension until either it catches up or MediaWiki catches up.
Someday we will have a solution to this problem I hope..
On Mon, Jun 15, 2009 at 8:30 AM, Tim Starling tstarling@wikimedia.orgwrote:
Wikimedia's copy of MediaWiki has been updated to r51904 (r51864 for extensions). There were lots of fun bugs, the most exciting of which are now fixed.
Developers, please check the bug tracker for bugs reported against code that you maintain, or bugs that you can otherwise fix. Users, please report any bugs you notice there, after doing a search for duplicates, even if you also report them in other places such as IRC or [[WP:VPT]].
https://bugzilla.wikimedia.org/
Please do not discourage users from reporting "known issues", point them to the bug report so that they can give us a priority hint in a comment. It's hard to prioritise bug fixes when we don't know how many people are affected or how severe the issue is.
-- Tim Starling
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
And of course Special:Version code has changed since the last time I ran that code, meaning there is really no reliable way to know what version of MediaWiki Wikipedia is running anyway.
On Wed, Jun 17, 2009 at 10:44 AM, Brian Brian.Mingus@colorado.edu wrote:
We always run the latest trunk and encounter few if any issues. The problems we do encounter usually involve extensions breaking.
I had implemented a policy of keeping up to date with Wikipedia using this cute bit of code:
svn update -r $(($(wget -q -O- http://en.wikipedia.org/wiki/Special:Version | grep pathrev | sed -r 's/.*pathrev=([0-9]{5,}).*/\1/')+10))
But WMF became so out of date that it became very problematic. What happens is that MediaWiki's newer code breaks an extension. The extension maker then fixes their extension which breaks backwards compatibility with previous versions of MediaWiki. But this means using a version of MediaWiki that has bugs. It really is kind of a nightmare trying to find a tradeoff between working versions of MediaWiki and working versions of your extensions and sometimes the only solution is to disable an extension until either it catches up or MediaWiki catches up.
Someday we will have a solution to this problem I hope..
On Mon, Jun 15, 2009 at 8:30 AM, Tim Starling tstarling@wikimedia.orgwrote:
Wikimedia's copy of MediaWiki has been updated to r51904 (r51864 for extensions). There were lots of fun bugs, the most exciting of which are now fixed.
Developers, please check the bug tracker for bugs reported against code that you maintain, or bugs that you can otherwise fix. Users, please report any bugs you notice there, after doing a search for duplicates, even if you also report them in other places such as IRC or [[WP:VPT]].
https://bugzilla.wikimedia.org/
Please do not discourage users from reporting "known issues", point them to the bug report so that they can give us a priority hint in a comment. It's hard to prioritise bug fixes when we don't know how many people are affected or how severe the issue is.
-- Tim Starling
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
The new code for preferences management seems to have several issues. See: https://bugzilla.wikimedia.org/show_bug.cgi?id=19261 https://bugzilla.wikimedia.org/show_bug.cgi?id=19245
Another bug (the one cause of which I went to Bugzilla): The image size limit always gets reset to 320x240px cause the 'selected="selected"' misses (at least sometimes, I have not yet managed to recognize the pattern). Maybe other settings are affected too.
Perhaps the changes to the preferences interface should be reverted, cause this causes damage to the user's preferences. (Of course only if the bugs cannot be fixed quickly.)
Marcus Buck
On 17/06/2009, at 6:47 PM, Marcus Buck wrote:
The new code for preferences management seems to have several issues. See: https://bugzilla.wikimedia.org/show_bug.cgi?id=19261 https://bugzilla.wikimedia.org/show_bug.cgi?id=19245
Another bug (the one cause of which I went to Bugzilla): The image size limit always gets reset to 320x240px cause the 'selected="selected"' misses (at least sometimes, I have not yet managed to recognize the pattern). Maybe other settings are affected too.
Perhaps the changes to the preferences interface should be reverted, cause this causes damage to the user's preferences. (Of course only if the bugs cannot be fixed quickly.)
I had no idea.
If there are bugs with the preference system, they need to be brought to my attention by assigning them to me. Otherwise I have no idea about them.
For now, I'm going to add myself as a default CC for those bugs.
-- Andrew Garrett Contract Developer, Wikimedia Foundation agarrett@wikimedia.org http://werdn.us
On Wed, Jun 17, 2009 at 1:51 PM, Andrew Garrettagarrett@wikimedia.org wrote:
On 17/06/2009, at 6:47 PM, Marcus Buck wrote:
The new code for preferences management seems to have several issues. See: https://bugzilla.wikimedia.org/show_bug.cgi?id=19261 https://bugzilla.wikimedia.org/show_bug.cgi?id=19245
Another bug (the one cause of which I went to Bugzilla): The image size limit always gets reset to 320x240px cause the 'selected="selected"' misses (at least sometimes, I have not yet managed to recognize the pattern). Maybe other settings are affected too.
Perhaps the changes to the preferences interface should be reverted, cause this causes damage to the user's preferences. (Of course only if the bugs cannot be fixed quickly.)
I had no idea.
If there are bugs with the preference system, they need to be brought to my attention by assigning them to me. Otherwise I have no idea about them.
For now, I'm going to add myself as a default CC for those bugs.
-- Andrew Garrett Contract Developer, Wikimedia Foundation agarrett@wikimedia.org http://werdn.us
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Default CC for those bugs, or default CC for all Preferences bugs? It's been brought up before, but it would be nice if all components have a default assignee, rather than just wikibugs-l (keeping on default CC list, of course). Even if bugs end up getting reassigned, etc, at least we've got a default contact who got poked when the bug was submitted.
Brion: you mentioned a "Bugzilla Czar" before. Is this something one of us volunteer devs can take on?
-Chad
On 17/06/2009, at 6:56 PM, Chad wrote:
Default CC for those bugs, or default CC for all Preferences bugs? It's been brought up before, but it would be nice if all components have a default assignee, rather than just wikibugs-l (keeping on default CC list, of course). Even if bugs end up getting reassigned, etc, at least we've got a default contact who got poked when the bug was submitted.
Default CC for the Preferences component.
-- Andrew Garrett Contract Developer, Wikimedia Foundation agarrett@wikimedia.org http://werdn.us
On Wed, Jun 17, 2009 at 1:56 PM, Chad innocentkiller@gmail.com wrote:
(keeping on default CC list, of course)
As far as I know, this shouldn't be needed either. I believe wikibugs is setup to watch "all bug changes".
Casey Brown wrote:
On Wed, Jun 17, 2009 at 1:56 PM, Chad innocentkiller@gmail.com wrote:
(keeping on default CC list, of course)
As far as I know, this shouldn't be needed either. I believe wikibugs is setup to watch "all bug changes".
Yes. It isn't needed since bugzilla was updated to 3.0 (May 2007).
Brian wrote:
And of course Special:Version code has changed since the last time I ran that code, meaning there is really no reliable way to know what version of MediaWiki Wikipedia is running anyway.
Not long ago it was linked here a script by werdna to do that: http://www.mediawiki.org/wiki/Wikimedia_sync_script
It uses the API so the interface is stable.
Currently the revision number on Special:Version only shows the revision number we are currently check out-ed or updated by default. By customising the message "version-svn-revision" to include the $1 value to show the revision number which was last modified. That I was intended to be done before.
-------------------------------------------------- From: "Brian" Brian.Mingus@colorado.edu Sent: Thursday, June 18, 2009 12:47 AM To: "Wikimedia developers" wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] Code updated
And of course Special:Version code has changed since the last time I ran that code, meaning there is really no reliable way to know what version of MediaWiki Wikipedia is running anyway.
On Wed, Jun 17, 2009 at 10:44 AM, Brian Brian.Mingus@colorado.edu wrote:
We always run the latest trunk and encounter few if any issues. The problems we do encounter usually involve extensions breaking.
I had implemented a policy of keeping up to date with Wikipedia using this cute bit of code:
svn update -r $(($(wget -q -O- http://en.wikipedia.org/wiki/Special:Version | grep pathrev | sed -r 's/.*pathrev=([0-9]{5,}).*/\1/')+10))
But WMF became so out of date that it became very problematic. What happens is that MediaWiki's newer code breaks an extension. The extension maker then fixes their extension which breaks backwards compatibility with previous versions of MediaWiki. But this means using a version of MediaWiki that has bugs. It really is kind of a nightmare trying to find a tradeoff between working versions of MediaWiki and working versions of your extensions and sometimes the only solution is to disable an extension until either it catches up or MediaWiki catches up.
Someday we will have a solution to this problem I hope..
On Mon, Jun 15, 2009 at 8:30 AM, Tim Starling tstarling@wikimedia.orgwrote:
Wikimedia's copy of MediaWiki has been updated to r51904 (r51864 for extensions). There were lots of fun bugs, the most exciting of which are now fixed.
Developers, please check the bug tracker for bugs reported against code that you maintain, or bugs that you can otherwise fix. Users, please report any bugs you notice there, after doing a search for duplicates, even if you also report them in other places such as IRC or [[WP:VPT]].
https://bugzilla.wikimedia.org/
Please do not discourage users from reporting "known issues", point them to the bug report so that they can give us a priority hint in a comment. It's hard to prioritise bug fixes when we don't know how many people are affected or how severe the issue is.
-- Tim Starling
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Brian <Brian.Mingus <at> colorado.edu> writes:
And of course Special:Version code has changed since the last time I ran that code, meaning there is really no reliable way to know what version of MediaWiki Wikipedia is running anyway.
You can get http://en.wikipedia.org/w/api.php?action=query&meta=siteinfo&format=... and look for /\brev="(\d)"/. A separate SVN branch for the version used on live Wikimedia wikis would be a great improvement, though.
Yes - this would be fantastic. It just needs to be a cheap copy which is essentially zero overhead on WMFs part. A 'live' tag for example.
On Thu, Jun 18, 2009 at 1:59 AM, Tisza Gergő gtisza@gmail.com wrote:
Brian <Brian.Mingus <at> colorado.edu> writes:
And of course Special:Version code has changed since the last time I ran that code, meaning there is really no reliable way to know what version
of
MediaWiki Wikipedia is running anyway.
You can get http://en.wikipedia.org/w/api.php?action=query&meta=siteinfo&format=... look for /\brev="(\d)"/. A separate SVN branch for the version used on live Wikimedia wikis would be a great improvement, though.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Brian <Brian.Mingus <at> colorado.edu> writes:
On Thu, Jun 18, 2009 at 1:59 AM, Tisza Gergő <gtisza <at> gmail.com> wrote:
Brian <Brian.Mingus <at> colorado.edu> writes:
And of course Special:Version code has changed since the last time I ran that code, meaning there is really no reliable way to know what version of MediaWiki Wikipedia is running anyway.
You can get http://en.wikipedia.org/w/api.php?action=query&meta=siteinfo&format=... and look for /\brev="(\d)"/. A separate SVN branch for the version used on live Wikimedia wikis would be a great improvement, though.
Yes - this would be fantastic. It just needs to be a cheap copy which is essentially zero overhead on WMFs part. A 'live' tag for example.
I tried to suggest that a few weeks ago, but couldn't create much interest: http://www.nabble.com/Live-SVN-branch-td23636464.html
If done properly, it would be probably more difficult than a simple copy of a certain version, but it would also be much more useful. For example, Tim updated SpecialUserrights.php to r52116 just a few minutes ago to fix a bug which stopped it from working, but you wouldn't know that from looking at Special:Version.
Tisza Gergő wrote:
I tried to suggest that a few weeks ago, but couldn't create much interest: http://www.nabble.com/Live-SVN-branch-td23636464.html
If done properly, it would be probably more difficult than a simple copy of a certain version, but it would also be much more useful. For example, Tim updated SpecialUserrights.php to r52116 just a few minutes ago to fix a bug which stopped it from working, but you wouldn't know that from looking at Special:Version.
It can't be that hard to setup a method to clone so. Supposing that internally it's just a couple of vars referring to the revisions for core and extensions, they could be exposed on noc.
How's that really done at Wikimedia? Do devs manually svn up the folders/files they want? Is that also versioned (for live hacks)? I know that some internal files are stored in bazaar, but know nothing about how scap internals. :)
On Thu, Jun 18, 2009 at 4:40 PM, Tisza Gergőgtisza@gmail.com wrote:
Brian <Brian.Mingus <at> colorado.edu> writes:
On Thu, Jun 18, 2009 at 1:59 AM, Tisza Gergő <gtisza <at> gmail.com> wrote:
Brian <Brian.Mingus <at> colorado.edu> writes:
And of course Special:Version code has changed since the last time I ran that code, meaning there is really no reliable way to know what version of MediaWiki Wikipedia is running anyway.
You can get http://en.wikipedia.org/w/api.php?action=query&meta=siteinfo&format=... and look for /\brev="(\d)"/. A separate SVN branch for the version used on live Wikimedia wikis would be a great improvement, though.
Yes - this would be fantastic. It just needs to be a cheap copy which is essentially zero overhead on WMFs part. A 'live' tag for example.
I tried to suggest that a few weeks ago, but couldn't create much interest: http://www.nabble.com/Live-SVN-branch-td23636464.html
If done properly, it would be probably more difficult than a simple copy of a certain version, but it would also be much more useful. For example, Tim updated SpecialUserrights.php to r52116 just a few minutes ago to fix a bug which stopped it from working, but you wouldn't know that from looking at Special:Version.
The simplest way would be to have the output of svn status -v on a public place along with svn diff (for live hacks). This could probably be easily incorporated in the script that is used for syncing.
Bryan Tong Minh wrote:
The simplest way would be to have the output of svn status -v on a public place along with svn diff (for live hacks). This could probably be easily incorporated in the script that is used for syncing.
Live hacks are strongly discouraged; the source should always be totally clean on a 'svn diff' though in practice there's usually something little here and there.
Individual high-priority fixes or new extensions being fixed up for deployment are often svn up'd or svn merge'd in temporarily before the next full update, though it's not an ideal practice.
But since there aren't *supposed* to be any differences between development trunk and deployment, maintaining a deployment branch seems like it could be a bit awkward... but might be better than pretending. :)
-- brion
wikitech-l@lists.wikimedia.org