On Thu, Oct 21, 2010 at 3:31 PM, Neil Kandalgaonkar neilk@wikimedia.orgwrote:
On 10/21/10 2:16 PM, Aryeh Gregor wrote:
- 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