(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(a)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(a)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(a)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.)
[1]
https://toolserver.org/~nemobis/crstats/core.txt