Last modified: 2014-11-03 06:00:27 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 38865 - (wmf-deployment) Next wmf deployment (tracking)
(wmf-deployment)
Next wmf deployment (tracking)
Status: NEW
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Sam Reed (reedy)
: tracking
: 29068 36464 36465 36664 36974 37346 38803 39515 39841 (view as bug list)
Depends on: 46397 46427 46575 46941 47279 47482 48642 48693 48928 49777 50196 51197 53865 55779 56070 56115 56133 56140 59234 60710 60795 61491 61689 62422 65375 65665 65704 65868 67243 67420 69007 69102 69566 70412 70413 70827 71334 71862
Blocks: tracking
  Show dependency treegraph
 
Reported: 2012-07-30 20:49 UTC by Sam Reed (reedy)
Modified: 2014-11-03 06:00 UTC (History)
11 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Sam Reed (reedy) 2012-07-30 20:49:57 UTC
MediaWiki bugs to be fixed for WMF deployment
Comment 1 Nemo 2012-09-15 05:50:50 UTC
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.
Comment 2 Krinkle 2012-09-19 18:04:21 UTC
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.).
Comment 3 Krinkle 2012-09-19 18:04:41 UTC
*** Bug 39515 has been marked as a duplicate of this bug. ***
Comment 4 Krinkle 2012-09-19 18:05:21 UTC
*** Bug 36974 has been marked as a duplicate of this bug. ***
Comment 5 Krinkle 2012-09-19 18:05:39 UTC
*** Bug 36664 has been marked as a duplicate of this bug. ***
Comment 6 Krinkle 2012-09-19 18:05:49 UTC
*** Bug 36465 has been marked as a duplicate of this bug. ***
Comment 7 Krinkle 2012-09-19 18:06:00 UTC
*** Bug 36464 has been marked as a duplicate of this bug. ***
Comment 8 Krinkle 2012-09-19 18:06:08 UTC
*** Bug 29068 has been marked as a duplicate of this bug. ***
Comment 9 Krinkle 2012-09-19 18:07:04 UTC
*** Bug 38803 has been marked as a duplicate of this bug. ***
Comment 10 Krinkle 2012-09-19 18:07:13 UTC
*** Bug 37346 has been marked as a duplicate of this bug. ***
Comment 11 Krinkle 2012-09-19 18:07:38 UTC
*** Bug 39841 has been marked as a duplicate of this bug. ***
Comment 12 Nemo 2012-09-21 08:19:07 UTC
(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.
Comment 13 Bartosz Dziewoński 2012-09-21 15:38:22 UTC
Boldly adding bug 38158 as a blocker. (I hope I'm not doing anything wrong.)
Comment 14 Krinkle 2012-09-21 16:17:42 UTC
(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.
Comment 15 Chris McMahon 2012-11-28 18:47:33 UTC
42512 blocks Nov 28 deployment to commons
Comment 16 Rob Lanphier 2013-09-04 15:54:31 UTC
Greg, are we still using this tracking bug?  If not, let's just close this.
Comment 17 Bartosz Dziewoński 2013-10-16 18:25:40 UTC
(For reference, Greg and Reedy say that we do.)
Comment 18 Greg Grossmeier 2013-10-16 18:30:47 UTC
(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.").

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links