Hello,
Jenkins jobs start failing on some repositories release branches because
they are lacking the CI [entry points]. For example if the 'npm' job
has been enabled, the master branch has a 'package.json' but the release
branches do not. That causes CI to reject backports.
I would like us to update our repositories REL1_24 and REL1_25 branches
with package.json and composer.json whenever they are present in master.
The commands being run would need be tweaked but at the very minimal
each branches should check:
* the i18n files using grunt-banana-checker (in package.json)
* php lint (jakub-onderka/php-parallel-lint) (in composer.json)
Repositories that haven't switched yet are not impacted nor are the
branches already having the package.json/composer.json files.
[entry points]
https://www.mediawiki.org/wiki/Continuous_integration/Entry_points
--
Antoine "hashar" Musso
I'm not sure, if an overall new skin is a really good idea. In my opinion, Wikipedia (and other wmf wikis) needs the experienced users, as well as "the person who think, that Wikipedia is written by paid people". While the first group could maybe handle a complete new skin, i'm sure, that all others will be very confused, which is not the goal, i think.
Vector itself doesn't look "so old" in my opinion and with the MediaWiki skin in OOUI it's possible to built a modern UI which perfectly fits into Vector.
While I like new designs, i don't think, that we need a new skin to replace vector (but that's only my opinion)
Gesendet mit meinem HTC
----- Nachricht beantworten -----
Von: "Ricordisamoa" <ricordisamoa(a)openmailbox.org>
An: <wikitech-l(a)lists.wikimedia.org>
Betreff: [Wikitech-l] Question: Should wikimedia wikis such as wikipedia be updated with a user frendly desgn
Datum: Mi., Sep. 9, 2015 15:57
There is some work about getting the mobile skin on desktop (T71366
<https://phabricator.wikimedia.org/T71366>), and Blueprint
<https://www.mediawiki.org/wiki/Skin:Blueprint> powers the Living Style
Guide.
However, no matter how ancient Vector may look, the little updates it
has received over the years make me think it isn't that bad for those
who use it.
Il 08/09/2015 19:53, Thomas Mulhall ha scritto:
> Hi this is a question but shoulden Wikimedia wikis such as Wikipedia be updated with a user friendly design. Currently vector is coming out of date because now a days you see sites with bruitiful colours not old ones as they were in 2010 when vector came out. We could create another skin to replace vector as we did with monobook or update vector with a new look that has bold colours and goes along with mediawiki code and is also mobile optimised even though we have the mobilefrontend extension some users may not want to install instead hoping the skin is mobile optimised.
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Dear Greg, and anyone else that is involved in deployment
This is a follow-up from Dan Duvall's talk today during the metrics
meeting about voting browser tests.
Background:
The reading web team this quarter with the help of Dan Duvall has made
huge strides in our QA infrastructure. The extensions Gather,
MobileFrontend and now the new extension QuickSurveys are all running
browser tests on a per commit basis. A selected set of MobileFrontend
@smoke tests (a selected subset of all he tests) are running in
15minutes on every commit and the entire set of Gather browser tests
is running in around 21minutes. It marginally slows down getting
patches deployed... but I think this is a good thing. The results
speak for themselves.
In the past month (August 4th-September 4th) only 3/33 builds failed
for MobileFrontend's daily smoke test build [1] (all 3 due to issues
with the Jenkins infrastructure). For the full set of tests only 10/33
failed in the Chrome daily build [3], 8 of which were due to tests
being flakey and needing improvement or issues with the Jenkin
infrastructure and the two others serious bugs [4,5] brought about by
work the performance team had been doing that we were able to fix
shortly after.
In Firefox [2] there were only 6 failures and only 2 of these were
serious bugs, again caused by things outside MobileFrontend [4,6]. One
of these was pretty serious - we had started loading JavaScript for
users with legacy browsers such as IE6. These were caught prior to the
daily builds when suddenly our MobileFrontend commits would not merge.
The future!:
Given this success:
1) I would like to see us run @integration tests on core, but I
understand given the number of bugs this might not be feasible so far.
2) We should run @integration tests prior to deployments to the
cluster via the train and communicate out when we have failures (and
make a decision to push broken code)
3) I'd like to see other extensions adopt browser test voting on their
extensions. Please feel free to reach out to me if you need help with
that. The more coverage across our extensions we have, the better.
We really have no excuse going forward to push broken code out to our
users and at the very least we need to be visible to each other when
we are deploying broken code. We have a responsibility to our users.
Thoughts? Reactions? Who's with me?!
[1] https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFro…
[2] https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFro…
[3] https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFro…
[4] https://phabricator.wikimedia.org/T108045
[5] https://phabricator.wikimedia.org/T108191
[6] https://phabricator.wikimedia.org/T111233
Hi all!
We have some breaking API changes that will soon be deployed to wikidata.org.
The deployment date should be: 9th September 2015 (just under 2 weeks)
The change making the breaks an be found at:
https://gerrit.wikimedia.org/r/#/c/227686/
The breaking changes are:
- XML output aliases are now grouped by language
- XML output may no longer give elements when they are empty
- XML any claim, qualifier, reference or snak elements that had an
'_idx' element will no longer have it
- ALL output may now give empty elements, ie. labels when an entity has none
If you want to see a wikipage explaining these changes take a look at:
https://www.wikidata.org/wiki/User:Addshore/API_Break_September_2015
If you have any questions regarding these breaking changes please ask!
Addshore
There is consensus at
https://www.mediawiki.org/wiki/Talk:Code_of_conduct_for_technical_spaces/Dr…
that the best way to finalize the CoC draft is to focus on a few
sections at once (while still allowing people to comment on other
ones). This allows progress without requiring people to monitor all
sections at once and lets us separate the questions of “what are our
goals here?” and “how should this work?”. After these sections are
finalized, I recommend minimizing or avoiding later substantive
changes to them.
The first sections being finalized are the intro (text before the
Principles section), Principles, and Unacceptable behavior. These
have been discussed on the talk page for the last two weeks, and
appear to have stabilized.
However, there may still be points that need to be refined. Please
participate in building consensus on final versions of these sections:
* https://www.mediawiki.org/wiki/Talk:Code_of_conduct_for_technical_spaces/Dr…
* https://www.mediawiki.org/wiki/Code_of_conduct_for_technical_spaces/Draft
If you are not comfortable contributing to this discussion under your
name or a pseudonym, you can email your feedback or suggestions to
conduct-discussion(a)wikimedia.org . Quim Gil, Frances Hocutt, and
Kalliope Tsouroupidou will be monitoring this address and will
anonymously bring the points raised into the discussion at your
request.
Thanks,
Matt Flaschen
[x-posted announcement]
Hello,
The next office hour of the Wikimedia Language Engineering team is
scheduled for next Wednesday, September 16th at 15:00 UTC. Like our last
office hour, this time also we are hosting it as an online discussion over
Hangout/Youtube with a simultaneous IRC conversation. Due to the limitation
of Google Hangouts, only a limited number of slots are available. Hence, do
let us know (on the event page
<https://plus.google.com/u/0/events/c1c0msurhua7enopsu3q8l42j3s>) if you
would like to participate on the Hangout. The IRC channel #wikimedia-office
and the Q&A channel for the youtube broadcast will be open for interactions
during the session.
Our last online round-table session was held in June 2015. You can watch
the recording here: https://www.youtube.com/watch?v=vbXyHmpZJGE
Please read below for the event details and do let us know if you have any
questions.
Thank you
Runa
== Details ==
# Event: Wikimedia Language Engineering office hour session
# When: September 16th, 2015 (Wednesday) at 15:00 UTC (check local time
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150916T1500)
# Where: https://plus.google.com/u/0/events/c1c0msurhua7enopsu3q8l42j3s and
on IRC #wikimedia-office (Freenode)
# Agenda: Content Translation updates and Q & A
--
Language Engineering Manager
Outreach and QA Coordinator
Wikimedia Foundation
I talked to Charlotte SH Jensen at the National Museum in Copenhagen yesterday.
We've been talking and doing stuff for several years, so we have a
huge backlog of ideas that didn't work, but we're still able to find
new things to do.
One idea that came up yesterday is rotating pictures on Wikipedia. We
hope to get people to do something at the #hack4dk hackathon in early
October.
See the idea at
https://hackdash.org/projects/55e99d6174d6ac1d21451575, and more about
#hack4dk at http://hack4.dk/
Regards,
Ole Palnatoke Andersen, Wikimedia Danmark
--
http://palnatoke.org * @palnatoke * +4522934588
Hi everyone,
Aaron did a great job leading the discussion about "Master/slave
datacenter strategy for MediaWiki" (T88666). Someone (maybe you!)
will publish a link to the IRC conversation, and someone (maybe you!)
will make our IRC transcripts from #wikimedia-office more robustly
stored. Spoiler alert: it was approved!
At any rate, we (Architecture Committee) haven't yet selected what the
discussion topic of next week's IRC meeting should be. The board here
is kind of a mess:
https://phabricator.wikimedia.org/tag/mediawiki-rfcs/
I have it as a TODO to completely rework that board, but I'm not doing
it by next week. What RfC needs attention now?
Rob