On Wed, Sep 26, 2012 at 3:24 PM, Sam Reed reedy@wikimedia.org wrote:
Krinkle <krinklemail <at> gmail.com> writes:
On Sep 22, 2012, at 10:54 PM, Mark A. Hershberger <mah <at> everybody.org>
wrote:
On 09/22/2012 02:50 PM, Krinkle wrote:
On Sep 21, 2012, at 4:13 PM, Mark A. Hershberger <mah <at> everybody.org>
wrote:
That commit is not included. I can merge it in or make a second RC with 1.20wmf12.
What do you think is the better way to go?
I'd say re-branch from master.
My thinking was to branch from a point that was known -- something whose issues we knew. I think this worked pretty well.
For instance, the issue Niklas raised was because I used a WMF branch.
I'm now thinking that I'll just stick with the 1.20wmf12 and just apply the patch he pointed to. This is in the vein of sticking to known issues.
What do you think?
Mark.
I think master is more stable then whatever wmf branch. I know because of
commits
recently merged and whatnot.
If there are problems we'll find them in the release candidate period. And by that time we'll have had a new wmf branch as well to see how the latest
code
performs on wmf.
Also, this bugzilla query should be empty before release as well (either by
fixing bugs,
or reviewing/merging pending commits that claim to fix stuff, or deferring the
bug to
a later release etc.). People assign and block things usually for a reason:
query_format=advanced&target_milestone=1.20.0%20release&product=MediaWiki&resolu tion=---
Those reasons for using master can be used in the counter argument. The counter argument has the fact that we've been using said branch in production for upto 2 weeks - we know it works (mostly).
Yes, master will have had numerous bugfixes brought into it, but there are also likely "new features" and other bugs introduced.
I think using a branch (though, not specifically the WMF branches "as is", due to WMF specific modifications. They want reverting out. Same goes for we don't want any of the extension update to master commits) is the best idea. Branching a REL1_20 branch from say the point that 1.20wmf12 branched, and then also backporting any relevant fixes from master makes sense. Pretty much how we did it for SVN, hopefully without the months and months of merging hell.
If we create a REL1_20 release branch now, we should then go through the usual process of bumping $wgVersion, creating RELEASE-NOTES-1.21 and new WMF branches can go back to wmf1 etc as a prefix.
I agree with Sam on all counts here (and actually suggested this as well). Since we're getting ready to land ContentHandler, it would be nice to have this branched before that happens. That way 1.20 can remain stable and be near a release.... ContentHandler will just be the first big thing to land in 1.21 :)
-Chad