://bugs.wikimedia.org/17316#c0).
The redesigned page eventually got deployed, but the client-side refresh
very sneakily moved from the HTML output to a Refresh header (cf.
https://bugs.wikimedia.org/35052#c0).
Neither bug is resolved, if anyone is interested in helping out. :-)
MZMcBride
be able to search for your changes as soon as you make them.
That's awesome! :-)
I hope you all will write up a blog post after CirrusSearch has been
deployed to all Wikimedia wikis. This is great news.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l
/Requests_for_comment, for
anyone not in the know.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
of providing a reference is
often painful and unintuitive, particularly in established articles that
employ complicated markup (infoboxes, citation templates, and ref tags).
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
Terry Chay wrote:
[a very long e-mail about the MassMessage extension]
Hi Terry.
Have you ever used or tested the MassMessage MediaWiki extension? If so,
when and where specifically?
MZMcBride
___
Wikitech-l mailing list
Wikitech-l
and present) that appear to be undocumented,
unsupported, and/or untrue, depending on the claim.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
new rôle!
This. Congrats!
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
coincides with the date that the MassMessage MediaWiki
extension is supposed to be deployed to all Wikimedia wikis. I'm giving
the Wikimedia Foundation a set of well-tested (though hackish) Python
scripts (https://github.com/mzmcbride/delivery-bots) in addition to a
stable, reviewed, implemented
editor.
Thanks again for working on this!
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
with a compatible library version and that you're following
JavaScript coding conventions (https://www.mediawiki.org/wiki/CC/JS).
Lastly, be sure that any enhancement tool that you write can degrade
gracefully if JavaScript is unavailable.
Thanks again for working on this!
MZMcBride
or in the commit message (such as
a keyword) might have gotten my attention. This might just be me, though.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
the bugs that arise after (not directly, anyway).
I'd be most interested to hear from Sam, Arthur, Max, Greg, et al. (the
people on https://wikitech.wikimedia.org/wiki/Deployments) about how the
deployments process(es) are working.
MZMcBride
___
Wikitech
proposed, it's already been approved. Is
this RFP intended for an additional new datacenter somewhere in the U.S.?
I looked at https://meta.wikimedia.org/wiki/Wikimedia_servers#Hosting to
try to gain clarity.
MZMcBride
___
Wikitech-l mailing list
pmtpa?
I'm just trying to wrap my head around this at a very high level. :-)
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Merlijn van Deen wrote:
On 16 October 2013 05:15, MZMcBride z...@mzmcbride.com wrote:
I looked at your original e-mail and gerrit-patch-uploader itself and
couldn't find a link to the source code. Could one be added to the user
interface? I think it would help sustain the project.
As Matt
Leslie Carr wrote:
On Sat, Oct 19, 2013 at 3:29 PM, MZMcBride z...@mzmcbride.com wrote:
Leslie Carr wrote:
ulsfo is a caching center (varnish + LVS servers, but no backend
infrastructure and very few machines)
Thank you for clarifying a bit. That helps.
Is this new datacenter intended
applications you're referring to.
MZMcBride
P.S. s/caviot/caveat/ :-)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
a white
screen. :-( My browser error console reports the following:
Uncaught InvalidCharacterError: The string contains invalid characters.
Uncaught TypeError: Cannot call method 'init' of undefined
Uncaught ReferenceError: lsg is not defined
MZMcBride
urge Bitergia to
sanitize its inputs and outputs. Currently passing raw HTML into certain
URL query parameters seems to echo the HTML directly back at the client.
/browser/people.html has this behavior for sure; there may be others.
MZMcBride
, particularly given that U.S. courts
seem to reject the idea that a font can be copyrighted. More info here:
https://wikipedia.org/wiki/Intellectual_property_protection_of_typefaces.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
about adhering to Wikimedia or
MediaWiki design philosophies. Yes, you can find plenty of other examples
of the mobile team doing things like this, but that hardly seems like a
good reason to import those choices into desktop.
MZMcBride
___
Wikitech-l
Happy Tim Starling Day! :-)
It seems this year is the tenth anniversary:
https://en.wikipedia.org/wiki/Wikipedia:Tim_Starling_Day.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo
the user experience for readers and editors daily.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
to be assigned to bugs,
as they cannot edit others' bugs by default. This is problematic and
disruptive to development efforts.
My suggestion is to re-add the editbugs user right to new users by
default (revert the old settings adjustment). Otherwise, an acceptable
workaround needs to be found.
MZMcBride
.
Okay, I apologize for using that term.
We can certainly do something different than what we're doing, though. It
should be easy to get editbugs; just not so easy that a vandal can get it.
Okay, let's. I proposed reverting the settings change. You don't like that
idea. Your turn. :-)
MZMcBride
main inbox to the Bugzilla folder. I suppose it's a slight
improvement, but it misses the point that the overall workflow is broken.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech
no interest in directly working on a code deployment dashboard yourself.
Perhaps a stupid question, but why is that?
Sam seems to have the deployments to the wikis under control and the Marks
seem to have the third-party releases under control. This seems like a
good project for you.
MZMcBride
to only users that
have done at least one or two actions in the last X months. Or exclude
people that haven't logged in for a year. 14.7k sounds like a lot.
Okay.
As to your other questions, I'm confident we'll be able to figure out the
logistical details, if needed.
MZMcBride
the control (it's kind of hiding in plain sight).
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
for this as well.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
://www.mediawiki.org/wiki/Special:AllPages currently outputs one.
Without objection, I'd go ahead and file a bug and mark it as easy. It
should be fairly trivial to kill, I think.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
to decrease interface noise.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
guide architectural
design decisions is, of course, a matter of debate. :-)
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
get an RfC.
We should encourage boldness. It's a wiki world: if you have an idea for
an RFC, the correct answer is to start writing. :-) Anyone can
participate.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
to safely install new MediaWiki extensions. Presumably a
graphical user interface installer would include the ability to do
dependency checking, PHP version checking, etc.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
and the ambassadors mailing list and IRC and other
communication avenues. Avoiding banner blindness is a real concern and the
possible benefit seems small. My two cents. :-)
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
.
* Minification is a form of obfuscation and it harms the open Web.
I'm not sure what the right answer is here. The damage to reproducibility
and the open Web hurts a lot. The performance hit may hurt more.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l
participation in RFCs.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Matthew Flaschen wrote:
On 12/09/2013 09:29 PM, MZMcBride wrote:
* You can specify debug=true.
** Specifying the URL parameter can damage reproducibility.
** URL parameter is non-obvious to just about everyone.
I can't think of a more straight-forward name. It's also clearly
documented
confusion.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
JavaScript gadgets or CSS.
In fact, in my experience certain actions (such as nominating a page for
deletion) have become nearly impossible without the use of gadgets.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
and Bawolff have replied on the bug report. Please feel free to ask
any questions there or here on this mailing list.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
summary has been updated accordingly.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
on a steward's kindness and willingness
to run a bot), and inefficient (not utilizing ResourceLoader). I'm very
excited about the work you're doing to implement a proper solution. :-)
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
/, but still can't figure out what
disabled wikis means. I'm familiar with closed, fishbowl, private,
deleted, etc. Disabled is a new term to me. Can someone please clarify?
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
to bolster the user
documentation and prepare the Commoners for the change will be time very
well spent.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
rate-limiting and other anti-abuse mechanisms.
Bleh.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
not sure this is the case.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
., query
paths containing _ v. + v. %20 v. c.).
Regarding rel=nofollow and link trustworthiness: I'm not sure any sane
search engine continues to trust user input these days. I thought lessons
of the past taught developers that people are pretty unscrupulous. :-)
MZMcBride
would help everyone plan better, though it will
presumably have to be updated after emergency (security) point releases?
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
the pros column seems a lot weaker than the cons
column for implementing this change to $wgMinimalPasswordLength.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi.
Tyler Romeo wrote:
On Wed, Feb 5, 2014 at 2:20 AM, MZMcBride z...@mzmcbride.com wrote:
Ultimately, account security is a user's prerogative. [...] Banks and
even e-mail providers have reason to implement stricter authentication
requirements.
This is conflicting logic. If it is the user's
will
likely be incomplete or inaccurate until this bug is fixed.
If anyone would like to take over the maintenance of these Gerrit reports,
they're yours for the taking. I'll even throw in a free bot account. :-)
MZMcBride
___
Wikitech-l mailing list
Wikitech
Chad wrote:
*From:* Schubotz, Moritz
*Sent:* Mittwoch, 29. Januar 2014 14:33
*To:* wikitech-l@lists.wikimedia.org
*Subject:* FW: effects on caching
Looking at http://lists.wikimedia.org/pipermail/wikitech-l/2014-January/
I guess this message never made it through.
MZMcBride
Wikimedia wikis, that's obviously (at least
partially) your prerogative. But for MediaWiki core and for standard
Wikimedia wikis, I'd like there to be a decent rationale before we
consider inconveniencing users.
MZMcBride
P.S. I also casually wonder whether there's a reasonable argument to be
made
Ryan Lane wrote:
Congrats Faidon, you do great work and you're an awesome person to work
with.
What he said. :-)
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
in substantial work on other wikis, but that's probably a
nearly insignificant percentage. The convenience versus security trade-off
is still a serious consideration, in my opinion.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
ideas?
It's difficult to offer advice without knowing why you're trying to do
what it is you're trying to do. You've described a potential solution, but
I'm not sure what problem you're trying to solve. Are there some example
use-cases or perhaps there's a relevant bug in Bugzilla?
MZMcBride
):
https://commons.wikimedia.org/wiki/Module:MyUploads
https://commons.wikimedia.org/wiki/Special:Permalink/110218872
https://meta.wikimedia.org/wiki/Module:Subpages
https://meta.wikimedia.org/wiki/Special:Permalink/5416155
There are likely others. What can be done to address this issue?
MZMcBride
Greg Grossmeier wrote:
We will be disabling ArticleFeedBack on all wikis.
* https://bugzilla.wikimedia.org/show_bug.cgi?id=61163
ArticleFeedbackv5, rather. ArticleFeedback was already disabled on
Wikimedia wikis (cf. https://bugzilla.wikimedia.org/43892).
MZMcBride
at wikitech.wikimedia.org has $wgDisableHardRedirects set to false.
https://www.mediawiki.org/wiki/Manual:$wgDisableHardRedirects
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
., by implementing
a user.user_display_name field or re-using user.user_real_name). But for
now, I don't see any substantive issue with this change or with merging it
in core. Silently changing a user's preferred username is a valid bug:
Mzmcbride' plainly looks stupid and the silent and unexpected change
here.
The feature in question seems sane and needs a few tweaks before being
re-merged into core. No big deal. I don't think this is a war. The subject
line chosen here was possibly a bit inflammatory. :-)
MZMcBride
___
Wikitech-l mailing list
Wikitech-l
that. One day.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
every MediaWiki wiki looks the same.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
behavior until there is.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
engender more ill will and not provide that much of a savings. It's not as
though anyone is currently prioritizing bug fixes and feature requests
related to skins other than Vector and Monobook. In other words, the de
facto support standard has long been only Monobook and Vector. Shrug.
MZMcBride
by
default with core. It'll be great. ;-)
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-like service or something more
interesting, it shouldn't be too difficult. More info:
* https://www.mediawiki.org/wiki/API
* https://www.mediawiki.org/w/api.php
This somewhat softens the blow of the various WAP services going away.
MZMcBride
wikis get some substantial traffic. ;-)
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
or contractors dedicated to
maintaining human resources software and Bugzilla, but perhaps it could
spare the additional resources for a person dedicated to Gerrit or another
code review tool. Or this is possibly an area where a Wikimedia Chapter
could provide support.
MZMcBride
Mark Holmquist wrote:
On Mon, Mar 17, 2014 at 12:52:52PM -0400, MZMcBride wrote:
The Wikimedia Foundation currently has staff or contractors dedicated to
maintaining human resources software
...which?
(I ask because I suspect MZ is referring to the orgchart project I have
maybe one day every
included). Diffusion
of responsibility. :-) Thanks for sending this note.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
the bare minimum of keeping the service online indefinitely; this would
ideally include regularly implementing bug fixes and enhancement requests.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman
.
For general clarity, while I used www.mediawiki.org in the examples in
this e-mail, because the Web API is retrieving global (wiki farm-wide)
data, the equivalent URL paths should work on other Wikimedia wikis such
as en.wikipedia.org or meta.wikimedia.org.
MZMcBride
the savings are, it's
difficult for me to assess whether the proposed plan is worth reducing the
potential utility of this data.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Daniel Norton wrote:
On Apr 6, 2014, at 12:08 PM, MZMcBride z...@mzmcbride.com wrote:
en.wikipedia.org/s/xr32
Hmm, I presume that you were just tossing out a random URL, but that
“/s/” path seems to be configured with some special purpose, sending a
301 redirect regardless of the remainder
disruptive. Going back to the status quo... not so much.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Steven Walling wrote:
On Mon, Apr 7, 2014 at 5:40 PM, MZMcBride z...@mzmcbride.com wrote:
* Is there an issue with specifying font-family: sans-serif; in
MediaWiki core?
Do you mean just for body type as Odder proposed in
https://gerrit.wikimedia.org/r/#/c/124475/, or for everything?
That's
would start.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
links updates) should just work in MediaWiki. Individual users shouldn't
feel compelled to manually null edit or aggressively purge pages. I'd
personally rather see time and energy invested into making the need for
null edits obsolete instead of making touch.py more robust.
MZMcBride
the
purge action in MediaWiki: https://bugzilla.wikimedia.org/54902.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
language feeds
for the Tech News team, but the infrastructure necessary to do so seems to
be mostly in place already, which is really nice.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman
Markus Glaser wrote:
== Security ==
* (bug 63251) SECURITY: escape sortKey in pageInfo.
:-(
Can you unlock https://bugzilla.wikimedia.org/show_bug.cgi?id=63251?
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
-April/076140.html.
This isn't to say that wikibugs couldn't have better documentation, both
on-wiki and built in. Code patches and wiki edits are welcome. :-)
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
==
* 03:01 Tim: reverting apache change
* 02:53 Tim: deploying apache configuration change
https://gerrit.wikimedia.org/r/106109
https://wikitech.wikimedia.org/wiki/Server_admin_log can be a decent
reference for issues such as this. Hope that helps.
MZMcBride
on mediawiki.org or meta.wikimedia.org.
Greg Grossmeier wrote:
You can. You can claim other accounts in Phab.
What's Phab?
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Chad wrote:
On Fri, May 16, 2014 at 4:38 PM, MZMcBride wrote:
I suppose you could rely only on global (in the CentralAuth extension
sense) accounts, but it really would make sense for Wikimedia to get its
own house in order first: we should finish fully unifying login across
Wikimedia wikis
or one of the other designers could take a look.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
. :-)
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
transclusions. This should provide a useful list of places for people
to help out, at which point the magical wiki process can take over. :-)
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo
to lots of editors every month and anecdotally many of
them would prefer not to have their usernames plastered at the top of
articles. I'm not sure this is unreasonable.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https
wiki installations probably want to re-visit whether
the user preferences defaults are appropriate for their communities.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
)
Putting Special:MyLanguage-type functionality in MediaWiki core seems
fine to me. It just maps a user's language preference to a language code
subpage, right? So Special:MyLanguage/Foo for someone who's specified
that she speaks Spanish would redirect to Foo/es.
MZMcBride
currently, 'File:Cosmos
atrosanguineus Choco Mocha.jpg').
Hope that helps.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Lars Aronsson wrote:
On 06/18/2014 06:14 AM, MZMcBride wrote:
If you search for 'incategory:Red flowers', you can find pictures in
only that category. If you search for 'incategory:Red flowers
incategory:Bicycles', you can see the intersection of these two
categories. (No results currently
in a URL.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
is correct
--
I suppose you'd need to make sure the md5 parameter made it to the Web
server before the truncated text parameter... bah. :-)
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman
= true,
NS_FILE_TALK = true,
NS_MEDIAWIKI = true,
NS_MEDIAWIKI_TALK = true,
NS_TEMPLATE_TALK = true,
NS_HELP = true,
NS_HELP_TALK = true,
NS_CATEGORY_TALK = true
);
---
Proposed array addition:
---
NS_MAIN = true,
---
MZMcBride
1 - 100 of 808 matches
Mail list logo
