Oct 25 2020
Jul 29 2020
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.
Jul 22 2020
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
Jul 9 2020
(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.
Jul 6 2020
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
Jul 4 2020
Jun 28 2020
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?
Jun 25 2020
Asking ws:it API for namespaces gives broken list when maxlag condition occurs. No maxlag/timeout error, no empty list like in other cases.
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.
Jun 24 2020
Jun 23 2020
Jun 22 2020
Goal: Find Wiktionary family file, find out some info about this wiki and appropriately update the file
Jun 19 2020
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
Jun 17 2020
Jun 16 2020
Jun 15 2020
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
Jun 14 2020
Jun 13 2020
Yeah, it's definitely a Regression as this never hapenned before
Jun 12 2020
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
Jun 11 2020
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.
Jun 10 2020
Let's try the API team about the successfull/duplicate messages not retrieved when expected
Jun 9 2020
@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) :)
Jun 8 2020
(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
Jun 7 2020
Jun 6 2020
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).
Jun 5 2020