On Wed, Jun 17, 2015 at 10:53 AM, Brad Jorsch (Anomie) <[email protected]> wrote: > We have an (informal?) policy that deprecation warnings shouldn't be raised > in WMF production. Thus if a core patch is going to add deprecation > warnings we have to make sure that all extensions deployed on the cluster > are updated to not trigger the warning. We can accomplish this by carefully > managing the addition of the warnings, by detecting the core version from > the extension and changing behavior, or by simply updating both core and > extension at the same time. > > With Gerrit change 134827,[1] the affected extensions are Flow and > CentralAuth. For neither of these extensions do we care that > extension-master works with non-master versions of MediaWiki core, and > patches to update the extensions are ready.[2][3] So normally we'd just > merge all three at once and be done with it. > > The problem is unit tests: we can't merge the core change[1] first because > Flow's unit tests will fail on the deprecation warning, and we can't merge > the Flow change[2] first because it doesn't work without the core change. > There are various ways to work around this, but all are ugly: > > 1. Merge the core change over Jenkins's objections, then the Flow change > can be merged as normal. But overriding Jenkins sucks. > 2. Split the core patch into two parts: part 1 does everything except > add the wfDeprecated() call, while part 2 adds just the wfDeprecated() call > and will be merged immediately after. The make-work here just to make > Jenkins happy sucks and slightly clutters the commit history. > 3. Rewrite the Flow unit test to detect whether core has the core change > and alter behavior accordingly. This is even more make-work than option 2 > when we're otherwise happy to just coordinate the merges. > > Which ugly option do we as a development community prefer in this > situation? Personally I'd go for option 1 as the most expedient with the > fewest long-term consequences. > > [1]: https://gerrit.wikimedia.org/r/#/c/134827/ > [2]: https://gerrit.wikimedia.org/r/#/c/190023/ > [3]: https://gerrit.wikimedia.org/r/#/c/190026/ > > > P.S. Let's not side-track this into whether the "extension master only > needs to be compatible with core master" policy for Flow and CentralAuth is > good/bad, or that situations exist where options 2 or 3 are necessary > choices (e.g. #2 when the extension fixes aren't ready yet and #3 when an > extension involved doesn't have the "master is only compatible with core > master" policy), or whether allowing core changes to be merged that cause > non-WMF-deployed extensions to raise deprecation warnings is somehow > discriminating against non-WMF-deployed extensions. Start a new thread if > you want to discuss those, please.
For the similar but slightly different case of library version bumps in composer.json and the associated mediawiki/vendor repo that holds the Jenkins/Beta cluster/Prod realization of composer.json we use the force past Jenkins option (#1). Both patches are put into Gerrit and fail Jenkins tests: in core because functionality from the updated library isn't available and in vendor because the library doesn't match the version in core's composer.json. The vendor patch can be forced and then the core patch retested to ensure that core is in the right state with the updated vendor. Bryan -- Bryan Davis Wikimedia Foundation <[email protected]> [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855 _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
