Re: [Wikitech-l] Collaboration team reprioritization

On 3 September 2015 at 07:44, Brian Wolff wrote: >> To better address the needs of our core contributors, we're now focusing >> our strategy on the curation, collaboration, and admin processes that take >> place on a variety of pages. Many of these processes use complex >>

[Wikitech-l] QA: Holding our code to better standards.

Dear Greg, and anyone else that is involved in deployment This is a follow-up from Dan Duvall's talk today during the metrics meeting about voting browser tests. Background: The reading web team this quarter with the help of Dan Duvall has made huge strides in our QA infrastructure. The

Re: [Wikitech-l] [WikimediaMobile] QA: Holding our code to better standards.

Looping in QA list and dropping our team private list. > Dear Greg, and anyone else that is involved in deployment > > This is a follow-up from Dan Duvall's talk today during the metrics > meeting about voting browser tests. > > Background: > The reading web team this quarter with the help of

Re: [Wikitech-l] QA: Holding our code to better standards.

I just want to say that I appreciate this overview. Pine ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] QA: Holding our code to better standards.

On 09/03/2015 02:45 PM, Jon Robson wrote: The future!: Given this success: 1) I would like to see us run @integration tests on core, but I understand given the number of bugs this might not be feasible so far. 2) We should run @integration tests prior to deployments to the cluster via the train

Re: [Wikitech-l] Collaboration team reprioritization

On 09/03/2015 03:54 AM, Federico Leva (Nemo) wrote: > that only non-Wikimedia developers have maintained LQT > is false, as a brief review of the commit log will show. I said "non-Wikimedia users". Not sure what log you've been looking to, but I did `git log --no-merges -- . ':(exclude)i18n'`

[Wikitech-l] Picking the RfC to discuss on IRC next week

Hi everyone, Aaron did a great job leading the discussion about "Master/slave datacenter strategy for MediaWiki" (T88666). Someone (maybe you!) will publish a link to the IRC conversation, and someone (maybe you!) will make our IRC transcripts from #wikimedia-office more robustly stored.

Re: [Wikitech-l] Collaboration team reprioritization

> that only non-Wikimedia developers have maintained LQT > is false, as a brief review of the commit log will show. I said "non-Wikimedia users". Not sure what log you've been looking to, but I did `git log --no-merges -- . ':(exclude)i18n'` and I confirm what I said. The only exception I

Re: [Wikitech-l] Collaboration team reprioritization

> To better address the needs of our core contributors, we're now focusing > our strategy on the curation, collaboration, and admin processes that take > place on a variety of pages. Many of these processes use complex > workarounds -- templates, categories, transclusions, and lots of >

Re: [Wikitech-l] New RFC: better JS minification

On Thu, Sep 3, 2015 at 4:15 PM, Jon Robson wrote: > Thanks, I thought I was alone with being confused by this e-mail. As > Jérémie correctly states we'll likely to get __less__ bugs with a more > maintained library. Less than zero? No one has managed to find a single bug

Re: [Wikitech-l] Collaboration team reprioritization

I appreciate the acknowledgement of failure. It's time for the community for an even braver move, let's take full control of Flow's development and get it to be actually usable. Il 01/09/2015 23:26, Danny Horn ha scritto: For a while now, the Collaboration team has been working on Flow, the

Re: [Wikitech-l] New RFC: better JS minification

Thanks, I thought I was alone with being confused by this e-mail. As Jérémie correctly states we'll likely to get __less__ bugs with a more maintained library. Obfuscation without source code being made available is anti-open source but that's not what's being talked about here. With regards to

Re: [Wikitech-l] New RFC: better JS minification

On 09/01/2015 07:53 PM, MZMcBride wrote: I'd personally prefer that we move in the other direction, removing the minification. I think it's harmful to the open Web to minify, or worse, obfuscate our code. I don't agree with this. However, I do think source maps (which allow you to serve

Re: [Wikitech-l] Collaboration team reprioritization

> On Sep 3, 2015, at 4:06 PM, Ricordisamoa wrote: > > I appreciate the acknowledgement of failure. I don't think that's what was said at all. You may wish to re-read all of this. --- Brandon Harris :: bhar...@gaijin.com :: made of steel wool and whiskey

Re: [Wikitech-l] QA: Holding our code to better standards.

In the services team, we found that prominent coverage metrics are a very powerful motivator for keeping tests in order. We have set up 'voting' coverage reports, which fail the overall tests if coverage falls, and make it easy to check which lines aren't covered yet (via coveralls). In all

Re: [Wikitech-l] New RFC: better JS minification

2015-09-04 1:37 GMT+02:00 Roan Kattouw : > On Thu, Sep 3, 2015 at 4:15 PM, Jon Robson wrote: > >> Thanks, I thought I was alone with being confused by this e-mail. As >> Jérémie correctly states we'll likely to get __less__ bugs with a more >>

Re: [Wikitech-l] Collaboration team reprioritization

Il 04/09/2015 01:24, Brandon Harris ha scritto: On Sep 3, 2015, at 4:06 PM, Ricordisamoa wrote: I appreciate the acknowledgement of failure. I don't think that's what was said at all. You may wish to re-read all of this. Putting "active development"

Re: [Wikitech-l] QA: Holding our code to better standards.

Just to hop on the bandwagon here: this seems like the only sane path going forward. One unmentioned benefit is that this is a step toward continuous deployment. Having integration tests run on every commit and then block when there are failures is pretty much a requirement if Wikimedia ever wants

Re: [Wikitech-l] New RFC: better JS minification

On Thu, Sep 3, 2015 at 4:37 PM, Roan Kattouw wrote: > On Thu, Sep 3, 2015 at 4:15 PM, Jon Robson wrote: > >> Thanks, I thought I was alone with being confused by this e-mail. As >> Jérémie correctly states we'll likely to get __less__ bugs with a more

Re: [Wikitech-l] Collaboration team reprioritization

>> >> >> This sounds a lot like PageTriage, which at best was a mixed success. >> I hope the team is able to extract lessons from that extension and >> apply them to whatever they intend to work on. >> > > "at best was a mixed success" speaking as someone who has used it > extensively, that is not

[Wikitech-l] Forrestbot → ReleaseTaggerBot

Hi, Forrestbot has been renamed to ReleaseTaggerBot per T100811[1]. Just a heads up in case you need to update your mail filters or ignore lists :) [1] https://phabricator.wikimedia.org/T100811 -- Legoktm ___ Wikitech-l mailing list

Re: [Wikitech-l] Collaboration team reprioritization

The decision to stop Flow development could have been a matter of prioritizing resources, and a decision may have been made that many of the resources that would be invested in improving Flow can now be better used elsewhere. I am reluctant to throw stones about Flow. Pine