Today

• No visible events.

Tomorrow

• No visible events.

Saturday

• No visible events.

User Since

Oct 16 2014, 9:25 AM (629 w, 6 d)

Availability

Available

IRC Nick

jayvdb

LDAP User

Unknown

MediaWiki User

John Vandenberg [ Global Accounts ]

Also if edit groups are now a thing that the community wants, it should be supported by functionality in core , that can be reused by any scripts.

Wont this cause errors due to duplicate label?

Perhaps a different script might be more sensible for this task.

Removing from GCI until it is very clear how this should proceed.

What is this?

I dont care much about the style, but dropping links seems unnecessary, except as an odd abuse prevention mechanism. Perhaps this could be allowed on more internal wikis like mediawiki.org and meta, which see more content copy-pasted from office documents by staff, devs and affiliates.

This can be closed?

We could use github repo topics to identify the repos which are active on github.

https://lists.wikimedia.org/pipermail/pywikibot/2016-August/009493.html is Amir attacking me without naming me, because his patches were not being accepted. It is full of lies. I have stepped away from Pywikibot as a result of that email, except for mentoring GSoC and GCI students.

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.

Note I will also be attending that weekend due to being selected as the mentor for coala.

Merged into devel https://github.com/guyzmo/git-repo/commit/2974c3f52bc64fa8a467ac2b0e9a485ba7ed333b

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.

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.

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.

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.
https://codein.withgoogle.com/dashboard/tasks/5025736417083392/

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.

Just do it.

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.

Also note that vcrpy is already a dependency due to nose-detecthttp

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.

Two new possible GCI tasks T184360 & T184361 . Need more analysis done, and expanding the description to ensure that the work is of a high quality.

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.

Imported as https://codein.withgoogle.com/dashboard/tasks/4929536800063488/

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.

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.

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.

@Legoktm , @hashar , I guess this task can be closed. It was originally a pywikibot task, but it grew big legs and achieved many things. Re-open if I am mistaken.

This was done at my request during code review because this script wasnt being tested with tests/script_tests.py which it should be.

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.

@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.

Repeating some of what I put into the code review of https://github.com/python-social-auth/social-core/pull/169

Looking good so far. The most recent PRs included a unit test module.

In T183698#3861026, @Paladox wrote:

Nope removing mediawiki auth will fix it, but will also prevent showing the other login form.