[Wikidata-bugs] [Maniphest] [Commented On] T223410: Split group1 so that Commons and Wikidata aren't in the general group1, but their own buckets

Ladsgroup added a comment. In T223410#6233012 , @Catrope wrote: > What's the rationale behind doing the branch cut on Friday, then waiting over 72 hours to deploy it to even test wikis on Monday? In the table in T223410#6174334

[Wikidata-bugs] [Maniphest] [Commented On] T223410: Split group1 so that Commons and Wikidata aren't in the general group1, but their own buckets

Catrope added a comment. What's the rationale behind doing the branch cut on Friday, then waiting over 72 hours to deploy it to even test wikis on Monday? In the table in T223410#6174334 , maybe we could move the branch cut to the "early

[Wikidata-bugs] [Maniphest] [Commented On] T223410: Split group1 so that Commons and Wikidata aren't in the general group1, but their own buckets

Addshore added a comment. In T223410#6174639 , @Jdforrester-WMF wrote: > In T223410#6173263 , @Addshore wrote: > >> If MediaWiki has an issue and wikidata is one of the first things

[Wikidata-bugs] [Maniphest] [Commented On] T223410: Split group1 so that Commons and Wikidata aren't in the general group1, but their own buckets

Jdforrester-WMF added a comment. In T223410#6173263 , @Addshore wrote: > If MediaWiki has an issue and wikidata is one of the first things to catch that, we risk bringing everything down. > The alternative order would be deploy to

[Wikidata-bugs] [Maniphest] [Commented On] T223410: Split group1 so that Commons and Wikidata aren't in the general group1, but their own buckets

mmodell added a comment. So that leaves wednesday for wikidata: | Name | Time | Sunday | Monday| Tuesday | Wednesday | Thursday | Friday | Saturday | | -- | -- | -- | - | --- | - | |

[Wikidata-bugs] [Maniphest] [Commented On] T223410: Split group1 so that Commons and Wikidata aren't in the general group1, but their own buckets

Addshore added a comment. In T223410#6172852 , @Krinkle wrote: > If there are "general" (non-Wikidata) issues to uncover on group0, we would ideally uncover them without letting Wikidata propagate and corrupt data to group2 and group1

[Wikidata-bugs] [Maniphest] [Commented On] T223410: Split group1 so that Commons and Wikidata aren't in the general group1, but their own buckets

Krinkle added a comment. If there are "general" (non-Wikidata) issues to uncover on group0, we would ideally uncover them without letting Wikidata propagate and corrupt data to group2 and group1 wikis like Wikipedia, and Commons, and also without letting it take down those sites e.g. as

[Wikidata-bugs] [Maniphest] [Commented On] T223410: Split group1 so that Commons and Wikidata aren't in the general group1, but their own buckets

mmodell added a comment. So how about something like this (only slightly different from what @krinkle has proposed in that I've got testwikis automated on monday and the branch cut automated on froday) | Name | Time | Sunday | Monday| Tuesday | Wednesday |

[Wikidata-bugs] [Maniphest] [Commented On] T223410: Split group1 so that Commons and Wikidata aren't in the general group1, but their own buckets

Ladsgroup added a comment. I'm slightly concerned by putting Wikidata in front of all production wikis. Issues in Wikidata usually propagates to all wikis, can Wikidata take it after group0? TASK DETAIL https://phabricator.wikimedia.org/T223410 EMAIL PREFERENCES

[Wikidata-bugs] [Maniphest] [Commented On] T223410: Split group1 so that Commons and Wikidata aren't in the general group1, but their own buckets

Krinkle added a comment. In T223410#6171292 , @Krinkle wrote: > We have also done per-wiki promotions directly at times in the past. Actually, this is done every week on Tuesday to promote testwiki (ahead of the rest from group0).

[Wikidata-bugs] [Maniphest] [Commented On] T223410: Split group1 so that Commons and Wikidata aren't in the general group1, but their own buckets

Krinkle added a comment. In T223410#5783502 , @mmodell wrote: > I generally like this proposal, however, I dislike the growing complexity of the groups and their naming. (I was thinking the same). I don't have a preference other

[Wikidata-bugs] [Maniphest] [Commented On] T223410: Split group1 so that Commons and Wikidata aren't in the general group1, but their own buckets

gerritbot added a comment. Change 599124 had a related patch set uploaded (by Jforrester; owner: Jforrester): [mediawiki/tools/release@master] Add deploy-promote check domains for groupD and groupC https://gerrit.wikimedia.org/r/599124 TASK DETAIL

[Wikidata-bugs] [Maniphest] [Commented On] T223410: Split group1 so that Commons and Wikidata aren't in the general group1, but their own buckets

gerritbot added a comment. Change 599125 had a related patch set uploaded (by Jforrester; owner: Jforrester): [operations/mediawiki-config@master] [DNM] Split Wikidata and Commons out of group1, into groupD and C respectively https://gerrit.wikimedia.org/r/599125 TASK DETAIL

[Wikidata-bugs] [Maniphest] [Commented On] T223410: Split group1 so that Commons and Wikidata aren't in the general group1, but their own buckets

Ladsgroup added a comment. > Try to roll out the Wikidata change on Tuesdays during European hours so that the Wikidata team are around, after the main group0 deployment Wouldn't this mean either Wikidata will get the new train before test wikis (in case the train is being rolled in US

[Wikidata-bugs] [Maniphest] [Commented On] T223410: Split group1 so that Commons and Wikidata aren't in the general group1, but their own buckets

mmodell added a comment. I generally like this proposal, however, I dislike the growing complexity of the groups and their naming. I don't currently have a better proposal than what's listed in the task description so this comment is worth < $0.02 TASK DETAIL

[Wikidata-bugs] [Maniphest] [Commented On] T223410: Split group1 so that Commons and Wikidata aren't in the general group1, but their own buckets

hashar added a comment. Intuitively, I think Wikidata would benefit from being deployed during European mornings. This way we get ample coverage from WMDE developers. The actual promotion is a single command, the devil lies in monitoring the log. I am definitely volunteering in training