Last modified: 2014-11-03 06:00:27 UTC
MediaWiki bugs to be fixed for WMF deployment
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.)
(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.").
