unsubscribe me
On 19 July 2013 19:10, <[email protected]> wrote: > Send Wikitech-l mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 <[email protected]> > To: [email protected] > Subject: Re: [Wikitech-l] Australia (was Re: conferences, Hacker > School, Code for America) > Message-ID: <[email protected]> > 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 <[email protected]> > To: [email protected] > 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_Bugzilla > > 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 <[email protected]> > To: Wikimedia developers <[email protected]> > Subject: Re: [Wikitech-l] Australia (was Re: conferences, Hacker > School, Code for America) > Message-ID: > < > cam2wsz58wdzl_pbgedeea4uny4ojnpgaojfs0vn5cve_i_v...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Sat, Jul 6, 2013 at 11:45 PM, Roan Kattouw <[email protected] > >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 <[email protected]> > To: [email protected], Wikimedia developers > <[email protected]> > Subject: Re: [Wikitech-l] Request for Comments: New Search > Message-ID: > < > cap+xbbv6gpgb6lsop3b72vxjaksnqt6-l+8xec4zvzjwdvy...@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%2FCirrusSearch&diff=740790&oldid=728213 > > Nik Everett > > On Fri, Jun 14, 2013 at 4:21 PM, Nikolas Everett <[email protected] > >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 <[email protected]> > To: Wikimedia developers <[email protected]> > Subject: [Wikitech-l] CSS: Make hlist class part of MediaWiki core > Message-ID: > <CALMndh=S=CUSNb_yRar8EsB= > [email protected]> > 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 <[email protected]> > To: Wikimedia developers <[email protected]> > Subject: Re: [Wikitech-l] Australia (was Re: conferences, Hacker > School, Code for America) > Message-ID: > <CALoQHwHfJ= > [email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > On Fri, Jul 19, 2013 at 5:54 AM, Quim Gil <[email protected]> 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 <[email protected]> > To: Wikimedia developers <[email protected]> > Subject: Re: [Wikitech-l] CSS: Make hlist class part of MediaWiki core > Message-ID: <[email protected]> > 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 <[email protected]> > To: Wikimedia developers <[email protected]> > Subject: Re: [Wikitech-l] CSS: Make hlist class part of MediaWiki core > Message-ID: > < > calmndhkyneahhgfwyk5heqq__w3xfrmybctxud7hwjswfmg...@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 <[email protected]> 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 <[email protected]> > To: Wikimedia developers <[email protected]> > Subject: [Wikitech-l] Git config trick. > Message-ID: > < > cahxk4bwcws6mjd2kecd55bg9dfz0p9pcbuzxoan2e-393ea...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > In ~/.gitconfig, add: > > [url "ssh://[email protected]:29418/mediawiki/extensions/ > "] > insteadOf = "ext:" > > Now you can: > > git clone ext:UploadWizard > > ! > > --- > Ori Livneh > [email protected] > > > ------------------------------ > > Message: 10 > Date: Fri, 19 Jul 2013 11:10:27 -0700 > From: Ryan Lane <[email protected]> > To: Wikimedia developers <[email protected]> > Subject: [Wikitech-l] MediaWiki extensions as core-like libraries: > MediaWiki's fun new landmine for admins > Message-ID: > < > calkgca0jqvukpla1v3fwzy_no9xnz470uayppysyn73elkm...@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 > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > End of Wikitech-l Digest, Vol 120, Issue 53 > ******************************************* > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
