I mean this is a fair point to me. Project Dashboards are much more novice-friendly than just list of open changes and a search field, for sure.

But that would just show all things (even abandoned) and not in distinct categories, which is usually quite cluttered. To me this is a huge regression, that perhaps bothers just me (as I was using the dashboard all the time), but as it does not bother anyone else, noone want to make effort to fix this.

No sysopwiki/arbcomwiki is in Pwb yet I think, perhaps let's close it as declined until we decide to include them as a whole group

(or find more stable wiki installation with unavailable api.php)

Reverted, the patch broke the test. It fails because the wiki has temporary server issues. Either leave the test as is or remove it at all.

There definitively should be a parser function for this, but perhaps we have to investigate more about its name

Arch Linux: No issue with installation of 3.0.20200703

Good point

Nice, this is what I looked for last 12 months at least :D

I know I might be weird, but I can not see any easy option to find merged patches to a project, which is a good way (for example) to look for regressions, comment merged patchsets (as a good way to communicate about regressions), revert merged patches, etc. The new behavior makes the work with Gerrit quite disturbing and it seems as a bug as some other Gerrit instances I used last time does support project dashboards.

Or just navigate visitors to the MW.org docs from there

Can we with Gerrit 3.2 somehow add some project description, where we could mention this? The same with Phabricator rPWBC project?

Asking ws:it API for namespaces gives broken list when maxlag condition occurs. No maxlag/timeout error, no empty list like in other cases.

In T242083#5954453, @Xqt wrote:

if maxlag Timeout occurs the tests are skipped as expected (see wp.de and wp.en) but it seems there is not maxlag for ws.it. The NamespacesDict is insufficient instead:

Validate page_from_repository on wikipedia:de ... Sleeping for 5.0 seconds, 2020-03-09 16:11:17
Sleeping for 5.0 seconds, 2020-03-09 16:11:22
Sleeping for 5.0 seconds, 2020-03-09 16:11:28
Sleeping for 5.0 seconds, 2020-03-09 16:11:33
Sleeping for 6.2 seconds, 2020-03-09 16:11:38
skipped 'Maximum retries attempted due to maxlag without success.'
 26.987s test_page_from_repository_en_wp (tests.site_tests.TestCategoryFromWikibase)
Validate page_from_repository on wikipedia:en ... Sleeping for 5.0 seconds, 2020-03-09 16:11:44
Sleeping for 5.0 seconds, 2020-03-09 16:11:49
Sleeping for 5.0 seconds, 2020-03-09 16:11:54
Sleeping for 5.0 seconds, 2020-03-09 16:12:00
Sleeping for 7.1 seconds, 2020-03-09 16:12:05
skipped 'Maximum retries attempted due to maxlag without success.'
 27.878s test_page_from_repository_it_ws (tests.site_tests.TestCategoryFromWikibase)
Validate page_from_repository on wikisource:it ... ERROR

This is a new behaviour of api fault ihmo.

Well this is not a thing to debate, there must be some bulletproof statistics. Anyway from my experience, on Czech Wikipedia there is a surprisingly big number of IE users even today.

Browser support?

Ok

Goal: Find Wiktionary family file, find out some info about this wiki and appropriately update the file

Last patch works finally. Travis is now forced to uninstall and then reinstall pytest, which resolves all version conflicts.

And now 4.1.0 is conflicting. But pytest should not be installed at all.

CHANGELOG of pytest-cov says they dropped support for py < 3.5, but they mean py3 < 3.5. Arghhhhhhh. Fixed in quick patch, should be ok now

Many thanks!

Well, the original reported issue was for old UI. Aklapper only added the issue occurs also with the new UI. The old UI issue probably had a different cause

@hashar?

Yeah, it's definitely a Regression as this never hapenned before

I continue to hope that someday, the Linter tracking will actually apply Wikipedia categories, so that we can work with them in the usual way.
One note from a gnome to a developer: "new uses that cause rendering failures will be obvious right away" is not a valid supposition.

Seems resolved now.

I created revert (https://gerrit.wikimedia.org/r/#/c/pywikibot/core/+/604926/), but it can't be merged possibly due to T252310

StackOverflow suggests this:

$ git reset 3.0.20200609
$ git add .
$ git commit -m "3.0.20200707"
$ git review stable

It should be much more simple like:

$ python3 setup.py sdist
... possibly cleanup or clone a clean repository
$ git review stable
... pushes master into stable directly

But I feel like this would require to squash all commits since the last version into one commit like described in https://www.mediawiki.org/wiki/Gerrit/Tutorial#Squash_several_commits_into_one_single_commit_via_rebase

With git it should work like this:

In standard git environemnt this would mean just to merge master branch into stable branch after every release, but I'm not familiat how this works with Gerrit (@Urbanecm ?)

After 3.0.2020070x we will no longer need to update python2.

Occurs again. Possibly have something to do with git tags, because today were two tags changed and one added.

Oh, should I close this as a duplicate?

Happenned also in Travis wowwiki test

Ecoreality seems to work fine lately

Started to fail cca 4 hours ago, tests passed before. Fails currently only on testwiki and enwpbeta. The following two tests are failing (both should be extremely easy to understand):

Tested 2.7.18 in Travis: https://travis-ci.org/github/dvorapa/pywikibot/builds/697066525, everything seems fine.

Let's try the API team about the successfull/duplicate messages not retrieved when expected

@bd808 Google now requires to pay for using his Maps externally (i.e. in Toolforge tools), so any solution to the proxy issue would still not help restoring Google Maps tools. But Google provides free access for foundations, who ask for that. Could we somehow on behalf of WMF ask Google (through their provided contact form for these cases) for this access?

After this announcement reaches Pywikibot mailing list, I'll also send a note to Tech news, again with the link to the e-mail announcement.

Yes, to my request (I don't know how to work with mailing lists) :)

(I feel like this is not only an add action. Users can ping people, so they know about the conversation (ping action), users can navigate to people, so others know who is responsible (navigate action), users can just reply to more people in one comment (comment part delimiter)...)

Any additional info from him/her would be much appreciated

@Xqt?

Then I would say this is classic Commons rate-limit issue with large files. Not sure what to do with it.

If the script sends at least one request to Wikidata, then this is caused by Wikidata lag (last week no bot was able to edit Wikidata with correct bot settings).

Yeah, an old issue, you can find more MW 1.19 issues in MW 1.19 tests. Also there is an issue with editmywatchlist right and gsrsearch (also shown in Fandom wiki tests)

Cool!

In T111853#6196291, @Ladsgroup wrote:

In T111853#6196240, @Dvorapa wrote:

Could we remove be-x-old from langlist? Can it break something?

I tried it (then generated the interwiki dump). It removed all interwiki links of be-x-old, meaning [[:be-x-old:foo]] would stop working. I rather try it in another time (gradual improvements).

Cool!