(continued, about the deployment process)
I'm going to start this one with some quotes which summarize the topic better than I would.
On Fri, 07 Mar 2014 00:30:24 +0100, Jon Robson jdlrobson@gmail.com wrote:
The code was merged at the final hour before a deployment train (this is another issue that our deployment train doesn't distinguish between patches that have been sitting on master for a week with patches that have been sitting there for 1 hour). Had this been merged on a Thursday morning we would have had more luxury and a revert maybe could have been avoided (but I still don't think that patch was in a mergeable format).
On Fri, 07 Mar 2014 01:08:54 +0100, Erik Bernhardson ebernhardson@wikimedia.org wrote:
Does core have any policies related to merging? The core features team has adopted a methodology(although slightly different) that we learned of from the VE team. Essentially +2 for 24 hours before a deployment branch is cut is limited to fixes for bugs that were introduced since the last deployment branch was cut or reverts for patches that turned out to not be ready for deployment. Core is certainly bigger and with more participants, but perhaps a conversation about when to +2 and how that effects the deployment process would be benefitial?
On Fri, 07 Mar 2014 01:31:43 +0100, Chris Steipp csteipp@wikimedia.org wrote:
Formally, no (not that I know of). Informally, I know a lot of us do a lot of merging on Fridays, partly for this reason. I resisted merging a big patch this morning because I want it to sit in beta for a while. I know a few patches were merged this morning so that they *would* make it into today's deploy. Everyone with +2 should always think about how/when things will be deployed, and merge as appropriate. And it seems like most people use good judgement most of the time.
We use continuous integration, we keep the deployed version pretty close to master, everyone used to be glad we did that and now everyone is commenting how that's not good. :)
I really do not think that blocking merges into core for 15% of the week is going to do us any good. Core already has a problem with stale patches not being touched (for various reasons, but most stemming from the lack of reviewers) and creating more obstructions is not going to help.
(As a volunteer developer and currently the most active user of CR+2 rights [1], this would seriously interrupt my workflow. I do reviews and merges when I have free time and being forced to adhere to WMF's deployment schedule would impede me.)
If – if – we need additional delay between when patches are merged and when they are deployed, in addition to the ones we already have (semi-beta period on testwikis and mw.org), this should be solved on the technical level, not by a policy – simply branch off from master@{24 hours ago} (or 3 days, or 7 days, whatever) rather than master, or add a delay between a new branch being cut and it being deployed (AFAIK this now happens as instantly as technically possible). Blocking merges to the most active repository just because a certain organization has to do a deployment sound rather irresponsible to me.
(And that's it from me for now. I'll also reply to some tangenial emails inline.)