In the next RFC meeting, we will discuss the following RFC:
* Business Layer Architecture on budget
<https://www.mediawiki.org/wiki/Requests_for_comment/Business_Layer_Architec…>
The meeting will be on the IRC channel #wikimedia-office on
chat.freenode.net at the following time:
* UTC: Wednesday 21:00
* US PDT: Wednesday 14:00
* Europe CEST: Wednesday 23:00
* Australia AEST: Thursday 07:00
-- Tim Starling
>From http://www.artima.com/weblogs/viewpost.jsp?thread=362327 :
That software systems are getting bigger and more pervasive is testament
that we can at times muster the wherewithal to manage the inherent
complexity of constructing large systems. At other times, however, it
simply supports the view that creating complexity is far easier than
hiding it — the creeping featurism, physical size, and bugginess of
certain operating systems and wordprocessing packages is tantamount to a
public admission of software engineering failure. To paraphrase Blaise
Pascal, "The software to solve your problem is larger and more complex
than necessary, because we did not have the ability or resources to make
it smaller and simpler."
[...]
In other words, leaving or taking things out by constantly examining the
difference between inherent and actual complexity, questioning and
reducing the number of features, and questioning and reducing the amount
of code. For benighted management that still measures productivity in
terms of KLOCs, this is scary: it appears to represent negative
productivity. But... less code, fewer bugs... fewer features, greater ease
of use... and so on.
This leads to an interesting marketing possibility, and one that I have
seen in action only a few times: the idea that a subsequent release of a
product might be smaller or have fewer features than the previous version,
and that this property should be considered a selling point. Perhaps the
market is not mature enough to accept it yet, but it remains a promising
and classic ideal — less is more.
Hello Labs project maintainers,
Today is your last chance to reboot any instances you may be running
that have Ubuntu Precise and have not been rebooted since my
notification last week!
All instances how have a /usr/local/sbin/reboot-if-idmap script
installed which, if run by root or with sudo, will reboot any instance
iff it still needs to be rebooted. (Specifically, it does the exact
feature test and does nothing if it passes).
== What happens if you don't reboot ==
At some point tomorrow (Apr 23, around 14h UTC) idmap[1] will be turned
off on the labs storage servers. Instances that are still trying to use
idmap will loose the ability to access files in /home and /data/project
that are not globally readable (or writable, as the case may be). This
may impact processes running on those instances in various ways.
Again, only instances that are running Ubuntu Precise and that have not
been rebooted (for any reason) since Apr 13, 2015 12h UTC are affected.
If in doubt, you can safely run the reboot-if-idmap script - it will
have no effect on instances that do not neet reboot or have already been
rebooted.
Thank you,
-- Marc
---------- Forwarded message ----------
From: Keegan Peterzell <kpeterzell(a)wikimedia.org>
Date: Wed, Apr 22, 2015 at 1:34 AM
Subject: Re: [Foundation-l] Single login - decision 2004
To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org>
On Nov 11, 2004, at 03:27:00 UTC , Erik Moeller <erik_moeller(a)gmx.de> wrote
[1]:
> Hi,
> there's been some movement forward on the Single User Login (SUL) issue. I
>
> ask the Board to review this mail carefully as this has significant long-
> term implications and we need Board input to go ahead. I also ask other
> developers to correct me if I misrepresent anything.
> There are currently three competing strategies. Before I describe these
> strategies, let me point out that one important consideration for any
> system is scalability. That is, single login will be used on all existing
> and future Wikimedia projects, and potentially even on non-Wikimedia sites
>
> which we allow to participate in our system.
> The three strategies are:
> 1) GLOBAL NAMESPACE, IMMEDIATE CONFLICT RESOLUTION
> We try to move towards a single global user namespace for all Wikimedia
> wikis. If a name is already taken in the global namespace, you have to
> find one which isn't.
> For the migration, any names which clearly belong to the same user are
> combined into one. If passwords and email addresses are different, the
> user can manually link together any accounts which belong to him by
> providing the passwords.
> For cases of true name conflicts between the existing wikis, there is a
> resolution phase, where factors like seniority, use on multiple wikis vs.
> a single one, etc., are weighed in - the "loser" has to choose a new
> account name.
> After the manual resolution phase, any remaining accounts are converted to
>
> the new system automatically by making them unique, e.g. by adding a
> number to the username. The transition is now complete. The old system no
> longer exists.
---
> 1) is very complex, and we may not find someone willing to deal with the
> name conflict resolution issue and take the blame from annoyed users at
> the same time. Naming conflicts will always be an issue in this scheme, as
>
> e.g. all common first names will be taken, and any small wiki hooking up
> with our SUL system would feel this impact. People can mutate these
> usernames relatively easily to make them unique - Erik333 - and the system
>
> can offer such mutations, but it's still a bit annoying.
This is now complete [2]. That wasn't too bad.
1.
https://lists.wikimedia.org/pipermail/wikimedia-l/2004-November/061327.html
2. https://lists.wikimedia.org/pipermail/wikimedia-l/2015-April/077576.html
--
Keegan Peterzell
Community Liaison, Product
Wikimedia Foundation
--
Keegan Peterzell
Community Liaison, Product
Wikimedia Foundation
Hey all,
Over the past months our main MediaWiki PHPUnit run slowed down a lot. Some of that is attributed to our unit tests using too much database integration [1]. Another significant portion is attributed to the switch to MySQL. The overhead was especially significant for Precise instances and PHP Zend.
While MySQL is heavier than SQLite, it generally does perform better at scale, caching, and with concurrent requests from the web. However we lost a lot compared to SQLite because our SQLite wasn't on disk but in a tmpfs mount.
Last week we worked on adding a tmpfs mount to our Jenkins slaves and configuring MySQL to store its data there instead.
Our average build time went from 20 minutes (zend) and 8 minutes (hhvm) to 9 minutes and 4 minutes!
For the impact on the average build time trend graphs, see https://phabricator.wikimedia.org/T96230#1215473 <https://phabricator.wikimedia.org/T96230#1215473>
There's still room for more optimisations, which are tracked at https://phabricator.wikimedia.org/T96249 <https://phabricator.wikimedia.org/T96249>.
— Krinkle
[1] https://phabricator.wikimedia.org/T93556 <https://phabricator.wikimedia.org/T93556>
Greetings,
I am pleased to announce that nominations are now being accepted for the
2015 Wikimedia Foundation Elections. This year the Board and the FDC Staff
are looking for a diverse set of candidates from regions and projects that
are traditionally under-represented on the board and in the movement as
well as candidates with experience in technology, product or finance. To
this end they have published letters
<https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections_2015/Call_fo…>
describing
what they think is needed and, recognizing that those who know the
community the best are the community themselves, the election
committee is accepting
nominations
<https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections_2015#Informa…>
for
community members you think should run and will reach out to those
nominated to provide them with information about the job and the election
process.
This year, elections are being held for the following roles:
*Board of Trustees*
The Board of Trustees is the decision-making body that is ultimately
responsible for the long term sustainability of the Foundation, so we value
wide input into its selection. There are three positions being filled.
More information about this role can be found at
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections_2015/Board_e….
*Funds Dissemination Committee (FDC)*
The Funds Dissemination Committee (FDC) makes recommendations about how to
allocate Wikimedia movement funds to eligible entities. There are five
positions being filled. More information about this role can be found at
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections_2015/FDC_ele…
.
*Funds Dissemination Committee (FDC) Ombud*
The FDC Ombud receives complaints and feedback about the FDC process,
investigates complaints at the request of the Board of Trustees, and
summarizes the investigations and feedback for the Board of Trustees on an
annual basis. One position is being filled. More information about this
role can be found at
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections_2015/FDC_Omb…
.
The candidacy submission phase lasts from 00:00 UTC April 20 to 23:59 UTC
May 5 for the Board and from 00:00 UTCApril 20 to 23:59 UTC April 30 for
the FDC and FDC Ombudsperson. This year, we are accepting both
self-nominations and nominations of others. More information on this
election and the nomination process can be found at
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections_2015.
Please feel free to post a note about the election on your project's
village pump. Any questions related to the election can be posted on the
talk page on Meta, or sent to the election committee's mailing list,
board-elections(a)wikimedia.org
On behalf of the Elections Committee,
-Gregory Varnum (User:Varnent)
Coordinator, 2015 Wikimedia Foundation Elections Committee
Previous announcement:
https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2014-September…
During the 1.25 development cycle, the API has been warning you if you're
specifying neither the "continue" nor "rawcontinue" parameters to
action=query. Recently this warning was targeted more specifically to
queries that actually return continuation data. The time is coming soon for
making this change, so please check your bots, bot frameworks, scripts, and
so on to ensure that you won't be broken when this change is made.
If you want to continue using your existing continuation code unchanged,
all you need to do is add the "rawcontinue" parameter to your action=query
queries.
If you'd rather change to the easier-to-get-right new style, add an empty
"continue" parameter to your initial action=query queries. See
https://www.mediawiki.org/wiki/API:Query#Continuing_queries for details on
the new mechanism.
If you do nothing, sometime in the next few months your code will likely
start thinking that no queries ever need continuation when the default is
changed to return the new 'continue' node rather than the old
'query-continue'. I'll send an announcement when the specific date is
decided, but I don't promise more than a week's notice.
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
Hi Everyone,
I'd like to welcome Madhu to the Analytics team. We are very excited about
bringing her skills and experience to the team. She'll be based in San
Francisco and sitting with the Analytics team on the third floor.
In her own words:
I grew up in India, for most part in Chennai, and finished my undergrad in
IT 3 years back. I was always into computers and programming but had not
had much "exposure". During college I met the legendary Yuvi Panda and
other folks in the "Chennai Geek" community, who introduced me to linux,
open source software, the Google Summer of Code program and got me started.
I started by participating the GSoC program for Gnome, moved on to work for
a company in the US, remote, for 2 years. I spent all my free time learning
Python, doing hobby projects, organizing hackathons, meetups in the tech
community in my city, etc. Last year, I quit to go to Hacker School in New
York, which I did twice!
Post Hacker School, I started looking for work, applied to the foundation,
and 7 interviews and 3 months of visa wait later, here I am :) Super
excited to be here!
Welcome Madhu!
-Toby
In relation to
Engage with established technical communities at the Wikimedia Hackathon
2015
https://phabricator.wikimedia.org/T76325
Are there any specific developers of any related communities that you would
like to invite to Lyon? We can talk about travel sponsorship if it's
reasonable.
I have asked directly to the owners of the main areas of the event [1] in
the related tasks. If you have good proposals in relation to other projects
planned, please share them as well at
https://phabricator.wikimedia.org/T76325
The sooner the better, since there is not much time left.
[1] https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2015#Main_areas
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil