On Fri, Mar 23, 2012 at 12:57 PM, Rob Lanphier robla@wikimedia.org wrote:
On Fri, Mar 23, 2012 at 7:33 AM, Chad innocentkiller@gmail.com wrote:
On Thu, Mar 22, 2012 at 3:57 PM, Brion Vibber bvibber@wikimedia.org wrote:
I kinda like the first model (it feels more organic), but the second has the advantage that you've got a previous branch to revert to quickly if needed. That's a plus for deployment work.
-- brion
I kinda like the idea of both. We need a wmf-branch (specific hacks for us, ability to trail master when need be), but having tags is super useful too.
Well, we need two wmf-branches when we're mid-deploy, which is going to be far more frequently in the new regime. When mediawiki.org, meta, commons, and nlwiki are on 1.20wmf03 for a week, while enwiki and others are on 1.20wmf02, we'll need to be mindful of what we might backport to both branches.
Then a branch for each one we're deploying. No harm in having wmf-1.20 and wmf-1.19 at the same time.
Now, in this new model, backporting in general should be far, far less frequent, and only done for the most urgent bugfixes.
Agreed. We want to keep them as close to master as possible as it is.
Why not just have the branch but make a new tag before any scap? Best of both worlds ;-)
There are almost certainly going to be times when the wmf branch isn't linear (e.g. a security fix needs to be deployed to all wikis, even though we're not ready to push all wikis to the tip of the wmf branch)
I disagree here. The wmf branches should always be linear, and you should never merge to it without accepting that it may get scapped.
-Chad