On Fri, Mar 23, 2012 at 12:57 PM, Rob Lanphier <[email protected]> wrote: > On Fri, Mar 23, 2012 at 7:33 AM, Chad <[email protected]> wrote: >> On Thu, Mar 22, 2012 at 3:57 PM, Brion Vibber <[email protected]> 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 _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
