Yeah, that's right. What I meant to say (and thought I had said in
some form later in that message) was that the puppet repo has
post-commit review for most changes by ops staff, and pre-commit
review for everything else (non-ops staff, volunteers, and certain
changes by ops staff in some
I became curious with these statements regarding self-review
(committer==reviewer) and so I ran a couple
of queries against the gerrit database to see how often this occurs:
1) For the puppet repo, 84.1% of the commits is self-reviewed.
2) For the mediawiki core repo, 27.9% of the commits
Yeah, I don't think Ops is proud of this, but from my understanding,
it's very difficult to develop for puppet without committing and
seeing what happens. It's possible, but it's definitely not as
productive.
That's not true anymore. It's been possible to fully test puppet
manifests before
(Also, this isn't counting people who contribute to the mobile projects
on GitHub, and really the final monthly report stat ought to. I don't
quickly see a way to ask how many unique contributors submitted unique
pull requests to a https://github.com/wikimedia/ repo in June? on
GitHub,
On Wed, Jul 18, 2012 at 1:18 PM, Petr Bena benap...@gmail.com wrote:
What about changing gerrit to our needs? It's open source, I suppose.
That's of course the route we're going right now. The biggest hurdle
to doing so is that it's written in Java, and Prolog. Neither of those
languages are
Given that we are going to use labsconsole wiki (which is later going
to be renamed to wikitech) as a documentation base for various
software and server documentation, we should propose a way how this
new documentation base is going to be organized.
I would prefer to create new namespace
On Thu, Jul 19, 2012 at 11:55 PM, Antoine Musso hashar+...@free.fr wrote:
Daniel Friesen wrote:
The ops guys hate ruby.
I am pretty sure they love it. Puppet itself is a DSL based on top of
ruby. The ops argument is we don't want to handle security updates and
nasty performance bug for yet
I think the we is a bit unwarranted. I don't hate Ruby and I certainly
don't hate Ruby more than Java :-) I also don't feel the same about
puppet; I do see some problems with it, but none of them have nothing to
do with the fact that it's written in Ruby.
Well, 90% of the ops team.
I think
But do we have a plan for improving Gerrit in a substantial way?
Gerrit releases often and every release is quite better than the last.
Chad can and has been pushing changes upstream. OpenStack (which has
180+ companies that can potentially assist), QT, and other substantial
communities are
* What does GitHub Enterprise buy us? Which of these issues would that fix?
It's a self-hosted GitHub. It would allow us to have private
repositories (good for deploys, ops, etc.) and manage our own user database
(we could integrate with our own auth system) and probably waives the
I'm trying to understand the differences between:
*phpMyAdmin
*SAML
*OpenID
*OpenVPN
You should only consider SAML and OpenID. More exactly, you should
really only consider SAML, since the resources you are trying to
connect to only support SAML, and not OpenID. We can use OpenID for
We're discussing alternatives to *gerrit*, not to git.
Heh. Sorry, yes. that's what I meant.
- Ryan
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Jul 26, 2012 at 7:04 PM, MZMcBride z...@mzmcbride.com wrote:
Rob Lanphier wrote:
A few of us are planning to meet Monday afternoon to figure out exactly
what the rest of the process looks like, so that first deadline is going to
be very important for understanding how many options
On Thu, Jul 26, 2012 at 10:57 PM, MZMcBride z...@mzmcbride.com wrote:
Ryan Lane wrote:
You've already admitted that you don't use Gerrit, so do you have a
really large stake in this?
Before it was replaced, I used MediaWiki's CodeReview quite a bit. Like most
people, I think I would use
I did mention how Android used a homemade tool to do the reviews. It was
introduced to me by a friend who is doing Android development for mobile
phone companies. At first I was like: what about the existing google
code or github? Then he explained me their pre commit workflow and it
made me
On Fri, Jul 27, 2012 at 6:42 AM, MZMcBride z...@mzmcbride.com wrote:
Antoine Musso wrote:
MZ, Do you even have a labs account? Your continuous rants are far from
being constructive and makes everyone lose their time.
Nope. I looked at getting one once or twice, but the process seemed too
I was just asking for numbers. Your response looks very like making an
excuse for bad numbers *before we have the numbers*.
I submit that if we know we have to prepare excuses for bad numbers
before we even have the numbers, the current process may not have been
a good idea.
Since the
Since the operations repos have been opened, we've had over 800
changes pushed in from non-operations team members (this includes devs
that have root). That's roughly equivalent to the number of changes
one operations team staff members have pushed in during the same time
period.
As a
On Sun, Jul 29, 2012 at 12:54 PM, Thomas Gries m...@tgries.de wrote:
Yes it _is_ difficult for volunteer developers.
I still find it very difficult and did not commit any new line of code
to gerrit except a coached fix during Berlin Hackathon 2012.
And use github for my daily work now.
Can
The good news for those who aren't so fond of Gerrit is that we do have
some nice alternatives on the horizon, which we can start working with and
improve... we'll be re-evaluating things across the board for core
extensions next year. (Ops can keep Gerrit forever if they like it, that's
not
On Wed, Aug 15, 2012 at 12:00 PM, Thomas Gries m...@tgries.de wrote:
Am 15.08.2012 20:58, schrieb Mark Holmquist:
Saves much time and efforts
You don't use it, otherwise you wouldn't have asked that question.
Clearly--but could you elaborate more as to why it's helpful? (Thomas
is currently
Ryan:
this must be tested.
I think, it NOT possible on the same server (Provider - Consumer)
I didn't say anything about the provider and consumer being on the
same server. The wmflabs prototypes would be consumers that would be
forced to use production Wikimedia as providers.
- Ryan
great, Then simply install it, please
I *didn't* say we should use the openid extension to make the
provider. In fact, I don't think we should.
Also, it's not like it's a simple change. We need to consider how
we'll deal with identity. Some people don't have global accounts. Do
we do identity
On Wed, Aug 15, 2012 at 12:39 PM, Thomas Gries m...@tgries.de wrote:
These are totally *different* things. The Extension can offer both (!)
https://bugzilla.wikimedia.org/show_bug.cgi?id=13631
Wikimedia should become an OpenID provider
I'd love Wikimedia to be a provider, but I'd prefer we
it is not.
OpenID adds only a short table to the database, where the OpenID is
connected with the (local wiki) userid.
Where exactly is the blocking problem for you ?
It's not a technical problem, per se. It's mainly a usability issue.
When you allow login as a consumer, you now have two
it seems, that you have never installed the Extension. Because then you
would not have asked the questions.
I'm working on migrating OpenStack's MoinMoin wiki to MediaWiki. They
use OpenID locked to launchpad's provider. I did the same with the
OpenID MediaWiki extension there. I've also
What is your plan to clean up the mess you made?
I need to call you out on this MZ. This is an incredibly rude way to
phrase this.
I get that our community tends to accept this kind of behavior, but I
think we should really put effort into coming up with some method of
discouraging people from
I think it's important to keep things in perspective, and not to overreact.
If you were treated this way consistently by someone, and the
community defended that person rather than calling them out on their
poor behavior, would you continue to volunteer? Do you expect staff to
continue working
On Fri, Aug 17, 2012 at 11:07 AM, bawolff bawolff...@gmail.com wrote:
That said, I'm not overly irritated. There are a few links I need to
update, but that's doable. Thanks for handling this issue, and for being
responsive to the concerns raised.
While there's 475 links to wikitech-l archives on
I'm not complaining about being called out or even bashed for writing
overly hostile posts. I've done that a few times and I hate it when I
slip up and do it. If I get called out or bashed over that, I've
deserved it, and I'll take it. But what pisses me off is that it's
apparently impossible
On Fri, Aug 17, 2012 at 1:52 PM, Federico Leva (Nemo)
nemow...@gmail.com wrote:
«This is like the 27637862487 time that links have been broken due to the
exact same action.» I can bear hyperboles but this is a bit excessive, and
looks like just another attempt to make this flame bigger: I hope
The link breakage sucks, but it's not my primary concern at this point. My
primary concern is that the archive now appears to be corrupt. Messages have
apparently gone missing from years ago (e.g., the Tim Starling Day
announcement from October 31, 2003) and there are artifacts of messages now
Sincerely, I'm still a little unclear what phrasing you object to here. Just
to be perfectly clear, it's the use of the word mess, right? If so, I can
make note not to use that word going forward on this list.
It may be a regional thing, but where I'm from, when a lot of things get
broken,
I get that our community tends to accept this kind of behavior, but I
think we should really put effort into coming up with some method of
discouraging people from acting this way.
I've long advocated for adopting toolserver-l's mailing list etiquette
guideline on all Wikimedia mailing
On Tue, Aug 21, 2012 at 12:04 PM, Trevor Parscal tpars...@wikimedia.org wrote:
That was unfortunate - I've been ridiculed (by Max) for things I've said
before as well, I feel your pain Ori.
That said however, I generally agree with this piece. I have more faith
than the author seems to have
I most definitely agree - WONTFIXING a request that is a bad idea is
just as important as fixing bugs, or implementing the good ideas. The
art is of course in being able to determine what constitutes a bad
idea and a good idea. Its also important to keep in mind the
community is full of many
But there's a difference between an issue and a solution. Yes, the
templating system is broken, and I'm sure many an editor will confirm that,
but just because a system is broken does not mean Lua is automatically the
solution. To put it in other words: just because people want a better
Most lay users likely won't be able to understand the discussions that
take place on wikitech-l. Hell most lay users don't even know it exists.
Lay users don't write templates either. People who write templates are
wizards. Templates make my eyes bleed and my mind hurt, and I've been
From what I understand lua was not chosen just randomly by throwing a
bunch of languages in a hat,
there were many requirements, such as sandbox-ability, performance
concerns, and ease of implementing
resource limits, etc. If I recall lua came out the clear winner.
This is what I mean when
I quite agree that it's important to actively seek out and work with
template creators and curators to get involved in testing out Lua. But it
is also critical to involve those who will be *using* the templates to see
if what has been designed will address any or all of their concerns and
On Wed, Aug 22, 2012 at 1:24 PM, Tyler Romeo tylerro...@gmail.com wrote:
As long as people in the templating community were at least consulted with,
then that's fine. I'm just saying we cannot randomly throw features onto
users without discussing it with them.
A good default assumption would
I hear what you're saying Ryan - although in fairness there is some history
there, and also some very significant challenges on all sides to actually
communicate. However, one has to keep in mind that sometimes the
definition of end user can be pretty different. On reading this thread,
I
I actually like it.
If Evil approval bot mailed you warning that it will merge 12 pending
changesets in two days if there's no action from your part, that would
force some promptly action by you.
Not a chance in hell we'll ever allow this for the operations repo or
the mediawiki deployment
You guys (and by that I mean anybody who doesn't regularly edit a
text-producing project[1], but needs to make announcements from time
to time; this includes most of the WMF employees) seem to have a
problem with village pumps and instead invent all kind of alternative
communication methods,
Your idea is a great one, except... I was going to say you can't see
the forest for the trees, but actually it's the other way around. I
think you're too focused on the big picture (communicating with the
community) to see that smaller steps can help a great deal.
I haven't seen any small
Here's what we're proposing to do.
[please note: this message was posted here by a bot. If you want to discuss
this -- here's where it's at: ___. Sory for the hassle.]
Seems reasonable. What's the procedure for doing this?
- Ryan
___
Wikitech-l
Did these organizations need to use those SAML credentials directly for API
things or is this just another method we want to support for logging in?
https://meta.wikimedia.org/wiki/Wikimedia_Fellowships/Project_Ideas/The_Wikipedia_Library
That's the biggest current reason for wanting to
Oh... so not SAML logins or SAML assertions for the api but acting as a
provider of SAML accounts for logging into a 3rd party source with a
Wikipedia account?
Yeah. It's the more interesting situation at first. I'm sure there are
some interesting use cases the opposite way, but we have an
I have re-read the Wikipedia article about OpenID and OpenAuth.
OpenAuth while nice in many ways is NOT the same as OpenID. User
authentication is one easy and obvious requirement and I have already said
too much about its need.
It is NOT clear at all to me why OpenAuth should be regarded
I don't think that's something we really want to do. Granting bot
permissions hides someone from RecentChanges by default,
which you wouldn't want as a normal user (well you might, but
I don't think communities would).
Indeed. Communities also want separate bot accounts so it's easy to
tell
It would still be easier though for an end user to look at a username and see
the bot. The user pages for Bots usually include quite a bit of information
on
them as well. Definitely think replacing Bot accounts with OAuth is the wrong
way to go. I like the idea of using it for the
I think you touch the most important point here. I'm one of the main
people who manage GSoC for KDE. KDE is the biggest org taking part in
GSoC this year in terms of number of students mentored. In addition we
are running our own program (Season of KDE) next to it. So in total
I'd say we've
For a bunch of reasons, we need to look at disabling direct pushing
on the master branch for all extensions in Gerrit […] Before I make
the change though, I wanted to ask about it publicly to make sure
there's no major blockers to me doing so.
E3 is using Phabricator for code-reviews, so
leaked passwords from your local
database. Please see bug 39184
https://bugzilla.wikimedia.org/show_bug.cgi?id=39184 for information
regarding purging the passwords.
- Ryan Lane
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
Another idea I've played with was development of a LRU filesystem. Probably
a FUSE module. You would mount it at thumbs/ and unused files would
periodically disappear.
We don't mount these filesystems anymore. We use an object store call
swift. FUSE also doesn't exist outside of Linux, right?
Today I put some time into fixing the remaining issues needed to
enable self-registration on labsconsole. I need reviews on the
following changes to deploy/enable it:
https://gerrit.wikimedia.org/r/#/q/status:open+topic:selfregistration,n,z
- Ryan
___
Hey if you want to make mediawiki.org a dumping ground for anything
mediawiki related, have fun with that.
Well, the parent thread had a point. Let's discuss what's possible
rather than just downing the current work. How can we make widgets a
viable extension? Is it possible? If not, can we
On Mon, Sep 17, 2012 at 11:24 AM, Derric Atzrott
datzr...@alizeepathology.com wrote:
Are you sure about that number? There are a suspicious number of zeros in
it!
Agreed. Have that many ISPs started to roll out their IPv6 networks to
subscribers?
Do we have an alternative log that could be
On Fri, Sep 28, 2012 at 8:48 AM, Chris McMahon cmcma...@wikimedia.org wrote:
When I was hired as QA Lead almost seven months ago, WMF lacked a test
environment where
* code was routinely deployed ahead of production
* the test environment emulated the production environment closely
* aspects
On Mon, Oct 8, 2012 at 2:49 PM, Chad innocentkil...@gmail.com wrote:
Indeed, we're actually hosting some Git repos for the project :)
We'll be pushing a few more in soonish, too.
- Ryan
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
Can you explain? I find this project amazing (converging and optimizing
documentation effort as opposed to keep building a dozen chapels and why not
starting a new, flashy one?). And I'm very happy to see that MediaWiki has
been put into use!
If the Wikimedia Foundation has got a significant
I'm new on this list but found that the last thread about ExternalAuth [1]
dated back from 2010 [2] but I thought it was acceptable to bring up
the subject again :)
ExternalAuth should be dropped from core. It isn't maintained, it only
supports a single type of authentication that's for
On Thu, Oct 11, 2012 at 4:33 PM, Daniel Friesen
dan...@nadir-seen-fire.com wrote:
I was thinking about this recently too. Though I started thinking from the
login form perspective.
Things we should have:
- Good build-in support for both single-authentication (everyone is in the
user
On Fri, Oct 12, 2012 at 2:14 AM, Seb35 seb35wikipe...@gmail.com wrote:
If there are multiple identification sources, what about unicity of
usernames? i.e. who is User1 if it exists different people User1@OpenID and
User1@RADIUS? the first who registers on the wiki? or is it assumed all
User1
Anyways, adding and deleting wikis is outside of the scope of our builtin
config tools.
Why? This is how Wikimedia creates wikis, but it's Wikimedia specific.
I don't see why this can't be made more generic with a little bit of
effort.
- Ryan
___
Well, Wikimedia people can contribute to non-Wikimedia projects as well...
... which makes me remember that I didn't include the webplatfom/* repos.
Should we?
webplatform.org/mediawiki/Comments
MediaWiki extension Comments for webplatform.org
Are there any plans for an SPDY [1] test on the Wikimedia servers?
I have plans on testing it in production when nginx supports it stably.
- Ryan
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
On Sat, Oct 27, 2012 at 12:38 PM, Yuvi Panda yuvipa...@gmail.com wrote:
We don't even do HTTP/1.1 yet - lack of Transfer-Encoding: Chunked has
bit me badly before.
Well, nginx didn't support this until fairly recently. We plan on
testing this fairly soon. I upgraded one of the ssl boxes
Awesome! Another old hack swept away. :D
Do we have a timetable for migrating all login sessions to HTTPS yet? I
love that we've got a clean HTTPS option available, but it really skeezes
me out that we still allow logins and passwords over plain HTTP.
We're waiting on some MediaWiki
I've been swamped with a few other projects recently, but once they
settle down, we're very close to getting all logins going over https.
I think we should be able to enable the preference by 1.21wmf5 or
wmf6.
Preference? I thought we wanted this to be default (and more
preferences suck ;)
On Sat, Nov 17, 2012 at 9:32 AM, Platonides platoni...@gmail.com wrote:
On 16/11/12 22:04, Brion Vibber wrote:
Awesome! Another old hack swept away. :D
Do we have a timetable for migrating all login sessions to HTTPS yet? I
love that we've got a clean HTTPS option available, but it really
A few weeks ago I upgraded a single SSL termination server to Ubuntu
Precise. I let it run for a while to ensure we wouldn't see memory leaks
and to give time for people to report errors. No issues were reported and
resource consumption was good, so today I upgraded all other nodes. This
upgrade
Saltstack and Webplatform as well.
On Tue, Nov 20, 2012 at 1:28 PM, Arthur Richards aricha...@wikimedia.orgwrote:
I'm helping to organize an 'intro to FLOSS' orientation module for new
hires at the WMF with Tomasz Finc, and we're curious to know what all the
projects are that the we
this version, please use the extension distributor
(http://www.mediawiki.org/wiki/Special:ExtensionDistributor/LdapAuthentication),
select “Development version (trunk)”, and click “Continue”.
Respectfully,
Ryan Lane
___
Wikitech-l mailing list
Wikitech-l
that would
prefer not to their presence known. Enterprise use in general fits
this category.
Respectfully,
Ryan Lane
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
to manage
this for all extensions, especially since they aren't all code
reviewed.
If Debian doesn't feel they should keep supported versions in their
repos, maybe they shouldn't distribute MediaWiki.
Respectfully,
Ryan Lane
___
Wikitech-l mailing list
, doesn't mean they should.
Respectfully,
Ryan Lane
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
can put on prototype versus test.
V/r,
Ryan Lane
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
in Java, and we all know how Oracle loves to sue.
-- Ryan Lane
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
OK. Nevertheless, I would really strongly suggest planning a firm
escape route as soon as possible.
Why? The Java we use is GPL licensed. As long as we use a JDK/VM that
is open, we are good.
-- Ryan Lane
___
Wikitech-l mailing list
Wikitech-l
stronger than passwords, is that it
requires a level of complexity that would be difficult for us, and
either annoying or very confusing for users.
Respectfully,
Ryan Lane
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
:
if (req.http.Authorization || req.http.Cookie)
to:
if (req.http.Authorization)
Whether or not that is a good idea, I don't know. You may be able to
pass on specific cookies as well; a good one to pass on would be the
actual authentication cookie.
Respectfully,
Ryan Lane
a
lot.
Respectfully,
Ryan Lane
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
numbers
temporarily.
-- Ryan Lane
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
and the dynamically
created resources. If a run doesn't complete for some reason, a cron
can clean up resources that haven't been used in some appropriate
amount of time.
Respectfully,
Ryan Lane
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
or buggy extensions.
Respectfully,
Ryan Lane
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
betting that almost everything not moved from
etherpad is never looked at again.
I think the correct solution here is to continue to move the documents
from etherpad to mediawiki.org (or some other appropriate wiki), and
try to be more vigilant about doing so.
Respectfully,
Ryan Lane
this, I think the strategy wiki is the right
spot. Not wikitech-l.
Respectfully,
Ryan Lane
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
It's in the strategic plan:
http://wikimediafoundation.org/wiki/2010-2011_Annual_Plan_Questions_and_Answers
I don't see how the link you provided addresses the post you were replying
to at all.
As Roan pointed out, I was telling you that a full time Bugmeister was
in the annual plan, if
for help.
Leave the name alone, and merge it into core as soon as possible.
Respectfully,
Ryan Lane
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
In the next hour or two we'll be migrating SVN to a new server.
Nothing is changing from the usage perspective. During this time SVN
may be inaccessible for a few minutes. Let me know if you are having
an access issue, and I'll fix it for you.
Respectfully,
Ryan Lane
I've just finished the SVN migration.
If you've logged into the new server before the migration via SSH,
you'll have SSH key problems. To fix this issue, edit
~/.ssh/known_hosts, and remove the entries for formey and
formey.wikimedia.org.
Respectfully,
Ryan Lane
to contractual
or confidentiality reasons.
Who is telling you it's staff stuff? I'm pretty sure all of the ops
people have been pretty clear about why we can't allow public access
to the system.
Respectfully,
Ryan Lane
___
Wikitech-l mailing list
Wikitech-l
that is being used. That said, there isn't anything to
gain by blocking this.
Respectfully,
Ryan Lane
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
, and maintain
extensions for WMF use. I honestly don't think this is a limiting
factor to the usability of WMF projects, either.
Respectfully,
Ryan Lane
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo
of this thread, yes, we do hope to participate.
Respectfully,
Ryan Lane
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
. Everything else seems normal (well, I'm in the UK, but
otherwise... ;-).
Thankfully, I do read wikitech-l often, but please, please, report
this on IRC as well, if possible everyone.
Thank you for the report, btw. We're looking into it now.
Respectfully,
Ryan Lane
solutions at social problems...)
Almost all threads on wikitech-l are dev related, not ops. I happen to
do both, so I noticed it. Pushing all thread subjects from wikitech-l
to ops folks would pretty much be spam.
Either way, a report is better than no report ;).
Respectfully,
Ryan Lane
for this project configured on tesla, if you'd
like to work in a pre-configured environment.
The extension page is here:
http://www.mediawiki.org/wiki/Extension:OpenStackManager
Respectfully,
Ryan Lane
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
.
Upgrading squid really isn't amazingly high on our priority list right
now.
Respectfully,
Ryan Lane
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
201 - 300 of 436 matches
Mail list logo
