Hurray!
Nik
---------- Forwarded message ----------
From: Clinton Gormley <noreply(a)discuss.elastic.co>
Date: Tue, Jun 9, 2015 at 12:36 PM
Subject: [Announcements] Elasticsearch 1.6.0 released
To: nik9000(a)gmail.com
Clinton_Gormley <http://discuss.elastic.co/users/clinton_gormley>
June 9
Today, we are pleased to announce the release of Elasticsearch 1.6.0, based
on Lucene 4.10.4. This is the latest stable version of Elasticsearch and is
packed with awesome new features:
- Faster restarts with synced flushing
- Shard allocation no longer blocks pending tasks JSON response body
filtering
- Security fix for shared file-system repositories
- Upgrade API for ancient indices
- More lenient highlighting for Kibana users
- mlockall for Windows users
- Fine-grained script settings
You can read more in the blog post:
https://www.elastic.co/blog/elasticsearch-1-6-0-released
------------------------------
To respond, reply to this email or visit
http://discuss.elastic.co/t/elasticsearch-1-6-0-released/2235/1 in your
browser.
To unsubscribe from these emails, visit your user preferences
<http://discuss.elastic.co/my/preferences>.
Hey all, looks like the new rev'd Schema:Search logging for desktop is in
effect. Here are a couple queries suggesting that, at least on English
Wikipedia for stable versions of Chrome most of the time people either
click on an OpenSearch result from the set or dropdown results or press
ENTER / click on the magnifying glass icon.
> SELECT count(DISTINCT event_userSessionToken) FROM Search_12057910 WHERE
timestamp > '20150614' AND timestamp < '20150615' AND (event_action =
'click-result' OR event_action = 'submit-form') AND wiki = 'enwiki' and
userAgent LIKE '%Chrome/43%';
+----------------------------------------+
| count(DISTINCT event_userSessionToken) |
+----------------------------------------+
| 1049 |
+----------------------------------------+
1 row in set (0.20 sec)
> SELECT count(DISTINCT event_userSessionToken) FROM Search_12057910 WHERE
timestamp > '20150614' AND timestamp < '20150615' AND wiki = 'enwiki' and
userAgent LIKE '%Chrome/43%';
> SELECT count(DISTINCT event_userSessionToken) FROM Search_12057910 WHERE
timestamp > '20150614' AND timestamp < '20150615' AND wiki = 'enwiki' and
userAgent LIKE '%Chrome/43%';
+----------------------------------------+
| count(DISTINCT event_userSessionToken) |
+----------------------------------------+
| 1100 |
+----------------------------------------+
In a recent meeting, Oliver expressed concerns about us having services
running in labs which are treated sort of like they were in production.
Examples include WDQS (already) and maps (potentially).
We agreed to have this discussion on the mailing list, so this is an
invitation to do so. I am not familiar enough with the various technical
issues to explain them properly, so hopefully someone else will step in and
do so. I believe one big area of concern is analytics.
Kevin Smith
Agile Coach
Wikimedia Foundation
*Imagine a world in which every single human being can freely share in the
sum of all knowledge. That's our commitment. Help us make it a reality.*
Hello all,
We will now be tracking our maps-related work in the Discovery-Maps-Sprint
project[1], rather than the Maps project[2].
Maps will continue to exist, as a feature-centric list of tasks. However,
it will not reflect the status of tasks (e.g. "In Progress" or "Needs
Review"). That will be handled by Discovery-Maps-Sprint, along with the
Maps column of the Discovery project[3]. In Maps, I have moved all the
tasks into a single column, and have hidden the other columns, to avoid
them accidentally being used.
I have copied all the Maps tasks over to the Sprint board, into the
appropriate columns. Note that the columns in Sprint are a bit different
than they were in Maps, to align with other Sprint boards within the
Discovery department. For details on how tasks are handled, see the
Discovery department process page[4].
I will be requesting phab herald rules to automatically ensure that Maps
tasks automatically get sync'd between these three related projects.
Please let me know if you have any questions or concerns.
[1] https://phabricator.wikimedia.org/tag/discovery-maps-sprint/
[2] https://phabricator.wikimedia.org/tag/maps/
[3] https://phabricator.wikimedia.org/tag/discovery/
[4]
https://www.mediawiki.org/wiki/Search_and_Discovery/Process#Workflow_and_Ph…
Kevin Smith
Agile Coach
Wikimedia Foundation
*Imagine a world in which every single human being can freely share in the
sum of all knowledge. That's our commitment. Help us make it a reality.*
It was nice to chat with many of you in Lyon! Wes mentioned that this
mailing list will be used intensely, but I don't remember how I got to
know about it.
Starting from simple things, it will be good if
* it's added to https://meta.wikimedia.org/wiki/Mailing_lists/Overview
with a description of the usage you expect to make of it;
* short notifications about it are sent to all relevant mailing lists
(which you can find in the wiki list above once you know who you want to
reach).
Nemo
Does anyone know where I can find info about the current load on
www.wikipedia.org? I'd like to set some reasonable sampling rates for the
EventLogging instrumentation that's going to be in place soon.
If the Portal gets a zillion hits per second, then 1/1000 of that is
probably too high. On the other hand, if it gets five hits per day, then
1/1000 of that is rather too low.
Based on input from the developers, Wes, and Dan, and others, here is a new
proposal for a new slate of Search & Discovery vertical recurring
meetings[1].
These changes really can't take full effect until the first week of June,
due to the Hackathon and related travel. But hopefully we can agree on them
now, and start to get them scheduled. After trying the new scheme out for a
couple weeks, we'll have a retrospective so we can adjust as needed.
The days-of-week proposed here are not set in stone, but they seemed
logical. They came out of an attempt to stack meetings (as requested by Nik
and others), combined with a sense that Monday and Friday are not ideal
days for certain types of meetings, plus a recognition that finding huge
blocks of time on our schedules may be challenging.
Basically, if you are a developer, you'll have twice-weekly 15-minute
sub-team standups, plus the weekly 25-minute full-vertical checkin. Every
2-4 weeks, you might be involved in a retrospective and/or showcase. That's
a total of about 1 hour of meetings per week.
Dan and I crave meetings[2], so we'll enjoy about 6.5 hours per week. The
"leads" among you will have meeting loads somewhere in between those
extremes.
Any concerns? Violent outbursts? Purrs of contentment?
[1]
https://www.mediawiki.org/wiki/Search_and_Discovery/Process#Recurring_Meeti…
[2] Not really, but we'll pretend we do
Kevin Smith
Agile Coach
Wikimedia Foundation
*Imagine a world in which every single human being can freely share in the
sum of all knowledge. That's our commitment. Help us make it a reality.*
Hi!
Just in case anybody finds it interesting/useful, I've made a quick
performance analysis on the update service we're running on wdqs-beta,
in order to catch up with the wikidata updates:
https://www.mediawiki.org/wiki/Wikibase/Indexing/Updater_performance_analys…
May be useful for evaluation which hardware we may need if we want for
updates to coexist with production loads.
--
Stas Malyshev
smalyshev(a)wikimedia.org
Summary:
* CirrusSearch has "morelike:*PageName*", who knew?
* I sense a developer article brewing, "Finding related content"
AIUI, the Wikipedia mobile apps' "Read more" section just performs a
full-text search (API [1] ) for the current page title (Android source [2]).
Joaquin's nfity demo http://chimeces.com/webkipedia/ 's "Related pages"
section calls the GettingStarted extension's gettingstartedgetpages API
module [3] with gsgptaskname=morelike . This is implemented by
GettingStarted/MoreLikePageSuggester.php... and it seems this just makes a
search query for srsearch=morelike:Australia . Who knew Cirrus search had
a "morelike:" keyword? It's not in the enwiki search help, but it is in
the Cirrus search help [4].
I'm not sure if there's any reason to interpose gettingstartedgetpages
instead of querying search directly for morelike:*pagetitle*, it might
cache stuff in Redis. The mobile apps might get better "Read more"
suggestions using one of these.
There's also a srwhat=suggestion, I don't know if that helps getting
related pages.
I'll be updating https://www.mediawiki.org/wiki/API:Search_and_discovery
with this, and it seems article-worthy.
Cheers, hope this helps someone.
[1] https://en.wikipedia.org/w/api.php?action=help&modules=query%2Bsearch
[2]
https://github.com/wikimedia/apps-android-wikipedia/blob/de0b8b579f5030f684…
[3]
https://en.wikipedia.org/w/api.php?action=help&modules=query%2Bgettingstart…
[4] https://www.mediawiki.org/wiki/Help:CirrusSearch#Special_prefixes
On Fri, May 29, 2015 at 2:18 AM, Joaquin Oltra Hernandez <
jhernandez(a)wikimedia.org> wrote:
> Sorry forgot to link it: https://github.com/joakin/webkipedia
>
> Matt Flaschen told me about the gettingstarted 'morelike' mode for other
> purposes, but it fitted perfectly my purposes for this reading app. They
> developed it on the Growth team about a year ago, but the experiment wasn't
> successful so the API has been there dormant and unused for a lot of time
> (works pretty well!).
>
> About the content I'm fetching for the articles, I'm using the extracts
> with the exintro option, and embedding the html (
> https://github.com/joakin/webkipedia/blob/master/lib/api/article.js). The
> idea would be to have a 'Read more' that would show the full article I
> guess.
>
> The president's chest is pretty good too :D
> http://chimeces.com/webkipedia/#/wiki/Barack_Obama
>
> On Fri, May 29, 2015 at 4:35 AM, S Page <spage(a)wikimedia.org> wrote:
>
>> (Cc'ing James Douglas, who's also developing API playground code.)
>>
>> On Thu, May 28, 2015 at 2:52 AM, Joaquin Oltra Hernandez <
>> jhernandez(a)wikimedia.org> wrote:
>>
>>> S, for getting started quickly, I set up a JS web app completely
>>> standalone with some basic infrastructure (libraries for calling the api,
>>> rendering pipeline of JS views, url routing) so that interested people
>>> could just get quickly to render a view within the app and do interesting
>>> stuff querying the API. We were also open to just doing a plain html file
>>> with some JS and CSS, or a codepen/jsbin style would have worked too.
>>>
>>> Here's the demo of the lite wikipedia webapp I worked on:
>>> http://chimeces.com/webkipedia/
>>>
>>
>> That's lovely! It's what API developers develop when they develop.
>> * Where's the source?
>> * I had no idea the gettingstartedgetpages would give you related pages,
>> so obscure!
>> * I guess RESTBase has no mode that strips the citations and such, or
>> gives you just the opening section (prop=extracts & exintro=)
>> * Nice closeup of the great man's chest :-),
>> http://chimeces.com/webkipedia/#/wiki/Albert_Einstein
>>
>> --
>> =S Page WMF Tech writer
>>
>
>
--
=S Page WMF Tech writer