unsubscribe me
On 19 July 2013 19:10, <wikitech-l-request(a)lists.wikimedia.org> wrote:
Send Wikitech-l mailing list submissions to
wikitech-l(a)lists.wikimedia.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
or, via email, send a message with subject or body 'help' to
wikitech-l-request(a)lists.wikimedia.org
You can reach the person managing the list at
wikitech-l-owner(a)lists.wikimedia.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Wikitech-l digest..."
Today's Topics:
1. Re: Australia (was Re: conferences, Hacker School, Code for
America) (Quim Gil)
2. Bugzilla: Tips and Best Practices (Andre Klapper)
3. Re: Australia (was Re: conferences, Hacker School, Code for
America) (Luis Villa)
4. Re: Request for Comments: New Search (Nikolas Everett)
5. CSS: Make hlist class part of MediaWiki core (Jon Robson)
6. Re: Australia (was Re: conferences, Hacker School, Code for
America) (Roan Kattouw)
7. Re: CSS: Make hlist class part of MediaWiki core (MZMcBride)
8. Re: CSS: Make hlist class part of MediaWiki core (Jon Robson)
9. Git config trick. (Ori Livneh)
10. MediaWiki extensions as core-like libraries: MediaWiki's fun
new landmine for admins (Ryan Lane)
----------------------------------------------------------------------
Message: 1
Date: Fri, 19 Jul 2013 14:54:07 +0200
From: Quim Gil <qgil(a)wikimedia.org>
To: wikitech-l(a)lists.wikimedia.org
Subject: Re: [Wikitech-l] Australia (was Re: conferences, Hacker
School, Code for America)
Message-ID: <51E936EF.9070104(a)wikimedia.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 07/06/2013 04:30 PM, Quim Gil wrote:
On 07/03/2013 09:22 AM, Sumana Harihareswara
wrote:
The linux.conf.au call for talks closes July 6th,
*Australian time*.
http://linux.conf.au/media/news/1
CFP Extension Announced linux.conf.au 2014 - linux.conf.au !!!
Now it's July 20.
http://linux.conf.au/media/news/27
... and this is tomorrow.
I also think that linux.conf.au could be a good
chance to spread our
word in Australia. You are encouraged to apply.
I just did. :)
> If you submit a good talk that doesn't
> get accepted, you may win a free ticket to attend LCA.
>
http://linux.conf.au/media/news/26 "This year, the papers committee is
> going to be focused on Linux on the frontier and deep technical
> content-- that might range from cybernetics and mobile operating
> environments to large astronomy projects and big data projects." LCA is
> 6-10 Jan 2014 in Perth, Australia. If you get a talk accepted, you
> could get a travel subsidy:
>
https://meta.wikimedia.org/wiki/Participation:Support
--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
------------------------------
Message: 2
Date: Fri, 19 Jul 2013 16:17:52 +0200
From: Andre Klapper <aklapper(a)wikimedia.org>
To: wikitech-l(a)lists.wikimedia.org
Subject: [Wikitech-l] Bugzilla: Tips and Best Practices
Message-ID: <1374243472.2060.25.camel@localhost>
Content-Type: text/plain; charset="UTF-8"
This is a reminder that I've been regularly blogging about small & not
so easy to discover functionality in Wikimedia's bugtracker located at
https://bugzilla.wikimedia.org .
Today's blogpost is about creating reports and tables in Bugzilla to get
a better overview of the bug reports that you are interested in.
The last episodes cover saving and sharing your Bugzilla searches with
others (e.g. your development team), and how to search for empty fields.
You can find the blogposts on
http://blogs.gnome.org/aklapper/category/computer/bugzilla/
The full list of topics is at the bottom of
https://www.mediawiki.org/wiki/Bug_management#Tricks_and_best_practices_in_…
If you want to see a specific topic covered, or always wanted to know
how to do X in Bugzilla: Tell me, or add it to
https://www.mediawiki.org/wiki/Bug_management/Task_list !
Cheers,
andre
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
------------------------------
Message: 3
Date: Fri, 19 Jul 2013 08:35:47 -0700
From: Luis Villa <lvilla(a)wikimedia.org>
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Subject: Re: [Wikitech-l] Australia (was Re: conferences, Hacker
School, Code for America)
Message-ID:
<
CAM2wSz58wdZL_PBgedEEA4UNy4ojnPgAOJfs0Vn5CVE_i_v_uw(a)mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Sat, Jul 6, 2013 at 11:45 PM, Roan Kattouw <roan.kattouw(a)gmail.com
wrote:
I
went to (and presented at) linux.conf.au in 2012, and I had an
awesome time. The quality of the talks and the number of high-quality
talks is amazing. I highly recommend it.
Historically they also treat speakers *really* well. The year I spoke I got
a hot air balloon ride. ;)
Luis
--
Luis Villa
Deputy General Counsel
Wikimedia Foundation
415.839.6885 ext. 6810
NOTICE: *This message may be confidential or legally privileged. If you
have received it by accident, please delete it and let us know about the
mistake. As an attorney for the Wikimedia Foundation, for legal/ethical
reasons I cannot give legal advice to, or serve as a lawyer for, community
members, volunteers, or staff members in their personal capacity.*
------------------------------
Message: 4
Date: Fri, 19 Jul 2013 12:38:57 -0400
From: Nikolas Everett <neverett(a)wikimedia.org>
To: engineering(a)lists.wikimedia.org, Wikimedia developers
<wikitech-l(a)lists.wikimedia.org>
Subject: Re: [Wikitech-l] Request for Comments: New Search
Message-ID:
<
CAP+xBbV6GPGB6LsOP3b72VxjaksnQt6-L+8XEc4ZvZJwDVyUrA(a)mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Everyone,
I'm reviving this old thread to update everyone on the status of the RFC:
We've continued working on implementation and everything seems to be
proceeding smoothly. We evaluated Elasticsearch and were super impressed
and decided it was very likely to be worth switching from Solr4 to it. The
evaluation and the switch did cost some time but in my opinion doing it was
time well spent.
Thanks so much for your comments a month ago when I first posted this. If
you are interested please give the page another look. Just to be helpful,
here is a link to what I changed:
http://www.mediawiki.org/w/index.php?title=Requests_for_comment%2FCirrusSea…
Nik Everett
On Fri, Jun 14, 2013 at 4:21 PM, Nikolas Everett <neverett(a)wikimedia.org
wrote:
So Chad and I feel like we've gotten far
enough in our prototype of our
new search backend for MediaWiki that we're ready to request comments.
So
here is our format RFC:
https://www.mediawiki.org/wiki/Requests_for_comment/CirrusSearch
You'll note that the plugin is called CirrusSearch. SolrSearch seems to
have been taken by an unrelated project so we had to pick a different
name.
Please read and comment in whatever way is normal for these things.
Thanks so much for your attention,
Nik Everett
------------------------------
Message: 5
Date: Fri, 19 Jul 2013 09:47:11 -0700
From: Jon Robson <jdlrobson(a)gmail.com>
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Subject: [Wikitech-l] CSS: Make hlist class part of MediaWiki core
Message-ID:
<CALMndh=S=CUSNb_yRar8EsB=
Ff5bVkP0HKK0ec4W7CUiCHgTbg(a)mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
One of the things mobile did early on in its lifetime was turn off all
modules by default to give modules the opportunity to sort out their
JavaScript/design (mostly the latter) to be mobile optimised and turn
themselves on.
The result of this is various pages are badly styled on mobile as their
styles never show up on mobile.
A common pattern I'm noticing /a lot/ is there are lots of lists which are
clearly meant to be horizontal lists that are not horizontal lists.
This suggests to me that we have a heap of code debt where there are lots
and lots of rules that do the same - make a list horizontal.
I'd like to propose that we make the .hlist class a part of core and go
through our extensions using it instead of custom rules where appropriate.
Note that said I know that .hlist has more meaning in various projects - it
also introduces additional styling changes such as dots between lists in
certain contexts. That said I think we should be striving to reuse as much
as possible - and this to me suggests that the community (both wiki and
developer) needs to work together to get our css much more organised and
reusable.
Thoughts?
------------------------------
Message: 6
Date: Fri, 19 Jul 2013 10:10:16 -0700
From: Roan Kattouw <roan.kattouw(a)gmail.com>
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Subject: Re: [Wikitech-l] Australia (was Re: conferences, Hacker
School, Code for America)
Message-ID:
<CALoQHwHfJ=
UQbhAYJxSR5VB5wMsGDTTg-GR87yczH6sE3qFKxw(a)mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Jul 19, 2013 at 5:54 AM, Quim Gil <qgil(a)wikimedia.org> wrote:
CFP
Extension Announced linux.conf.au 2014 - linux.conf.au !!!
Now it's July 20.
http://linux.conf.au/media/news/27
... and this is tomorrow.
Beware that because of Australia's far-east timezone, it's already
tomorrow there :)
Roan
------------------------------
Message: 7
Date: Fri, 19 Jul 2013 13:34:41 -0400
From: MZMcBride <z(a)mzmcbride.com>
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Subject: Re: [Wikitech-l] CSS: Make hlist class part of MediaWiki core
Message-ID: <CE0EEFB3.1D13D%z(a)mzmcbride.com>
Content-Type: text/plain; charset="UTF-8"
Jon Robson wrote:
Note that said I know that .hlist has more meaning
in various projects -
it also introduces additional styling changes such as dots between lists
in certain contexts. That said I think we should be striving to reuse as
much as possible - and this to me suggests that the community (both wiki
and developer) needs to work together to get our css much more organised
and reusable.
Thoughts?
Adding the "hlist" class to MediaWiki core seems reasonable to me. The
"wikitable" class had a similar migration path (copied to dozens and
dozens of wikis before finally being integrated into [the] core).
I'd suggest filing a bug in Bugzilla to track this feature request. We may
want to consider whether to make the separator (if any) more easily
customizable on a per-wiki basis, if possible.
MZMcBride
------------------------------
Message: 8
Date: Fri, 19 Jul 2013 10:37:31 -0700
From: Jon Robson <jdlrobson(a)gmail.com>
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Subject: Re: [Wikitech-l] CSS: Make hlist class part of MediaWiki core
Message-ID:
<
CALMndhkYNeAhhgFWyK5HEQq__w3xFrmybcTxUd7HWJSWfmg-6w(a)mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Done:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51692
Just also noticed LiquidThreads would look a lot nicer on mobile if it made
use of it! :)
On Fri, Jul 19, 2013 at 9:47 AM, Jon Robson <jdlrobson(a)gmail.com> wrote:
One of the things mobile did early on in its
lifetime was turn off all
modules by default to give modules the opportunity to sort out their
JavaScript/design (mostly the latter) to be mobile optimised and turn
themselves on.
The result of this is various pages are badly styled on mobile as their
styles never show up on mobile.
A common pattern I'm noticing /a lot/ is there are lots of lists which
are
clearly meant to be horizontal lists that are not
horizontal lists.
This suggests to me that we have a heap of code debt where there are lots
and lots of rules that do the same - make a list horizontal.
I'd like to propose that we make the .hlist class a part of core and go
through our extensions using it instead of custom rules where
appropriate.
Note that said I know that .hlist has more meaning in various projects -
it also introduces additional styling changes such as dots between lists
in
certain contexts. That said I think we should be
striving to reuse as
much
as possible - and this to me suggests that the
community (both wiki and
developer) needs to work together to get our css much more organised and
reusable.
Thoughts?
--
Jon Robson
http://jonrobson.me.uk
@rakugojon
------------------------------
Message: 9
Date: Fri, 19 Jul 2013 10:40:33 -0700
From: Ori Livneh <ori(a)wikimedia.org>
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Subject: [Wikitech-l] Git config trick.
Message-ID:
<
CAHXK4BwcWs6mJD2KeCd55bg9dFz0P9PcbuZxoAN2e-393EaAHg(a)mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
In ~/.gitconfig, add:
[url "ssh://your_username@gerrit.wikimedia.org:29418/mediawiki/extensions/
"]
insteadOf = "ext:"
Now you can:
git clone ext:UploadWizard
!
---
Ori Livneh
ori(a)wikimedia.org
------------------------------
Message: 10
Date: Fri, 19 Jul 2013 11:10:27 -0700
From: Ryan Lane <rlane32(a)gmail.com>
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Subject: [Wikitech-l] MediaWiki extensions as core-like libraries:
MediaWiki's fun new landmine for admins
Message-ID:
<
CALKgCA0jqVuKPLa1V3FWzY_NO9XnZ470uayppYSyn73ELkM7mQ(a)mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
I attempted to install Wikibase the other day and made a fun discovery.
Installing it properly requires the following (12) extensions:
WikibaseClient
Wikibase DataModel
WikibaseLib
Wikibase Repository
DataValues
DataTypes
ValueParsers
ValueView
ValueValidators
ValueFormatters
Diff
Scribunto
And the following optional (2) extensions:
Universal Language Selector
Babel
Soon it will also require at least the following (4) extensions:
Ask
Wikibase Query
Wikibase Database
Wikibase QueryEngine
To fully deploy wikibase in a way that will work like wikidata, it will
take at least 18 extensions, all of which are versioned differently, and
are broken out in this manner to be used as libraries.
What this is subtly doing is adding another dependency chain into
MediaWiki: extension libraries. Since these extensions are meant to be used
as libraries, other extensions will eventually do so and admins will have
to worry about not only extension compatibility with MediaWiki (an already
nearly impossible task), but will also need to worry about extension
dependency with extension libraries. The compatibility matrix for this is
going to be terrible and exacerbates one of MediaWiki's biggest problems
for admins.
Quite a few of these should be core functionality or if they can't properly
pass review they should be removed. For legitimate library-like extensions
I have no constructive alternative, but there must be some sane alternative
to this.
- Ryan
------------------------------
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
End of Wikitech-l Digest, Vol 120, Issue 53
*******************************************