On Thu, Oct 21, 2010 at 3:31 PM, Neil Kandalgaonkar <neilk(a)wikimedia.org>wrote;wrote:
On 10/21/10 2:16 PM, Aryeh Gregor wrote:
3. How
deep is the belief that Wikimedia production deployment must
precede a MediaWiki tarball release? Put another way, how tightly are
they coupled?
IMO, it's essential that Wikimedia get back to incrementally deploying
trunk instead of a separate branch.
I agree with this very strongly.
I would like to know what (if any) arguments there are for doing a
separate deploy branch. It seems to me that we ought to be deploying
constantly to the website, and making occasional MediaWiki branch
releases. On the projects we want timeliness, and downstream MediaWiki
packagers want stability,
Original announcement thread from July 2009:
http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg03903.html
The original purpose of having a deployment branch was so that we actually
knew what we were running! :) Even with fairly regular deployments from
trunk, we had two big problems:
1) "live hacks" -- little tweaks, patches, and one-off hacks in the live
code to work around temporary problems. These would accumulate over time and
eventually we'd end up with surprise merging problems at deployment time, or
just forgetting to merge important bits of code back into trunk... sometimes
hacks that should have been kept got even accidentally removed when a new
version got pulled in!
Knowing that was was in deployment was *exactly* what was in SVN means that
we know
a) where they came from
b) when and by whom they were committed
and
c) allows folks to easily see the difference between trunk and deployment
and make sure that important work is in fact merged back.
In theory, live hacks are punishable by eternal torture in the bowels of SVN
branching. In practice, they'll happen as long as it's _possible_ to deploy
code that's not in SVN.
2) Temporary breakages on trunk right in the middle of an important quick
fix
If we don't do those one-off fixes, workarounds, and debugging hacks as live
hacks, the alternative without a deployment branch is to actually do them
*on* trunk. That means that when you want to slap in a one-line tweak to fix
or debug something, you *also* have to deploy the last few days' worth of
trunk changes.
Hopefully there are no regressions or incompatible changes. Right? Right? :)
But ultimately, wmf-deployment was never intended to diverge from trunk by
more than a couple weeks in regular usage; I was aiming for a weekly or
biweekly deployment schedule.
With the sort of backlog we've developed during the long slog of stabilizing
the new JavaScript layers, they've ended up HUGEly divergent, which is very
unpleasant -- especially with SVN's primitive merging systems.
For what it's worth, I'm influenced by my former job at Flickr, where
the practice was to deploy several times *per day*,
directly from trunk.
That may be more extreme than we want but be aware there are people who
are doing it successfully -- it just takes a few extra development
practices.
If in-progress work were done on branches and merged to trunk when stable,
that would be a grand way to go. That's a big pain in the butt with SVN's
branching, unfortunately, but much easier with git.
-- brion