Krinkle added a comment.
In T223410#6233012 <https://phabricator.wikimedia.org/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? From my perspectice, the same rationale for why +2 doesn't go to production automatically within the hour, either. We should imho stop cutting and deploying on the same day regardless of any other changes. Note that I'm not against more rapid deployments in general. I just think that right now we are far too disfynctional and undisciplined to do that responsibly. For changes merged Tue-Fri there are currently two working days for maintainers, product owners and QA to find out about what changes are made, whether they approve, and if so what amount of QA is appropiate to do locally or on Beta prior to deployment, and then to have performed that QA - all before the production deploy on Tuesday. The same applies to cross-cutting risks as well, e.g. TechCom, Security, Performance finding logical mistakes or misunderstands that are incompatible with current database, CDN, or parser cache semantics. Areas that are frequently misunderstood and rarely found even on group0. A similarly magical and undocumented/informal QA cycle also repeats itself for the Wednesday group0-1 and Thursday group1-2. None of this is formalised or explicitly expected or waited for, and thus assumes nobody is on vacation, or pulled away to other work on any given day. I elaborated on this at T118212: Take heat off day before the weekly branch-cut? <https://phabricator.wikimedia.org/T118212>. In short, I think we need to "logically slow down" (better understand and consistently expect/ensure), after which we can then try speeding it up, or simply removing time-bound bottlenecks alltogether and see how long it takes in general for people to do their thing. A long-term idea I have is that perhaps Beta shouldn't run master but rather the next branch. E.g. we'd cut it on Thursday for Beta, and promote onwards from there until the following Thursday, and repeat. There are a lot of moving parts though, so I'm definitely in favour of incremental changes and regular re-evaluation. TASK DETAIL https://phabricator.wikimedia.org/T223410 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Krinkle Cc: Catrope, Majavah, ArielGlenn, Krinkle, DannyS712, BEANS-X2, Amorymeltzer, RhinosF1, Ladsgroup, Michael, Jakob_WMDE, Pablo-WMDE, Addshore, Lydia_Pintscher, darthmon_wmde, WMDE-leszek, Lucas_Werkmeister_WMDE, brennen, mmodell, greg, hashar, Aklapper, Jdforrester-WMF, Blissjay007, Oblanco79, Alter-paule, Beast1978, CBogen, Un1tY, Hook696, Daryl-TTMG, RomaAmorRoma, E.S.A-Sheild, Kent7301, Meekrab2012, joker88john, CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Af420, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, WSH1906, Lewizho99, Maathavan, Poyekhali, _jensen, rosalieper, Taiwania_Justo, Liudvikas, Scott_WUaS, Ixocactus, Wong128hk, Wikidata-bugs, aude, El_Grafo, Dinoguy1000, Steinsplitter, Mbch331, Keegan
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
