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.