Page MenuHomePhabricator

Decommission compat
Closed, ResolvedPublic

Description

Draft plan (please edit):

  1. release 2.0 release candidate and stop updating shared/nightly releases
  2. mass change all #pywikiboot-compat bugs to Lowest priority, except if they are also Pywikibot tasks, with a note to retest in core and close the task as Declined if the bug is fixed in core.
  3. notify all large village pumps that compat is deprecated
  4. request that 'Bot approval' processes and teams reject compat bots
  5. T99373 - Analytics monitoring and reporting on compat bots running on Wikimedia sites
  6. rewrite / replace compat bots; fix core bugs preventing upgrading to core: Pywikibot-compat-to-core
  7. Move all compat documentation to https://www.mediawiki.org/wiki/Manual:Pywikibot/Compat, add it to https://www.mediawiki.org/wiki/Template:Pywikibot
  8. hold a Pywikibot-General cleanup day to triage all bugs in that tag into either/both compat/core, and then delete that tag. (and then repeat step 2)
  9. release Pywikibot 2.0
  10. at Wikimania July 2015 (https://wikimania2015.wikimedia.org/), mass close all tasks that are Pywikibot-compat only
  11. Block bots using Pywikipedia in user-agent
  12. Celebrate.

Event Timeline

jayvdb raised the priority of this task from to Needs Triage.
jayvdb updated the task description. (Show Details)
Restricted Application added subscribers: Aklapper, Unknown Object (MLST). · View Herald TranscriptJun 3 2015, 3:18 AM

@Aklapper can do number 2 (mass change all #pywikiboot-compat bugs to Lowest priority)
I can do the number 3 (notify all large village pumps that compat is deprecated)
I already did number 4 and asked Marios not to accept compat based codes
(request that 'Bot approval' processes and teams reject compat bots)

No 1 on plan migt be:

  1. Solve all bugs in compat which prevents users from using it for all tasks

No 1 on plan migt be:

  1. Solve all bugs in compat which prevents users from using it for all tasks

Based on your comment in T99365#1293286, I fixed lots of your bugs. There is only one bug in pywikibot-core with "Unbreak Now!" priority (T100779). Note that we can't fix all of core bugs ;)
Can you name all of blocker bugs in core?

@Ladsgroup did we ever had "Unbreak Now!" prios in pywikibot? I thought that prio level is reserved for mw only.

Yes, It's possible to have unbreak now priority in pywikibot. Why not?

@Xqt: the priorities are used however they like. MW says only the assigned should use it but I personally don't know how this is helpful as the assigned should know how important it is to them.

@Ladsgroup: Please don't say “X can do 2, Y can do 3” in case the entries and numbering does change.

I don't think compat should be banished THAT hard. It's an open source project so others should feel free to fork it and fix bugs thy encounter (or create a group on their own supporting it). It should be up to the wiki administrators if they want to allow compat bots.

jayvdb set Security to None.

"Block bots using Pywikipedia in user-agent". What would be the benefit?

  1. mass change all #pywikiboot-compat bugs to Lowest priority, except if they are also pywikibot-core tasks, with a note to retest in core and close the task as Declined if the bug is fixed in core.

Done for 82 tasks that were in pywikibot-compat but not in pywikibot-core. (Mass-adding comments ignores linebreaks, meh.)

"Block bots using Pywikipedia in user-agent". What would be the benefit?

Wikimedia devs (Pywikibot and MediaWiki) no longer need to support it, and if Wikimedia doesnt allow it to be used, most other users will stop using it too.

This step is probably not going to be necessary, due to T101524: Many parts of compat will break when used on Wikimedia servers on July 1, 2015.
WMF are already advocating to block bots like this.

Wikimedia sites run very new/green code, and lately the MW devs are keen on breaking things, even intentionally so that their maintenance costs of legacy code is reduced.
In addition the WMF - which already has a very quick deploy cycle - is moving to a high-speed deploy train with only a few days between deploy to test servers and deploy to the capital city (English Wikipedia).

MediaWiki will be able to move more quickly (and with less risk) if they can be tested against the main clients using it. Pywikibot core is hopefully close to being tested regularly against the Beta-Cluster (T100903) and making it possible to run pywikibot tests against a MediaWiki changeset before commit (T58961). Other clients like mwclient also have test suites that can be run to detect if support was broken. This cant happen with compat as it doesnt have a test suite, and bugs raised are not worked on quickly enough to remain being supported by Wikimedia.

This probably warrants a notice to users and sysadmins, in conjunction with T101524.

I talked with one of BAG members of English Wikipedia to reject compat-based bots. He was okay.

  1. request that 'Bot approval' processes and teams reject compat bots
  1. Block bots using Pywikipedia in user-agent

reject compat-based bots

Why such a manhunt? I'm pretty sure many other operators use custom out-of-date frameworks.

Before forbidding compat bots please solve T74674, which prevents core interwiki bots in wiktionary run in autonomous mode.

I stroked some step which are already done or declined.

Change 322502 had a related patch set uploaded (by Xqt):
Decommission compat

https://gerrit.wikimedia.org/r/322502

Change 322502 merged by jenkins-bot:
Decommission compat

https://gerrit.wikimedia.org/r/322502

Xqt claimed this task.

Change 388054 had a related patch set uploaded (by Hashar; owner: Hashar):
[integration/config@master] Mark pywikibot/compat as archived

https://gerrit.wikimedia.org/r/388054

Change 388054 merged by jenkins-bot:
[integration/config@master] Mark pywikibot/compat as archived

https://gerrit.wikimedia.org/r/388054