Hi,
On Tue, Mar 1, 2016 at 3:36 PM, David Strine <dstrine(a)wikimedia.org> wrote:
> We will be holding this brownbag in 25 minutes. The Bluejeans link has
> changed:
>
> https://bluejeans.com/396234560
I'm not familiar with bluejeans and maybe have missed a transition
because I wasn't paying enough attention. is this some kind of
experiment? have all meetings transitioned to this service?
anyway, my immediate question at the moment is how do you join without
sharing your microphone and camera?
am I correct thinking that this is an entirely proprietary stack
that's neither gratis nor libre and has no on-premise (not cloud)
hosting option? are we paying for this?
-Jeremy
As of 950cf6016c, the mediawiki/core repo was updated to use DB_REPLICA
instead of DB_SLAVE, with the old constant left as an alias. This is part
of a string of commits that cleaned up the mixed use of "replica" and
"slave" by sticking to the former. Extensions have not been mass
converted. Please use the new constant in any new code.
The word "replica" is a bit more indicative of a broader range of DB
setups*, is used by a range of large companies**, and is more neutral in
connotations.
Drupal and Django made similar updates (even replacing the word "master"):
* https://www.drupal.org/node/2275877
* https://github.com/django/django/pull/2692/files &
https://github.com/django/django/commit/beec05686ccc3bee8461f9a5a02c607a023…
I don't plan on doing anything to DB_MASTER, since it seems fine by itself,
like "master copy", "master tape" or "master key". This is analogous to a
master RDBMs database. Even multi-master RDBMs systems tend to have a
stronger consistency than classic RDBMs slave servers, and present
themselves as one logical "master" or "authoritative" copy. Even in it's
personified form, a "master" database can readily be thought of as
analogous to "controller", "governer", "ruler", lead "officer", or such.**
* clusters using two-phase commit, galera using certification-based
replication, multi-master circular replication, ect...
**
https://en.wikipedia.org/wiki/Master/slave_(technology)#Appropriateness_of_…
***
http://www.merriam-webster.com/dictionary/master?utm_campaign=sd&utm_medium…
--
-Aaron
O'Reilly just published some of their popular books for free, either as
part of open access movement or some kind of marketing (or both). I find
them useful to Wikimedia developers. It supports several types of e-books
so you can read it in your kindle, etc.:
* Performance, Operations, Release engineering:
http://www.oreilly.com/webops-perf/free/
* Data, AI, Analytics: http://www.oreilly.com/data/free/
* Programming, architecture, Open source culture:
http://www.oreilly.com/programming/free/
* Security: http://www.oreilly.com/security/free/
* Web platform, design: http://www.oreilly.com/web-platform/free/
This is a rather unusual type of email so I wasn't sure I was doing the
right thing so I just sent it to wikitech-l. Please spread the word if you
think it's okay or tell me if you think not. Thanks.
Best
Hi everybody!
As a reminder the CREDIT Showcase is next week on Wednesday,
1-February-2017 (see https://www.mediawiki.org/wiki/CREDIT_showcase for
details). Also, as I mentioned previously we're conducting a survey about
CREDIT. We'd appreciate your feedback! Here is a link to the survey (which
is hosted on a third-party service), and, for information about privacy and
data handling, the survey privacy statement.
https://docs.google.com/a/wikimedia.org/forms/d/e/1FAIpQLSedAtyPfcEhT6OVd26…https://wikimediafoundation.org/wiki/CREDIT_Feedback_Survey_Privacy_Stateme…
.
This email is being sent to several mailing lists in order to reach
multiple audiences. As always, please follow the list link at the very
bottom of this email in case you want to manage your list subscription
options such as digest, unsubscribe, and so on.
And, as usual, if you'd like to share the news about the upcoming CREDIT,
here's some suggested verbiage.
*Hi <FNAME>*
*I hope all is well with you! I wanted to let you know about CREDIT, a
monthly demo series that we’re running to showcase open source tech
projects from Wikimedia’s Community, Reading, Editing, Discovery,
Infrastructure and Technology teams. *
*CREDIT is open to the public, and we welcome questions and discussion. The
next CREDIT will be held on February 1st at 11am PT / 2pm ET / 19:00 UTC. *
*There’s more info on MediaWiki
<https://www.mediawiki.org/wiki/CREDIT_showcase>, and on Etherpad
<https://etherpad.wikimedia.org/p/CREDIT>, which is where we take notes and
ask questions. You can also ask questions on IRC in the Freenode chatroom
#wikimedia-office (web-based access here
<https://webchat.freenode.net/?channels=%23wikimedia-office>). Links to
video will become available at these locations shortly before the event.*
*Please feel free to pass this information along to any interested folks.
Our projects tend to focus on areas that might be of interest to folks
working across the open source tech community: language detection,
numerical sort, large data visualizations, maps, and all sorts of other
things.*
*If you have any questions, please let me know! Thanks, and I hope to see
you at CREDIT.*
*YOURNAME*
Thanks!
Adam Baso
Director of Engineering, Reading
Wikimedia Foundation
abaso(a)wikimedia.org
The Parsing team at the Wikimedia Foundation that develops the Parsoid
service is deprecating support for node 0.1x. Parsoid is the service
that powers VisualEditor, Content Translation, and Flow. If you don't
run a MediaWiki install that uses VisualEditor, then this announcement
does not affect you.
Node 0.10 has reached end of life on October 31st, 2016 [1] and node
0.12 is scheduled to reach end of life December 31st, 2016 [1].
Yesterday, we released a 0.6.1 debian package [2] and a 0.6.1 npm
version of Parsoid [3]. This will be the last release that will have
node 0.1x support. We'll continue to provide any necessary critical bug
fixes and security fixes for the 0.6.1 release till March 31st 2017 and
will be completely dropping support for all node versions before node
v4.x starting April 2017.
If you are running a Parsoid service on your wiki and are still using
node 0.1x, please upgrade your node version by April 2017. The Wikimedia
cluster runs node v4.6 right now and will soon be upgraded to node v6.x
[4]. Parsoid has been tested with node 0.1x, node v4.x and node v6.x and
works with all these versions. However, we are dropping support for node
0.1x right away from the master branch of Parsoid. Going forward, the
Parsoid codebase will adopt ES6 features available in node v4.x and
higher which aren't supported in node 0.1x and will constitute a
breaking change.
Subramanya Sastry (Subbu),
Technical Lead and Manager,
Parsing Team,
Wikimedia Foundation.
[1] Node.js Long Term Support schedule @ https://github.com/nodejs/LTS
[2] https://www.mediawiki.org/wiki/Parsoid/Releases
[3] https://www.npmjs.com/package/parsoid
[4] https://phabricator.wikimedia.org/T149331
There is a security fix to ensure that EnableFlow is always properly
attributed.
This may be an issue if you see users maliciously using
Special:EnableFlow on pages that already exist.
It should be merged shortly, but in the meantime, you can download it
from Gerrit (https://gerrit.wikimedia.org/r/#/c/333301/):
git fetch ssh://gerrit.wikimedia.org:29418/mediawiki/extensions/Flow
refs/changes/01/333301/1 && git checkout FETCH_HEAD
Matt Flaschen
Hello Wikitext-l,
-----------------------------------
TL;DR: The Wikidata team is considering to use a MVVM/Single-State solution
for Wikidata’s UI. What are requirements and concerns would be important to
consider?
-----------------------------------
Wikidata’s current UI is built on jQuery UI. Since jQueryUI shall be faded
out, we are looking at possible future frameworks or paradigms to build our
UI on. Our needs are:
- Having a sustainable foundation
- Being able to handle complex state dependencies (simplest are like: "if
element x is in edit mode, set element y to saving mode")
- A solution that is easy to learn for beginners and easy to read and
reason about for our engineers.
State management and data/event propagation goes beyond of what OOUI can
provide, as far as I (Jan) know. So an obvious candidate was looking into
MVVM solutions of which the most well known is the React library.
We had a deeper look at Vue.js which is known for having a large community,
too, but being easier to understand and not using an additional patent
clause in its licensing.
We see the following possible advantages:
- Better modularization
- understandability of our code, in particular reasoning about event- and
data-flow
- better separation of concerns and testability for:
-- HTML templates
-- Component interactivity
-- Data manipulation
-- connection to backend-API
- If we use a well documented framework, learning to contribute is much
easier compared to software for which there is only auto-generated
code-level-docs
Here are some answers to obvious questions:
1) Does using a MVVM mean we need to write mixed JS/CSS/HTML in a new
syntax? (aka JSX)? -> No, it is possible, but for most frameworks (Vue,
too) normal HTML templates are used
2) Does that mean that people coming from Object oriented languages will
need to learn a whole new paradigm – reactive, pure-functional programming?
-> While there are some elements of functional programming used in
react-like-frameworks, I would (subjectively) say that few additional,
totally new knowledge is needed and most can be covered by "take
parameters, work with them, return values; don't manipulate non-local
values"
3) How does DOM access work? Does this mean no jQuery?
-> DOM can be still be directly accessed. Libraries like jQuery can still
be reused (even if they might not be necessary in many points any more).
However, to change data or dom persistently, you need to tell the library
(which is not unusual, afaic)
There are also some other concerns:
- Should we introduce a new dependency like a framework as Vue?
- What would be the process of introducing such a dependency (if we agree
on one)?
- Can we agree on this (or another?) paradigm for managing complex UIs, so
that it is not a Wikidata-only solution, but could be used by other
Wikimedia projects in the future, too?
- How will this work with OOUIjs? OOUI seems to be mainly responsible for
creating DOM elements and this actions are usually owned by the MVVM
framework. One can use hooks to use libraries like OOUI and such, but it
feels like having the same functionality twice. A possible solution would
be using OOUI styles and markup but leaving DOM creation to the framework.
Do you think using Vue (or a similar framework) is an option for us? What
are requirements and concerns which would be important?
Kind Regards,
Jan
--
Jan Dittrich
UX Design/ User Research
Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30 219 158 26-0
http://wikimedia.de
Imagine a world, in which every single human being can freely share in the
sum of all knowledge. That‘s our commitment.
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/029/42207.
Hi,
The Architecture Committee plans to make a decision in two weeks on the RFC
about the schema change for image and oldimage tables. [1] [2]
Please review the updated RFC page [2] and send any final comments here on
Wikitech-l or Phabricator [1] by 2017-02-01. If no new and significant
concerns are raised within this time the committee will most likely approve
the RFC on Wednesday, February 1st.
-- Timo
[1] https://phabricator.wikimedia.org/T589
[2] https://www.mediawiki.org/wiki/Requests_for_comment/
image_and_oldimage_tables