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:
https://bugzilla.wikimedia.org/buglist.cgi?
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
