Page MenuHomePhabricator
Create Task
Maniphest T40865

[DO NOT USE] Next wmf deployment (tracking) [superseded by #WMF-Server-Backports]
Closed, InvalidPublic
Actions

Description

MediaWiki bugs to be fixed for WMF deployment

Details

Reference
bz38865

Related Objects

Event Timeline

• bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:45 AM
• bzimport added projects: WMF-General-or-Unknown, Tracking-Neverending.
• bzimport set Reference to bz38865.
Reedy created this task.Jul 30 2012, 8:49 PM
Nemo_bis added a comment.Sep 15 2012, 5:50 AM

Note to tracking bug readers: don't take the summaries too literally, some (or most) of the tracked issues are actually handled after deployment; always check the server admin log and [[Special:Version]] carefully.

Krinkle added a comment.Sep 19 2012, 6:04 PM

Renaming this bug to be a generic "rolling tracking" bug for each wmf deployments.

This must not have any unresolved dependencies before a new wmf-branch is created and deployed. After deployments, dependencies can be purged. Using a tracking bug instead of a milestone so that it can work cross-product (Tasks for configuration in Wikimedia, bugs in MediaWiki core, stuff in extensions, VisualEditor etc.).

Krinkle added a comment.Sep 19 2012, 6:04 PM
  • Bug 39515 has been marked as a duplicate of this bug. ***
Krinkle added a comment.Sep 19 2012, 6:05 PM
  • Bug 36974 has been marked as a duplicate of this bug. ***
Krinkle added a comment.Sep 19 2012, 6:05 PM
  • Bug 36664 has been marked as a duplicate of this bug. ***
Krinkle added a comment.Sep 19 2012, 6:05 PM
  • Bug 36465 has been marked as a duplicate of this bug. ***
Krinkle added a comment.Sep 19 2012, 6:06 PM
  • Bug 36464 has been marked as a duplicate of this bug. ***
Krinkle added a comment.Sep 19 2012, 6:06 PM
  • Bug 29068 has been marked as a duplicate of this bug. ***
Krinkle added a comment.Sep 19 2012, 6:07 PM
  • Bug 38803 has been marked as a duplicate of this bug. ***
Krinkle added a comment.Sep 19 2012, 6:07 PM
  • Bug 37346 has been marked as a duplicate of this bug. ***
Krinkle added a comment.Sep 19 2012, 6:07 PM
  • Bug 39841 has been marked as a duplicate of this bug. ***
Nemo_bis added a comment.Sep 21 2012, 8:19 AM

(In reply to comment #2)

This must not have any unresolved dependencies before a new wmf-branch is
created and deployed.

Rob, just to know: is this an actual decision or just a generic hope?
1.20wmf12 has been deployed to all non-Wikipedia projects without resolving blockers. en.wiki is scheduled for Monday and it's completely unclear what's supposed to happen before and after such deployment.

matmarex added a comment.Sep 21 2012, 3:38 PM

Boldly adding bug 38158 as a blocker. (I hope I'm not doing anything wrong.)

Krinkle added a comment.Sep 21 2012, 4:17 PM

(In reply to comment #12)

(In reply to comment #2)

This must not have any unresolved dependencies before a new wmf-branch is
created and deployed.

Rob, just to know: is this an actual decision or just a generic hope?
1.20wmf12 has been deployed to all non-Wikipedia projects without resolving
blockers. en.wiki is scheduled for Monday and it's completely unclear what's
supposed to happen before and after such deployment.

I'm not sure that is a question, if it is that is a problem. Though we already knew that. Obviously we do have the principle of blocking bugs. The question is where they are listed (in this case on this bug), and secondly it is important that before deployment stuff here doesn't have loose ends.

We can't demand bugs to be fixed by just dumping them on this bug, what I think is a reasonable demand however is that there are no unresolved blockers at the deployment window. Meaning either they are fixed, or removed from the blocker list. But not ignored and let to rot, which is very frustrating but current practice (!).

From spending time in the office I know that's not the case they're not ignored. People do go over this blocker list and decide to either backport a fix, write a new patch or decide it is not important enough. The problem is that result is then not communicated back down to where it belongs: The bug itself and therewith the blocker list here.

It can happen that a decision is made that a bug is not blocking enough, but then it should simply be removed as blocker (with a rationale in the bug comment) and either:

  • assigned to a person to work on soon after deployment
  • or if not important right now and no person available as assignee, put on a milestone for later (e.g. 1.20 release)
  • or if no milestone, adjust the overall priority.
• Cmcmahon added a comment.Nov 28 2012, 6:47 PM

42512 blocks Nov 28 deployment to commons

• RobLa-WMF added a comment.Sep 4 2013, 3:54 PM

Greg, are we still using this tracking bug? If not, let's just close this.

matmarex added a comment.Oct 16 2013, 6:25 PM

(For reference, Greg and Reedy say that we do.)

greg added a comment.Oct 16 2013, 6:30 PM

(In reply to comment #16)

Greg, are we still using this tracking bug? If not, let's just close this.

Reedy is, and intends to, keep an eye on it. Andre and others are using it actively. I less so, but Andre usually beats me to the punch.

There's also the request for backport flag, which is being used (9 confirmed requests, last one sept 25th). Slight overlap, but not much, really (this one being for "things that should be done at next train start" and backport flags being for "this needs to happen now, now.").

Krinkle removed subtasks: T71566: Sporadic reports of users being served MW with no skins on 1.24wmf17, T73334: wgLogo missing on Login page, T71102: Special:PasswordReset locks out of account: "Incorrect password entered", T72827: [1.24wmf20] Fatal error: Call to a member function getProperty() on a non-object, after completely history merging a page, T71007: On login: Fatal exception of type PasswordError on 1.24wmf16, T67868: Modern and Cologne Blue should remain in Preferences/Appearance after removal from core, T64422: [Regresssion] "Watch this page" confirmation message is empty, T69420: Users experiencing "Script not responding" errors on 1.24wmf11 wikis – EventLogging triggering itself with deprecation warnings, T62710: multiversion/getMWVersion prints version line twice now, broken, T67704: Tab from Username no longer sends user to Password field, but instead to Search box, T67665: Revisions missing from mediawiki.org., T69243: jQuery UI 1.9.2 autocomplete makes triggers content vanishing in Chrome, Opera next, T72413: Special:Contributions on mediawiki.org shows inverse chronological order, T72412: LQT: [Regression 1.24wmf20] Pagination arrows have been moved, T67375: Pages lose their required ResourceLoader modules after being purged on 1.24wmf5, T73862: "There was an unexpected error logging in" when creating accounts on Beta, T63689: Fatal exception on Mediawiki.org, T63491: no WikiEditor edit controls on any page in beta labs, T53197: Migrate older campaign data model on commons to Campaign: namespace, T58140: Review and deploy MultimediaViewer extension, T58133: Review and deploy CommonsMetadata extension, T58115: Diff sizes on Special:Contributions are wrong, T61234: CSSMin: Embedded SVG icons are broken in Wikimedia production due to bad mime type, T58070: no search suggestions at all on test2wiki and mw.org, T62795: [Regression] Can no longer select the number of changes to show in Special:RecentChanges, T57779: Personal links and tabs are reversed in the Vector skin, T49482: RedisCategorySync doesn't work due to core change, T50928: Impossible to patrol new page with subsequent edit, T49279: redirect.php has gone AWOL, T55865: Review and deploy BetaFeatures extension, T50693: Gadget settings cannot be changed on Mediawiki 1.22wmf4, T50642: ULS enables IPA by default for English, T52196: In RTL languages, "history" and "add section" menu items moved into the hidden menu, T48941: Flagged revisions not properly marked, T48575: [Regression] mw.loader.addEmbeddedCSS throws cssText.indexOf is not a function, T51777: Wikidata related repo fragmentation, T48427: Error when moving a page with lua, T48397: Moving pages is completely broken in 1.21wmf12.Dec 3 2014, 12:28 AM

Cleared backlog of next-deployment changes that have since been processed.

Krinkle unsubscribed.Dec 3 2014, 12:30 AM
Krenair added a comment.Feb 14 2015, 3:09 AM

What are we going to do with this task now?

Nemo_bis added a subscriber: • mmodell.Mar 1 2015, 12:00 AM

What are we going to do with this task now?

Maybe Mukunda has opinions. :)

Aklapper mentioned this in T91251: Clarify MediaWiki and WMF Backporting requests process with regard to Phabricator tasks.Mar 2 2015, 1:28 PM
greg added a comment.Mar 27 2015, 7:26 PM
In T40865#1076036, @Nemo_bis wrote:

What are we going to do with this task now?

Maybe Mukunda has opinions. :)

@mmodell: how would you like to deal with "things (like config patches) people want to be included in the next train release".

There's already WMF-Server-Backports which we aren't using much at all yet.

greg reassigned this task from Reedy to • mmodell.Mar 27 2015, 7:26 PM
greg set Security to None.
greg updated the task description. (Show Details)
• mmodell added a comment.Mar 28 2015, 10:50 AM

@greg: By "next train release" do you mean the new branch that gets created on wednesday or any train deployment in general?

Glaisher subscribed.Mar 28 2015, 3:31 PM
PleaseStand added a parent task: T94369: Prevent JS breakage on cached pages that refer to _mwq.Mar 29 2015, 10:28 PM
greg added a comment.Mar 30 2015, 8:51 PM
In T40865#1159225, @mmodell wrote:

@greg: By "next train release" do you mean the new branch that gets created on wednesday or any train deployment in general?

The perpetual next release. This bug was used by Reedy to have a place to look for bugs to be pushed out with the train.

We now also have WMF-Server-Backports, which we should probably use in lieu of this tracking bug, which is what https://www.mediawiki.org/wiki/Backporting_fixes says anyway...

If that sounds ok with you (@mmodell) then let's just close this bug, bid it farewell and thank it for its use over the years...

• mmodell closed this task as Declined.Mar 31 2015, 1:04 AM

@greg: agreed, I prefer the project/tag over a tracking bug.

Nikerabbit mentioned this in T41480: [DO NOT USE] Issues affecting translatewiki.net [superseded by #affects-translatewiki.net].Apr 18 2015, 3:35 PM
Danny_B moved this task from Tag to Transition in progress on the Tracking-Neverending board.Jul 11 2016, 3:55 PM
Danny_B renamed this task from Next wmf deployment (tracking) to [DO NOT USE] Next wmf deployment (tracking) [superseded by #WMF-Server-Backports].Jul 16 2016, 2:42 AM
Danny_B changed the task status from Declined to Invalid.
Danny_B removed • mmodell as the assignee of this task.
Danny_B lowered the priority of this task from Medium to Lowest.
Danny_B removed parent tasks: T94369: Prevent JS breakage on cached pages that refer to _mwq, T4007: [DO NOT USE] Tracking bug [superseded by #Tracking].
Danny_B edited projects, added WMF-Server-Backports; removed WMF-General-or-Unknown.
Danny_B moved this task from Transition in progress to Transition completed / Archived on the Tracking-Neverending board.
Nemo_bis raised the priority of this task from Lowest to Medium.Jul 16 2016, 8:07 AM
Meno25 unsubscribed.Aug 28 2016, 8:10 AM
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL