On Tue, Sep 19, 2017 at 8:37 PM, Tim Starling
wrote:
> According to people on the ops team who have worked with them
> recently, they stopped working on the open source product altogether.
> They stopped responding to bug reports.
This makes it sound as if your
On 20/09/17 12:19, C. Scott Ananian wrote:
> On Sep 19, 2017 9:45 PM, "Tim Starling" wrote:
>
> Facebook have been inconsistent with
> HHVM, and have made it clear that they don't intend to cater to our needs.
>
>
> I'm curious: is this conclusion based on your recent
On Sep 19, 2017 9:45 PM, "Tim Starling" wrote:
Facebook have been inconsistent with
HHVM, and have made it clear that they don't intend to cater to our needs.
I'm curious: is this conclusion based on your recent meeting with them, or
on past behavior? Their recent
On 20/09/17 02:40, C. Scott Ananian wrote:
> For example, the top-line github stats are:
> hhvm: 504 contributors (24,192 commits)
> php-src: 496 contributors (104,566 commits)
There's a reason I've contributed loads of code to HHVM and hardly any
to PHP. Although the HHVM folks were sometimes
>
> Anyway, would it be a big deal to show the transliterated results with
> less weight in ranking?
Doing any special weighting would be more difficult, but they would already
be naturally ranked lower for not being exact matches. (You can see this at
work if you compare the results for
Le 19/09/2017 à 23:47, Trey Jones a écrit :
We recently got a suggestion via Phabricator[1] to automatically map
between hiragana and katakana when searching on English Wikipedia and other
wiki projects. As an always-on feature, this isn't difficult to implement,
but major commercial search
Le 19/09/2017 à 15:29, Brad Jorsch (Anomie) a écrit :
On Tue, Sep 19, 2017 at 2:48 AM, mathieu stumpf guntz <
psychosl...@culture-libre.org> wrote:
But having ability to write a limited amount of bytes in a single data
module per script call, and possibly others safeguard limits, wouldn't be
Hello All,
Over the past week there's been a significant increase in the number of
folks interested in participating in the upcoming Technical Debt SIG
sessions. As a result, there's also been a fair amount of discussion on
the challenges and value of having a large number of participants in a
We recently got a suggestion via Phabricator[1] to automatically map
between hiragana and katakana when searching on English Wikipedia and other
wiki projects. As an always-on feature, this isn't difficult to implement,
but major commercial search engines (Google.jp, Bing, Yahoo Japan,
DuckDuckGo,
On Tue, Sep 19, 2017 at 2:41 PM, C. Scott Ananian
wrote:
> You say "there's not much migration cost moving to PHP7" --
> well, it would be nice to assign someone to go through the details in a
> little more detail to double-check that.
What migration costs there were
Hi!
> IMO the more interesting discussion to be had is how little we invest into
> the technology our whole platform is based on. You'd think the largest
> production user of PHP would pay at least one part-time PHP developer, or
> try to represent itself in standards and roadmap discussions, but
Hi!
> So to be super clear: I'm just pointing out that there used to be issues
> here; sometimes the community's interests do not exactly align. Consider
> me in the devil's advocate role again: I'd be interested to hear an
> insider's opinion (Stas?) on how security issues are handled these
On Tue, Sep 19, 2017 at 11:41 AM, C. Scott Ananian
wrote:
> Think of this like
> the traditional [[devil's advocate]] process for canonizing a saint. I'm
> just challenging us to take a hard look at our reasoning and make sure it
> is well-founded technically.
>
I for
On Tue, Sep 19, 2017 at 9:40 AM, C. Scott Ananian
wrote:
> Fair enough. My point is just that we should stop and reflect that this is
> a major inflection point. Language choices are sticky, so this decision
> will have significant long-term implications. We should at
On Tue, Sep 19, 2017 at 2:41 PM, C. Scott Ananian
wrote:
> source". You also mentioned PHP's long history of FLOSS without also
> mentioning their long history at sucking at security.
>
Whoops, I should have toned that down a bit before hitting send. To be
clear, I'm
On Tue, Sep 19, 2017 at 6:42 AM, Daniel Kinzler wrote:
> That table will be tall, and the sha1 is the (on average) largest field.
> If we
> are going to use a different mechanism for tracking reverts soon, my hope
> was
> that we can do without it.
>
Can't you just
Chad: thanks for writing up all of those in one place. I'm not actually
trying to argue *for* Hack here. My argument is just that we should take
the time to lay out the arguments carefully on both sides, since this is a
decision that is likely to have long-lasting effects. Think of this like
On 09/19/2017 10:34 AM, Bryan Davis wrote:
For what it's worth, my opinion is that PHP is an actual FLOSS
software project with years of history and core contributions from
Zend who make their living with PHP. HHVM is a well funded internal
project from Facebook that has experimented with FLOSS
Hi!
> Incidentally, how much work has been done on incorporating HHVM's
> improvements back into Zend?
Depends on which ones you're talking about. Syntax ones may or may not
find its way into PHP, but performance ones would probably be completely
different from HHVM - i.e. the resulting
Zend was testing against hhvm at one point, then decided they would stop
testing against it. See
https://www.phoronix.com/scan.php?page=news_item=PTS-PHP-7.1-Benchmarks
On Tuesday, 19 September 2017, 19:24:49 BST, Stas Malyshev
wrote:
Hi!
> I agree the short
Hi!
> I agree the short timeline seems to push us toward reverting to Zend. But
> it is worth having a meaningful discussion about the long-term outlook.
> Which VM is likely to be better supported in 15 years' time? Which VM
15 years is a lot to predict. 15 years ago Facebook, Twitter, Reddit
There are two important use cases; one where you want to identify previous
reverts, and one where you want to identify close matches. There are other
ways to do the first than to use a digest, but the digest opens up for
alternate client side algorithms. The last would typically be done by some
On Tue, Sep 19, 2017 at 10:50 AM C. Scott Ananian
wrote:
> Chad: the more you argue that it's not even worth considering, the more I'm
> going to push back and ask for actual numbers and facts. ;)
>
>
As I said in my prior message: it's been considered, and discarded
Hi,
On 09/19/2017 10:50 AM, C. Scott Ananian wrote:
> Chad: the more you argue that it's not even worth considering, the more I'm
> going to push back and ask for actual numbers and facts. ;)
Migrating to Hack simply isn't feasible for most users of MediaWiki.
Most distros don't have packages
Hi,
On 09/19/2017 10:27 AM, C. Scott Ananian wrote:
> To be super clear: MediaWiki is in *PHP5*. The choices are:
Well, kind of. MediaWiki has full support for PHP 7 while still
maintaining PHP 5 support.
> 1) MediaWiki will always be in PHP5.
> 2) MediaWiki will eventually migrate to PHP7, or
Chad: the more you argue that it's not even worth considering, the more I'm
going to push back and ask for actual numbers and facts. ;)
Alex: I admit 8 contributors is not significant, but 24,192 commits vs
104,566 commits is. The conclusion I was suggesting was "same number of
contributors over
On Tuesday, September 19, 2017, C. Scott Ananian
wrote:
> On Tue, Sep 19, 2017 at 1:17 PM, Chad wrote:
>
>> be clear: we never chose HHVM for Hack. We don't use Hack. The one
>> experiment I had at trying Hack never panned out. MediaWiki is in
On 19 Sep 2017 5:40 pm, "C. Scott Ananian" wrote:
I'm suggesting to proceed cautiously and have a proper
discussion of all the factors involved instead of over-simplifying this to
"community" vs "facebook".
For example, the top-line github stats are:
hhvm: 504
On Tue, Sep 19, 2017 at 10:28 AM C. Scott Ananian
wrote:
> On Tue, Sep 19, 2017 at 1:17 PM, Chad wrote:
>
> > be clear: we never chose HHVM for Hack. We don't use Hack. The one
> > experiment I had at trying Hack never panned out. MediaWiki is
On Tue, Sep 19, 2017 at 1:17 PM, Chad wrote:
> be clear: we never chose HHVM for Hack. We don't use Hack. The one
> experiment I had at trying Hack never panned out. MediaWiki is in PHP, not
> Hack.
>
To be super clear: MediaWiki is in *PHP5*. The choices are:
1)
On Tue, Sep 19, 2017 at 9:40 AM C. Scott Ananian
wrote:
> Fair enough. My point is just that we should stop and reflect that this is
> a major inflection point. Language choices are sticky, so this decision
> will have significant long-term implications. We should at
On Tue, Sep 19, 2017 at 11:34 AM, Bryan Davis wrote:
> On Tue, Sep 19, 2017 at 9:21 AM, C. Scott Ananian
> wrote:
> > There are other big users of HHVM -- do we know what other members of the
> > larger community are doing? We've heard that
> On Sep 19, 2017, at 6:56 AM, Gilles Dubuc wrote:
>
> Should we have a TechComm-driven meeting about this ASAP?
>
> Like others, I don't expect that there will be disagreement about the way
> to go, but there is a lot to discuss about what needs to be done,
> resourcing,
On Tue, Sep 19, 2017 at 11:33 AM, bawolff wrote:
> I disagree. I don't think its useful or possible to try to forecast
> technical trends 15 years out. 15 years from now, it is just as likely
> that facebook will be as relevant as myspace is today, as it is that
> facebook
On Tue, Sep 19, 2017 at 9:21 AM, C. Scott Ananian
wrote:
> There are other big users of HHVM -- do we know what other members of the
> larger community are doing? We've heard that Phabricator intends to follow
> PHP 7. Etsy also shifted to HHVM, do we know what their
*Continue* to have the best performance? A quick search for benchmarks suggests
that 7.1 outperforms HHVM more often than not.
Betting our future on Facebook because they have most money right now seems
unwise. Which of the two has the larger developer community?
> On 19 Sep 2017, at 16:21,
On Tue, Sep 19, 2017 at 3:21 PM, C. Scott Ananian
wrote:
> On Mon, Sep 18, 2017 at 9:51 PM, Chad wrote:
>
>> I see zero reason for us to go through all the formalities, unless we want
>> to really. I have yet to see anyone (on list, or on IRC
> On Sep 19, 2017, at 8:21 AM, C. Scott Ananian wrote:
>
>> On Mon, Sep 18, 2017 at 9:51 PM, Chad wrote:
>>
>> I see zero reason for us to go through all the formalities, unless we want
>> to really. I have yet to see anyone (on list, or on
On Mon, Sep 18, 2017 at 9:51 PM, Chad wrote:
> I see zero reason for us to go through all the formalities, unless we want
> to really. I have yet to see anyone (on list, or on IRC anywhere at all
> today) where anyone suggested (2) was a good idea at all. It's a
>
Am 19.09.2017 um 10:15 schrieb Jaime Crespo:
> I am not a mediawiki developer, but shouldn't sha1 be moved instead of
> deleted/not deleted? Moved to the content table- so it is kept
> unaltered.
The background of my original mail is indede the question whether we need the
sha1 field in the
On Tue, Sep 19, 2017 at 2:48 AM, mathieu stumpf guntz <
psychosl...@culture-libre.org> wrote:
But having ability to write a limited amount of bytes in a single data
> module per script call, and possibly others safeguard limits, wouldn't be
> that risky, would it?
>
It would break T67258
Sounds like a good idea. +Daniel for scheduling.
Best,
Victoria
> On Sep 19, 2017, at 6:56 AM, Gilles Dubuc wrote:
>
> Should we have a TechComm-driven meeting about this ASAP?
>
> Like others, I don't expect that there will be disagreement about the way
> to go, but
Sorry for cross-posting!
Reminder: Technical Advice IRC meeting again **tomorrow 3-4 pm UTC** on
#wikimedia-tech.
The Technical Advice IRC meeting is open for all volunteer developers,
topics and questions. This can be anything from "how to get started" over
"who would be the best contact for X"
Should we have a TechComm-driven meeting about this ASAP?
Like others, I don't expect that there will be disagreement about the way
to go, but there is a lot to discuss about what needs to be done,
resourcing, etc.
It would be nice to have Ori around for it, to pick his brains about any
Hello.
Since yesterday, I started to get a lot of letters about unexisting
revisions in ruwiki articles. I did not changed something relevant in
preferences, I think. A little investigation gave me the cause - these are
edits of items that are connected by the the item of my watchlist articles
in
I am not a mediawiki developer, but shouldn't sha1 be moved instead of
deleted/not deleted? Moved to the content table- so it is kept
unaltered.
That way it can be used for all the goals that have been discussed
(detect reversions, XML dumps, etc.) and they are not altered, just
moved away (being
On Tue, Sep 19, 2017 at 10:13:47AM +1000, Tim Starling wrote:
> On 19/09/17 06:58, Max Semenik wrote:
> > Today, the HHVM developers made an announcement[1] that they have plans of
> > ceasing to maintain 100% PHP7 compatibility and concentrating on Hack
> > instead.
>
> The HHVM team did tell us
Le 19/09/2017 à 00:38, mathieu stumpf guntz a écrit :
Well, I have investigated a bit, and so far the only reference where I
found a description of saving/retrieving data from a Scribunto module
is SemanticScribunto.
Hum, it was a bit late when I wrote that, so of course *load* data from
a
48 matches
Mail list logo