I am always interested in mentoring it, but refuse to do it without the support of a real community using FlaggedRevs, via a knowledgeable community member as co-mentor.
We've tried to find one , and failed. (see history of this task) I'll be very happy if you succeed where I have failed.
I've especially tried to solicit Wikimedia Indonesia to provided a co-mentor from the Indonesian community which uses FlaggedRevs , but that hasnt worked in the past either. I will try that again this year, and will also look more broadly in the Indonesian community.
Tue, Jan 16
Hi @Xqt, this was taken into account in the development. The live tests can be activated using an environment variable. see recent addition to tests/README.rst . Maybe we want to update the Travis builds on the main repo to always do live tests.
Mon, Jan 15
I've created https://codein.withgoogle.com/dashboard/tasks/4590764342378496/ as a follow-up task for this, to add more cassettes. Only three available as this is a 'last task', and there is a lot of potential for conflict.
I've added a follow up GCI task to implement this in a Wikimedia project hosted on GitHub.
Thu, Jan 11
After it is merged, most of the functionality is done, and further enhancements would need to be worked on with the git-repo maintainers.
After it is merged, most of the functionality is done, and this task should be closed. This wouldnt be suitable for a tech project, as there are only tiny chunks left to write after this patch, and git-repo is intentionally limited in what functionality is added - all features must be sensible in most backends.
PYWIKIBOT2_TEST_ are easy. They are only used in our tests. Travis CI configs will be effected. Some forks may be using these in their CI, which will break if they are renamed. I suspect this isnt a big enough problem to worry about. Easy to fix.
My notes about improvements probably needed.
Oops. Now I need to create a GCI task for this.
Wed, Jan 10
Mon, Jan 8
Just do it.
Sun, Jan 7
Which scripts are left to port from compat? Has anyone asked for them? If not, we're importing more maintenance work without any clear benefit.
This is how we will have more tests running on the local developer machines very quickly and easily (not taking hours, interacting with sites), and on upload into Gerrit, instead of having to rely on Travis.
sorry I missed this; could you rebase the patch and submit to travis so we can see if it doesnt break anything (reflinks has good tests, so that is sufficient to verify nothing is broken). Then make sure that one of the tests tries to fetch a 2 Mb PDF, and emit a warning to indicate that the document was trimmed.
There are also requests and urllib3 workarounds in pywikibot.comms.
It is always required to use pywikibot.comms , because those 'features' are described in our documentation, and it is messy to need to document that the features only work sometimes.
Sat, Jan 6
There will be no impact on how this tool is installed in Gerrit.
@Paladox , this isnt about Gerrit. Please read first.
I've added myself and @MtDu as mentors.
The suggested limit on https://gerrit.wikimedia.org/r/#/c/223053/2/SyntaxHighlight_GeSHi.class.php was 2000 kb.
Could you try similar JS file of that size?
@Pietrodn would be better at answering that , as they were using an older version of Wikibase.
I believe we dont have good wikibase version detection, which would be the ideal solution, but we may have hit the goal here.
We probably dont have support for wbeditentity on older Wikibase.
Fri, Jan 5
Thu, Jan 4
c.f. https://github.com/PyCQA/pydocstyle/pull/227 - this __all__ problem shouldnt exist in pydocstyle. (I'm still investigating, and this doesnt impact the current CR)
Note that this change is removing the existing, working, __all__ checking. It likely brings in new features and bugs fixes, so probably is worth that, but then we need to get __all__ checking working again.
No more tasks for this script should be created, as it currently untested, and mostly untestable by design.
It is not acceptable to be having students doing tasks which are not tested. The result is low quality work, and a poor educational experience for the students.
We should be increasing test coverage, not decreasing it.
Added to 2017 GCI https://codein.withgoogle.com/dashboard/tasks/6029008296738816/
Here is the GCI 2015 task : https://codein.withgoogle.com/archive/2015/organization/4822184463695872/task/5953614677803008/
Try cleaning your cache (see maintenance script) or just delete tests/apicache*, to check whether you can reproduce locally.
Wed, Jan 3
The first set to do would be TestItemBasePageMethods , as there are other BasePageMethods tests in other parts of the system, making this an interesting way to get basic coverage of a lot of modules/classes quickly, and hopefully easily.
Pywikibot docstring params use epytext format.
This was already created as https://codein.withgoogle.com/dashboard/tasks/6189366353330176/ ; I am just creating a Phab task for it.
All commits should reference this Phab task
Agree, it is a waste of time to be updating this, as git log has better information if it is needed.
This was done at my request during code review because this script wasnt being tested with tests/script_tests.py which it should be.
Mon, Jan 1
Specifically testme whether line=off, line=false, line=disabled or some other reasonable boolean like value is possible.
IMO line=0 is not a good option.
Hmm, I also a bit doubt of that, since I can't test it in toolforge.
Thu, Dec 28
@ori created https://people.wikimedia.org/~ori/bad.js as a test case, and 'Python' failed badly (likely Pygments with all of its regexes, but maybe one of its dependencies). That is an Upstream failure. See his comment on https://gerrit.wikimedia.org/r/#/c/223053/ . But that was two years ago. Perhaps this should be retested, and a bug files Upstream if there still a problem.
The entire problem space has moved, as Wikimedia now uses Pygments. @Oetterer , are you still using the syntax highlighter that uses GeSHi ?
@divadsn , you have three commits on https://github.com/python-social-auth/social-core/pull/169/commits ; that is unnecessary , and in gerrit world it would be considered messy work. Please squash them.
Wed, Dec 27
Repeating some of what I put into the code review of https://github.com/python-social-auth/social-core/pull/169
Tue, Dec 26
Looking good so far. The most recent PRs included a unit test module.
Can we add some CSS to hide the MediaWiki auth?
First challenge is getting a test instance of Phabricator up.
https://secure.phabricator.com/ says NOTE: You can launch a test installation of Phabricator on [[Phacility|https://admin.phacility.com/]] if you want to poke around and try things out.
Wed, Dec 20
This was around the time we were revising the mwparserfromhell build system . We had only finished getting Python 3.4 working, and then another problem arose when testing on Python 3.5.
I can only guess that mwparserfromhell now supports Python 3.5+, but it would be wise to rerun the tests periodically.
cosmetic_changes sometimes have exceptions added for specific wikis which do not want the change.
My guess is most wikis wont have a problem with this cosmetic change. Lets try it and see who complains?
Dec 19 2017
@Filip , can you add some Polish templates to the task description?
I suggest using https://www.mediawiki.org/wiki/Manual:Pywikibot/PAWS for this. Less complicated.
The task description was wrong, I've updated it.
Here is the task from last year: https://codein.withgoogle.com/archive/2016/organization/5709875686408192/task/6126939156774912/