Sun, Mar 4
Mon, Feb 26
Fri, Feb 23
Thanks @Tgr , that use case sounds perfect. I've added you as a mentor, with the expectation you'll mostly be involved in familiarisation at the beginning, and validation of the use cases and checking the final code meets the communities needs.
Feb 15 2018
Note I will also be attending that weekend due to being selected as the mentor for coala.
Feb 9 2018
Feb 5 2018
Jan 19 2018
Re notifications, I saw that a feature Google added towards the end of this years program was emails sent when the task is 24 hrs elapsed for mentors to review, i.e. 12 hrs to go.
Jan 17 2018
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.
Jan 16 2018
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.
Jan 15 2018
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.
Jan 11 2018
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.
Jan 10 2018
Jan 8 2018
Just do it.
Jan 7 2018
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.
Jan 6 2018
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.
Jan 5 2018
Jan 4 2018
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.
Jan 3 2018
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.
Jan 1 2018
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.
Dec 28 2017
@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.
Dec 27 2017
Repeating some of what I put into the code review of https://github.com/python-social-auth/social-core/pull/169
Dec 26 2017
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 if you want to poke around and try things out.
Dec 20 2017
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 mwparserfromhell tests periodically, as it doesnt see a lot of PRs so not many eyes on it.
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?