Last modified: 2014-10-09 14:17:40 UTC
Current extension repositories have REL1_23 branch, but it was created when REL1_22 was created too, so basically it's outdated. Examples: https://git.wikimedia.org/branches/mediawiki%2Fextensions%2FCite.git https://git.wikimedia.org/branches/mediawiki%2Fextensions%2FImageMap.git https://git.wikimedia.org/branches/mediawiki%2Fextensions%2FCheckUser.git They have REL1_23 updated as of 22-10-2013 I've only found one exception, though: https://git.wikimedia.org/branches/mediawiki%2Fextensions%2FWidgets.git One particular change introduced on 1.23 release was the migration from PHP to JSON files for i18n. I think all the extensions were migrated to JSON files in master, but REL1_23 still doesn't have that change.
While we're on it, could please whoever is in charge of releasing new MediaWiki versions, add also a note to check extension branches to the steps to create a new release? Every major release since we're on git have the same problem!! (usually REL1_XX branch is not created when the new release is done in core) See also bug 48837
I fixed ProofreadPage by having Chad enable force push, and pushing to update the remote REL1_23 branch. Why were the REL1_23 branches created at the branching point of REL1_22? :/
If you look at Auth_remoteuser (https://git.wikimedia.org/branches/mediawiki%2Fextensions%2FAuth_remoteuser.git), you'll see that REL1_21, REL1_22, and REL1_23 were all apparently branched when REL1_20 was created. From this I conclude that there were no changes on master between the time that REL1_20 was created and when REL1_23 was created. And the history seems to confirm this: https://git.wikimedia.org/log/mediawiki%2Fextensions%2FAuth_remoteuser.git/refs%2Fheads%2Fmaster That is, the dates you see on the branch page are the dates of the last commit on that branch, not when the branch was made. I created most of these REL1_23 branches last week.
(In reply to Mark A. Hershberger from comment #3) > That is, the dates you see on the branch page are the dates of the last > commit on that branch, not when the branch was made. > > I created most of these REL1_23 branches last week. That doesn't seem right. As I said in comment #0, a lot of extensions were changed to have i18n messages in JSON files instead of PHP, and that was done weeks before REL1_23 was branched on master (it's in REL1_23 in core). But REL1_23 on the extensions I've linked as example doesn't include this change, among others that were merged on master after October 2013. I've manually checked some of those extensions, downloading from git for that branch name and they aren't migrated, while if I switch to master they have the new JSON files.
(In reply to Jesús Martínez Novo (Ciencia Al Poder) from comment #0) > One particular change introduced on 1.23 release was the migration from PHP > to JSON files for i18n. I think all the extensions were migrated to JSON > files in master, but REL1_23 still doesn't have that change. Any extensions that have i18n files will need to be updated, but some, like Auth_remoteuser, are fine as is. Thank you for pointing out this problem before the release!
Like I say, ProofreadPage was massively out of date too. Now fixed though
It looks like some of the problem is confusion between gerrit and gitblit. For example, https://git.wikimedia.org/branches/mediawiki%2Fextensions%2FSemanticMediaWiki.git shows REL1_23 on 2013-10-24. A fresh checkout from gerrit, though, shows the last commit on REL1_23 to be 26923ba5d306b24afe3e8d71f3f065139fd593c6 on 2014-04-14. Hmmm, and part of what I'm running into here is caching. Opening the branch listing in a new browser shows what I expect. Another part of the problem is that I did initially make a mistake of branching the wrong code. When I discovered that I got a pointer from Chad on how to fix the problem. Evidently, though, this happened in more places than I realized.
Fixed those in comment #0, looking for more problems.
Fixed BlueSpiceFoundation
Wrote a script to remove the faulty REL1_23 branches (since I couldn't just push a new one). Should all be fixed now.
It looks like some extensions including SyntaxHighlight_GeSHi and SpamBlacklist were not fixed, and as a result the 1.22 versions of these two extensions are in the 1.23.0 tarball.
UploadWizard is also affected by this, and as a result it is completely broken on 1.23.
Greg / hexmode / Markus: Will anybody fix this? It's been open for two months and creates followup issues, confusion, brokenness (bug 66866).
Created attachment 15693 [details] Submodules under extensions w/o commits for 1.23 This file was generated by using an up-to-date extensions checkout (with updates submodules) and listing those submodules without any commit between 2014-04-10 (when REL1_23 was created) and 2013-10-10 (~when REL1_22 was created). This will help determine when REL1_22 should be the same as REL1_23.
Comment on attachment 15693 [details] Submodules under extensions w/o commits for 1.23 The following script was used to create this file: lines=`git log --oneline --before 2014-04-10 --after 2013-10-10 | wc -l` branch123=`git branch -a | grep origin/REL1_23 | wc -l` branch122=`git branch -a | grep origin/REL1_22 | wc -l` echo REL1_23: $branch123 REL1_22 $branch122 lines $lines if [ "$lines" -eq "0" -a "$rel123" == "$rel122" ]; then echo REL1_23 == REL1_22 for $ext echo $ext >> /tmp/122=123 fi
(Missed a couple of lines for the above script bit: rel123=`git log -1 --oneline origin/REL1_23 2>&1` rel122=`git log -1 --oneline origin/REL1_22 2>&1` ) UploadWizard was branched on 2014-Apr-14. Some bugs (bug #47161, bug #53245, bug #40147, bug #64908, bug #63921, bug #64067, bug #64883 and others below) were addressed with patches but no indication was made that a backport should be considered. After looking through the bugs with fixes for UW, I found the following three that seem like good candidates for backports: Bug #54750 - UploadWizard allows two different files with same name at same time Bug #64067 - Pg Support Bug #65406 - Flikr support Without more information, it is impossible to tell if fixing these will address comment #12: > UploadWizard is also affected by this, and as a result it is completely > broken on 1.23.
non-l10n changes in UploadWizard since it was branched: https://gerrit.wikimedia.org/r/#/q/status:merged+project:mediawiki/extensions/UploadWizard+branch:master+-owner:L10n-bot,n,z
Created attachment 15695 [details] differences between bundled version of spamblacklist in 1.22 and 1.23 I only see l10n diffs for the bundled versions of SpamBlacklist, but they aren't the same. $ git log -1 --pretty=format:"%h%x09%an%x09%ad" origin/REL1_23 d6bd4c1 Translation updater bot Thu Oct 24 20:50:16 2013 +0000 $ git log -1 --pretty=format:"%h%x09%an%x09%ad" origin/REL1_22 f91ad56 Translation updater bot Tue Oct 22 19:21:30 2013 +0000 So, year, not the right place for a branch, but not the same thing. No clue yet why this happened.
Extensions that look like they were branched on Oct 24: SolrStore REL1_23 5dabd1e Thu Oct 24 20:50:10 2013 +0000 SpamBlacklist REL1_23 d6bd4c1 Thu Oct 24 20:50:16 2013 +0000 SphinxSearch REL1_23 4a24249 Thu Oct 24 20:50:22 2013 +0000 SubPageList REL1_23 a68966d Thu Oct 24 20:50:26 2013 +0000 Sudo REL1_23 98bd893 Thu Oct 24 20:50:33 2013 +0000 SyntaxHighlight_GeSHi REL1_23 2f064f4 Thu Oct 24 05:51:03 2013 +0000 TemplateData REL1_23 26dacfc Thu Oct 24 20:50:37 2013 +0000 TemplateSandbox REL1_23 1e880cc Thu Oct 24 20:50:40 2013 +0000 Thanks REL1_23 22333e0 Thu Oct 24 20:50:46 2013 +0000 ThrottleOverride REL1_23 e122ac6 Thu Oct 24 20:50:50 2013 +0000 TimedMediaHandler REL1_23 7bd2b47 Thu Oct 24 20:50:54 2013 +0000 Translate REL1_23 dfee4f4 Thu Oct 24 20:51:04 2013 +0000 TranslateSvg REL1_23 5d30452 Thu Oct 24 20:51:11 2013 +0000 TranslationNotifications REL1_23 5537a12 Thu Oct 24 20:51:18 2013 +0000 TwnMainPage REL1_23 016ea86 Thu Oct 24 21:19:02 2013 +0000 TwoFactorAuthentication REL1_23 e2fb0cc Thu Oct 24 20:51:31 2013 +0000 UploadWizard REL1_23 9b39bd9 Thu Oct 24 20:51:37 2013 +0000 Validator REL1_23 3c3997a Thu Oct 24 20:51:44 2013 +0000
Number of extensions with last commit on REL1_23 that was in April and the message was "Localisation updates from http://translatewiki.net." or "Update i18n shim": 470 The extensions on comment #19 all had the last message "Localisation updates..." except for SyntaxHighight_GeSHi and TwnMainPage. Remaining extensions: BlueSpiceExtensions REL1_23 57ae783 Tue Apr 8 11:20:14 2014 +0200 Fix spelling: occurred CategoryTree REL1_23 c7333ea Fri Jun 6 11:44:02 2014 +0200 Register CategoryTreeMagic from global scope instead of setup Collection REL1_23 bf7c4b9 Thu Apr 24 20:52:39 2014 +0100 Fatal error: Unsupported operand types in Collection.body.php ConfirmAccount REL1_23 e4f00be Tue Apr 22 15:09:02 2014 +0000 Add support for request account link ConfirmEdit REL1_23 0c63352 Mon Apr 7 19:25:45 2014 +0200 SimpleCaptcha: Move the equals sign inside the <label/> DPLforum REL1_23 01211c5 Fri Jun 6 17:32:19 2014 +0300 Fix DPLforum b0rkage. DataTransfer REL1_23 24f7782 Tue Jun 17 14:00:56 2014 +0200 Fix incorrect path in $wgMessagesDirs Disambiguator REL1_23 cf11744 Fri May 9 19:04:52 2014 +0100 Fix table prefixing in SpecialDisambiguationPages Math REL1_23 d0e998f Wed Apr 16 19:39:10 2014 -0700 Simplify VE inspector code by extending new MWLiveExtensionInspector MobileFrontend REL1_23 984e276 Mon May 12 14:29:25 2014 -0700 Fix XSS in section handling Nuke REL1_23 ba618ff Thu Jun 5 14:17:17 2014 +0100 chmod -x Nuke.alias.php Nuke_body.php Nuke.hooks.php Nuke.i18n.php Nuke.php SpecialNuke.php NumberFormat REL1_23 70be63c Mon Jun 16 21:13:13 2014 +0600 fix bug with negative numbers (version 0.8.0) PagedTiffHandler REL1_23 1e2be08 Tue Apr 22 09:34:03 2014 +0200 mark method visibleMetadataFields as public ProofreadPage REL1_23 86fa295 Tue Apr 15 21:01:56 2014 +0200 Fills $params to recursive calls of preloadTransform VisualEditor REL1_23 82dc0cb Wed May 21 09:33:19 2014 -0700 [browser test] Dismiss new confirm dialog Wikibase REL1_23 d2ed0cc Mon Apr 14 21:13:23 2014 +0000 Merge "Add documentation for badgeItems setting on repo"
Looks like UW -- and others branched before April 22 -- would benefit from a bit of work. Others, like WikimediaMessages, suffer from the problem of d373fd87b17bfb67f6616011ec1faa2531e58878 -- where the committer "This, that and the other" made a commit indicating "Update for release of MW 1.23" without merging it with REL1_23 or requesting a backport.
(In reply to Mark A. Hershberger from comment #21) > Others, like WikimediaMessages, suffer from the problem of > d373fd87b17bfb67f6616011ec1faa2531e58878 -- where the committer "This, that > and the other" made a commit indicating "Update for release of MW 1.23" > without merging it with REL1_23 or requesting a backport. I don't think that patch needs to be backported, as the change is only relevant to mediawikiwiki, which is on 1.24wmfX by now. Since WikimediaMessages is a WMF-only extension I don't understand why it needs release branches in the first place.
(In reply to Mark A. Hershberger from comment #16) > After looking through the bugs with fixes for UW, I found the following > three that seem like good candidates for backports: > > Bug #54750 - UploadWizard allows two different files with same name at same > time > Bug #64067 - Pg Support > Bug #65406 - Flikr support Agreed, these are good candidates for backport. None of them are critical though. > Without more information, it is impossible to tell if fixing these will > address comment #12: > > UploadWizard is also affected by this, and as a result it is completely > > broken on 1.23. That would be addressed by moving all the missing commits (between 2013-10-24 and 2014-04-10) into REL1_23. Specifically, UW is broken because this commit from 2013 December is missing: http://git.wikimedia.org/commit/mediawiki%2Fextensions%2FUploadWizard/8bd13ac4317f48336f90a39723d142628eb906e9
The upload wizard case is fixed by https://gerrit.wikimedia.org/r/141586
*** Bug 67270 has been marked as a duplicate of this bug. ***
Fixed the ones in Comment 19. Emailed a couple of q's to developers about the right revision to use, but it should be fixed now.
Not sure, if this is a bug in the one-off update process, or something that is generally not handled when creating new versions of extensions, but the .gitreview file in the root extension folder should have defaultbranch=REL1_23 but it has defaultbranch=master instead. (I have run into this in MultimediaViewer and UploadWizard; I assume it's the same for all others.)
(In reply to Tisza Gergő from comment #27) > Not sure, if this is a bug in the one-off update process, or something that > is generally not handled when creating new versions of extensions, but the > .gitreview file in the root extension folder should have > defaultbranch=REL1_23 but it has defaultbranch=master instead. (I have run > into this in MultimediaViewer and UploadWizard; I assume it's the same for > all others.) This is something we should update our branching script to take care of.
(In reply to Mark A. Hershberger from comment #28) > (In reply to Tisza Gergő from comment #27) > > Not sure, if this is a bug in the one-off update process, or something that > > is generally not handled when creating new versions of extensions, but the > > .gitreview file in the root extension folder should have > > defaultbranch=REL1_23 but it has defaultbranch=master instead. (I have run > > into this in MultimediaViewer and UploadWizard; I assume it's the same for > > all others.) > > This is something we should update our branching script to take care of. Are you going to use this bug to track that or open a new one? Just don't want this to be lost in the aether...
hexmode: > Are you going to use this bug to track that or open a new one?
I'll use this one.
