Google Code-in is an annual contest for 13-17 year old students. It
will take place from Nov28 to Jan17 and is not only about coding tasks.
While we wait whether Wikimedia will get accepted:
* You have small, self-contained bugs you'd like to see fixed?
* Your documentation needs specific improvements?
* Your user interface has small design issues?
* Your Outreachy/Summer of Code project welcomes small tweaks?
* You'd enjoy helping someone port your template to Lua?
* Your gadget code uses some deprecated API calls?
* You have tasks in mind that welcome some research?
Also note that "Beginner tasks" (e.g. "Set up Vagrant" etc) and
"generic" tasks are very welcome (e.g. "Choose & fix 2 PHP7 issues
from the list in https://phabricator.wikimedia.org/T120336 ").
Because we will need hundreds of tasks. :)
And we also have more than 400 unassigned open 'easy' tasks listed:
https://phabricator.wikimedia.org/maniphest/query/HCyOonSbFn.z/#R
Would you be willing to mentor some of those in your area?
Please take a moment to find / update [Phabricator etc.] tasks in your
project(s) which would take an experienced contributor 2-3 hours. Check
https://www.mediawiki.org/wiki/Google_Code-in/Mentors
and please ask if you have any questions!
For some achievements from last round, see
https://blog.wikimedia.org/2017/02/03/google-code-in/
Thanks!,
andre
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
Tool-forge users can ignore this email, it only concerns VPS
project owners.
Long ago, the Wikimedia Operations team made the decision to phase
out use of Ubuntu servers in favor of Debian. It's a long, slow process
that is still ongoing, but in production Trusty is running on an
ever-shrinking minority of our servers.
As Trusty becomes more of an odd duck in production, it grows
harder to support in Cloud Services as well. Right now we have no
planned timeline for phasing out Trusty instances (there are 238 of
them!) but in anticipation of that phase-out we'd like to discourage the
addition of new Trusty hosts to the cloud.
Step one[1] is to prevent people from creating new Trusty images
unless they really, really need them. We would like to remove Trusty
from the default available list of base images and make it available for
new VMs only via special request on phabricator. The questions for you are:
1) Would that change make your life a lot harder?
2) If yes, can you name a date after which it /won't/ make your life harder?
If the loss of Trusty doesn't worry you, feel free to ignore this
email. In the event of a silent (or relatively quiet) response, I'll
pull Trusty from the default image list sometime in the next few weeks.
- Andrew (+ the rest of the Cloud team)
[1] https://phabricator.wikimedia.org/T161899
_______________________________________________
Wikimedia Cloud Services announce mailing list
Cloud-announce(a)lists.wikimedia.org (formerly labs-announce(a)lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/cloud-announce
I'm trying to debug a PHP script that runs various queries against the enwiki_p database on the new server (enwiki.analytics.db.svc.eqiad.wmflabs), and I've run into a wall. To simplify the question, I'm running three SQL queries in succession using mysqli_query. The first two queries return results as expected, but the third one doesn't. It just hangs the script indefinitely until the server times out. If I go into the MariaDB client while the script is running and try SHOW FULL PROCESSLIST, it shows the script's connection is sleeping.
Here's what has me stumped: if I comment out the first two queries and just submit the third, it runs fine and returns the data I am looking for. So I know it's not an error in my query string or in PHP syntax. Am I running up against some limit on successive queries? What should I be doing differently?
If it makes a difference, none of these are extremely slow queries. Each one separately completes in about 30-60 seconds depending on server load.
Sent from my iPhone
Sorry for cross-posting!
Reminder: Technical Advice IRC meeting again **tomorrow 3-4 pm UTC** on
#wikimedia-tech.
The Technical Advice IRC meeting is open for all volunteer developers,
topics and questions. This can be anything from "how to get started" over
"who would be the best contact for X" to specific questions on your project.
If you know already what you would like to discuss or ask, please add your
topic to the next meeting: https://www.mediawiki.org/
wiki/Technical_Advice_IRC_Meeting
This meeting is an offer by WMDE’s tech team.
Hope to see you there!
Michi (for WMDE’s tech team)
--
Michael F. Schönitzer
Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
http://wikimedia.de
Stellen Sie sich eine Welt vor, in der jeder Mensch an der Menge allen
Wissens frei teilhaben kann. Helfen Sie uns dabei!
http://spenden.wikimedia.de/
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
On Sun, Oct 8, 2017 at 8:22 AM, Fæ <faewik(a)gmail.com> wrote:
> On 8 October 2017 at 15:06, Nitin Gadia <nittyjee(a)gmail.com> wrote:
>> Why am I being sent emails? Where did this come from?
>
> See https://wikitech.wikimedia.org/wiki/User:BryanDavis/Rebranding_Cloud_Servic…
>
> The WMF marketing/rebranding exercise included renaming the email list
> you were subscribed to. It may be less confusing if the footer of the
> email list mentioned the previous name; probably for at least 12
> months.
Thanks for the suggestion Fæ. I've updated the mailman footer settings
to include "(formerly labs-l(a)lists.wikimedia.org)" and made the
displayed list name more descriptive. I have also made similar changes
for the cloud-announce(a)lists.wikimedia.org list.
Bryan
--
Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org>
[[m:User:BDavis_(WMF)]] Manager, Cloud Services Boise, ID USA
irc: bd808 v:415.839.6885 x6855
I deployed a new version of the jsub command at 2017-10-05T22:42Z. The
major change was porting the script from Python2 to Python3.
Unfortunately I did not test all code paths with the new script. When
invoked as `jstart` or `jsub -continuous ...` it would fail with an
error [0]:
Traceback (most recent call last):
File "/usr/bin/jstart", line 662, in <module>
main()
File "/usr/bin/jstart", line 654, in main
(out, err) = proc.communicate(qsub_stdin)
File "/usr/lib/python3.4/subprocess.py", line 960, in communicate
stdout, stderr = self._communicate(input, endtime, timeout)
File "/usr/lib/python3.4/subprocess.py", line 1602, in _communicate
input_view = memoryview(self._input)
TypeError: memoryview: str object does not have the buffer interface
At 2017-10-06T15:33Z I deployed a fix for this problem. `jstart` and
`jsub -continuous ...` are now working again. I apologize for the
interruption of service. I'm going to try and add an automated test
for this code path to help catch any similar errors in the future.
[0]: https://phabricator.wikimedia.org/T177614
Bryan
--
Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org>
[[m:User:BDavis_(WMF)]] Manager, Cloud Services Boise, ID USA
irc: bd808 v:415.839.6885 x6855
Hi,
Sometimes I get questions on how to control queries running for longer
than intended on the wikireplicas. Since MariaDB 10.1 (the version
used on tools and the new wikireplicas), one can run:
SET max_statement_time = 300; [0]
And all subsequent queries on the same connection will be killed if
the run longer than 5 minutes. For example:
mariadb[(none)]> SET max_statement_time = 10;
Query OK, 0 rows affected (0.00 sec)
mariadb[(none)]> SELECT sleep(20);
+-----------+
| sleep(20) |
+-----------+
| 1 |
+-----------+
1 row in set (10.00 sec)
It works on quarry, too! [1] But not on the old wikireplicas.
This is of course not required, but 1) it will win you karma, by
making your requests not run longer you intended (making resources
available for others), and 2) it can limit the execution on web-based
tools, as it is unlikely that a user will wait for longer than 1-5
minutes on a browser- an error will be a better feedback and a freezed
loading page.
Regards,
[0] <url:https://mariadb.com/kb/en/library/server-system-variables/#max_statemen…>
[1] <url:https://quarry.wmflabs.org/query/22003>
--
Jaime Crespo
<http://wikimedia.org>
A proposal is up in <https://phabricator.wikimedia.org/T177427> to
move the notification bots (icinga-wm, shinken-wm, wikibugs) out of
the #wikimedia-cloud Freenode IRC channel and into a channel primarily
intended for notifications/monitoring. The intent of this change would
be to make #wikimedia-cloud less noisy for support questions and
discussions between Cloud Services users.
Your feedback is welcome.
Bryan
--
Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org>
[[m:User:BDavis_(WMF)]] Manager, Cloud Services Boise, ID USA
irc: bd808 v:415.839.6885 x6855