Page MenuHomePhabricator

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

Description

MediaWiki bugs to be fixed for WMF deployment

Details

Reference
bz38865

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 22 2014, 12:45 AM
bzimport set Reference to bz38865.
Reedy created this task.Jul 30 2012, 8:49 PM

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.

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.).

  • Bug 39515 has been marked as a duplicate of this bug. ***
  • Bug 36974 has been marked as a duplicate of this bug. ***
  • Bug 36664 has been marked as a duplicate of this bug. ***
  • Bug 36465 has been marked as a duplicate of this bug. ***
  • Bug 36464 has been marked as a duplicate of this bug. ***
  • Bug 29068 has been marked as a duplicate of this bug. ***
  • Bug 38803 has been marked as a duplicate of this bug. ***
  • Bug 37346 has been marked as a duplicate of this bug. ***
  • Bug 39841 has been marked as a duplicate of this bug. ***

(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.

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

(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.

42512 blocks Nov 28 deployment to commons

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

(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 removed a subscriber: Krinkle.Dec 3 2014, 12:30 AM

What are we going to do with this task now?

What are we going to do with this task now?

Maybe Mukunda has opinions. :)

greg added a comment.Mar 27 2015, 7:26 PM

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)

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

greg added a comment.Mar 30 2015, 8:51 PM

@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.

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 Normal to Lowest.
Nemo_bis raised the priority of this task from Lowest to Normal.Jul 16 2016, 8:07 AM
Meno25 removed a subscriber: Meno25.Aug 28 2016, 8:10 AM