On Fri, Mar 23, 2012 at 12:57 PM, Rob Lanphier <robla(a)wikimedia.org> wrote:
On Fri, Mar 23, 2012 at 7:33 AM, Chad
<innocentkiller(a)gmail.com> wrote:
On Thu, Mar 22, 2012 at 3:57 PM, Brion Vibber
<bvibber(a)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