I think a simple revert would be simplest. Adding a feature flag adds new
possibilities of overlooked bugs, especially since this is "just" a
refactoring and so *in theory* shouldn't be changing anything.
Maybe we could just cherry-pick a revert onto the Jan 2 branch, rather than
revert on master and then un-revert after the branch. It shouldn't be
interpreted as any comment on code quality or "readiness", just a
reflection of the fact that the first deploy after the holiday will
inevitable cause *some* breakage, and in our eggnog-induced stupor it would
be nice if we could just rule out this refactor as contributing to whatever
the breakage turns out to be. (That's why a feature flag doesn't seem
helpful to me; it would still be lines of code to comb through. Better
either a clean revert or just deploy the thing as is.)
--scott
On Fri, Dec 22, 2017 at 2:01 PM, Addshore <addshorewiki(a)gmail.com> wrote:
So the plan going forward will be to create a feature
flag for the MCR
Revision gutting.
I'll crack on with that this evening.
If that turns out to be too messy then we can revert the MCR patches for
the next wmf branch.
I'm currently keeping track of this @
https://wikitech.wikimedia.org/wiki/User:Addshore/MCR_Revert
On 22 December 2017 at 18:39, Ramsey Isler <risler(a)wikimedia.org> wrote:
Fantastic news! Great work handling this behemoth
of a technical
challenge.
On Fri, Dec 22, 2017 at 2:26 AM, Daniel Kinzler <
daniel.kinzler(a)wikimedia.de> wrote:
Hello all!
Addshore last night merged the patch[1] that is the first major step
towards
Multi-Content-Revisions[2]: it completely guts the Revision class and
turns it
into a thin proxy for the new RevisionStore service. The new code is now
live
on beta.
This is our second attempt: The first one, on December 18th, thoroughly
corrupted the beta database. It took us some time and a lot of help from
Aaron
and especially Roan to figure out what was happening. A detailed
post-mortem by
Roan can be found at [3].
Anyway - this stage of MCR development introduces the new multi-revision
capable
interface for revision storage (and blob storage) [4]. It does not yet
introduce
the new database schema, that will be the next step [5][6]. While doing
the
refactoring, I tried to keep the structure of the existing code mostly
intact,
just moving functionality out of Revision into the new classes, most
importantly
RevisionRecord, RevisionStore, and BlobStore.
Beware that with the next deployment (due January 2nd) the live sites
will start
using the new code. Please keep an eye out for any strangeness regarding
revision handling. Adam greatly improved test coverage of the relevant
code
(thanks Adam!), but it's always possible that we missed some edge case,
maybe
something about archived revisions that were partially migrated from on
old
schema or something similarly fun.
Exiting times!
Cheers
Daniel
[1]
https://gerrit.wikimedia.org/r/#/c/399174/
[2]
https://www.mediawiki.org/wiki/Requests_for_comment/Multi-
Content_Revisions
[3]
https://phabricator.wikimedia.org/T183252#3853749
[4]
https://phabricator.wikimedia.org/T174025
[5]
https://phabricator.wikimedia.org/T174024
[6]
https://phabricator.wikimedia.org/T174030
--
Daniel Kinzler
Principal Platform Engineer
Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
(
http://cscott.net)