Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives

2014-07-18 Thread Tilman Bayer 
Minutes and slides from Wednesday's quarterly review of the
Foundation's MediaWiki Core team are now available at
https://www.mediawiki.org/wiki/Wikimedia_MediaWiki_Core_Team/Quarterly_review,_July_2014/Notes

(agenda/overview page:
https://www.mediawiki.org/wiki/Wikimedia_MediaWiki_Core_Team/Quarterly_review,_July_2014
)

On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller  wrote:
> Hi folks,
>
> to increase accountability and create more opportunities for course
> corrections and resourcing adjustments as necessary, Sue's asked me
> and Howie Fung to set up a quarterly project evaluation process,
> starting with our highest priority initiatives. These are, according
> to Sue's narrowing focus recommendations which were approved by the
> Board [1]:
>
> - Visual Editor
> - Mobile (mobile contributions + Wikipedia Zero)
> - Editor Engagement (also known as the E2 and E3 teams)
> - Funds Dissemination Committe and expanded grant-making capacity
>
> I'm proposing the following initial schedule:
>
> January:
> - Editor Engagement Experiments
>
> February:
> - Visual Editor
> - Mobile (Contribs + Zero)
>
> March:
> - Editor Engagement Features (Echo, Flow projects)
> - Funds Dissemination Committee
>
> We’ll try doing this on the same day or adjacent to the monthly
> metrics meetings [2], since the team(s) will give a presentation on
> their recent progress, which will help set some context that would
> otherwise need to be covered in the quarterly review itself. This will
> also create open opportunities for feedback and questions.
>
> My goal is to do this in a manner where even though the quarterly
> review meetings themselves are internal, the outcomes are captured as
> meeting minutes and shared publicly, which is why I'm starting this
> discussion on a public list as well. I've created a wiki page here
> which we can use to discuss the concept further:
>
> https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_reviews
>
> The internal review will, at minimum, include:
>
> Sue Gardner
> myself
> Howie Fung
> Team members and relevant director(s)
> Designated minute-taker
>
> So for example, for Visual Editor, the review team would be the Visual
> Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker.
>
> I imagine the structure of the review roughly as follows, with a
> duration of about 2 1/2 hours divided into 25-30 minute blocks:
>
> - Brief team intro and recap of team's activities through the quarter,
> compared with goals
> - Drill into goals and targets: Did we achieve what we said we would?
> - Review of challenges, blockers and successes
> - Discussion of proposed changes (e.g. resourcing, targets) and other
> action items
> - Buffer time, debriefing
>
> Once again, the primary purpose of these reviews is to create improved
> structures for internal accountability, escalation points in cases
> where serious changes are necessary, and transparency to the world.
>
> In addition to these priority initiatives, my recommendation would be
> to conduct quarterly reviews for any activity that requires more than
> a set amount of resources (people/dollars). These additional reviews
> may however be conducted in a more lightweight manner and internally
> to the departments. We’re slowly getting into that habit in
> engineering.
>
> As we pilot this process, the format of the high priority reviews can
> help inform and support reviews across the organization.
>
> Feedback and questions are appreciated.
>
> All best,
> Erik
>
> [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus
> [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
>
> ___
> Wikimedia-l mailing list
> wikimedi...@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l



-- 
Tilman Bayer
Senior Operations Analyst (Movement Communications)
Wikimedia Foundation
IRC (Freenode): HaeB

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Fwd: HHVM deployment update

2014-07-18 Thread Rob Lanphier 
Hi everyone,

The email below was written with an internal audience in mind, but
Krenair pointed out that there would generally be a lot of general
interest in this.

Rob
-- Forwarded message --
From: Rob Lanphier 
Date: Fri, Jul 18, 2014 at 5:20 PM
Subject: HHVM deployment update
To: WMF Engineering List, Operations Engineers


Hi everyone,

I'm writing to give you a quick update about where we are with HHVM
deployment, so you know what to expect.  Ori, Aaron, Tim, Giuseppe,
Brett, Antoine and probably others I'm forgetting have been hard at
work getting HHVM ready, and are about to make changes that may affect
your work in production.

The good news is that the way it'll most affect you is that your code
will run a lot faster.  The bad news is that there is some risk of
breakage due to the number and nature of things we're changing.

We've started referring to the stack that we're migrating to as "HAT"
(HHVM, Apache 2.4, Trusty), as a nod to LAMP and as a useful tag on
Gerrit changes. The point being: this is not merely a change in our
PHP implementation, but a full stack upgrade that may have
implications beyond just the problems that might be introduced by
HHVM.

The team is deploying this one piece at a time, with the first bit of
the deployment happening very soon.  Here's our rough timeline:
* Now: limited deployments of production job runners to osmium, which
the team only leaves on when they are monitoring it for errors
* Week of July 21: Deployment to Beta Cluster.  The timing on this may
slip, since it might be a surprise to a few people who are deeply
affected by it (/me waves to Chris McMahon), but we think it's
generally ready from an engineering perspective.
* Week of July 21: Deployment to a few job runners in production.
You'll know the first job runner was deployed when you see this
patch[1] get its +2.  We didn't get a chance to coordinate this with
Greg today, so exact timing is TBD.
* Sometime later: Deployment to test.wikipedia.org application server
* Sometime later: Deploy Varnish module allowing partial deployment to
a fraction of application servers
* Sometime later: Limited deployment to small number of application servers
* Sometime later: Ramp up deployment to more application servers until
most servers use HHVM
* Sometime later: Deploy to remainder of services

How to test your extension with HHVM:
-
Historically, we've treated HHVM-related bugs in MediaWiki extensions
as the sole responsibility of HHVM team, because we could not
reasonably expect developers to test their code on HHVM while it was
still difficult to build and configure. As we head toward full
deployment, however, we are going to progressively shift
responsibility onto you to be proactive about testing your code with
HHVM and reporting any issues you encounter.

If you're not sure how to test your code with HHVM, ask! The options
that are currently available to you are:
* On your machine, using MediaWiki-Vagrant (HHVM is the default PHP runtime)
* On Labs, using Labs-Vagrant
(). The Flow team is
doing this; ask them how. :)
* Sometime next week: on the Beta cluster, when we switch it over to HHVM.

Use the "hiphop" keyword in Bugzilla to catch our attentions.

Some things that will change, and the associated challenges:
* Lots of C++ code that is generally high-quality but doesn't have
quite as many flight-hours logged in production as PHP. All that is
entailed by that.
* We expect the performance profile to improve substantially, but we
can't rule out the possibility that specific operations will suffer
performance regressions
* Distribution-upgrade risks: there are many utilities we rely on
besides MediaWiki itself, and many of those utilities will see
upgrades as well.  For example, a lot of the utilities on our image
scalers (e.g. imagemagick, avconf, etc) will be upgraded.

What we're doing to mitigate/minimize risk: test, test, test.  A lot
of the work that's been going on has been to improve the state of our
unit tests such that we can have a clean test run before deploying all
the way; a task made trickier by the fact that our current codebase
doesn't meet that bar[2]

That's all for now.  More information about HHVM and our deployment to
it can be found at https://www.mediawiki.org/wiki/HHVM .  Anything
that isn't there, come talk to me, and I'll turn around and ask Ori.
:-)

Thanks!
Rob

[1]  Puppet repo patch "jobrunner: create hhvm-only jobrunners"
https://gerrit.wikimedia.org/r/#/c/147086/
[2]  Tracking bugs for unit tests that fail in HHVM (and
unfortunately, our current production setup too):
https://bugzilla.wikimedia.org/show_bug.cgi?id=67216

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Phabricator migration update

2014-07-18 Thread Rob Moen 
On Fri, Jul 18, 2014 at 3:29 PM, Steven Walling 
wrote:

> That said, I think Growth would be interested in provisionally
> giving Phabricator a try as a Trello/Bugzilla replacement.
>

+1


-- 
Rob Moen
Wikimedia Foundation
rm...@wikimedia.org
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Phabricator migration update

2014-07-18 Thread Steven Walling 
On Fri, Jul 18, 2014 at 11:59 AM, Andre Klapper 
wrote:

> Hi,
>
> this is a quick status update on the planned migration of our
> development planning tools to Phabricator. See
> https://www.mediawiki.org/wiki/Phabricator for general info.
>
>
> Several things have been worked on and achieved in the meantime:
>   * WMF SUL Authentication has been implemented for Phabricator.
>   * A separate server legalpad.wikimedia.org was deployed (a tool to
> manage trusted users - workflow to be further defined with
> Legal.
>   * A data backup system for Phabricator in place.
>   * Code to restrict access to tasks in a certain project is in
> place (same as Bugzilla's "Security" project)
>   * The dedicated Phabricator server was upgraded to Ubuntu Trusty.
>   * Packaging for Debian using pkg-php-tools/dh_php5
>
>
> The identified tasks are listed on the planning board at
> http://fab.wmflabs.org/project/board/31/
>
>
> Bugzilla:
> When it comes to the planning of how to convert data in Bugzilla tickets
> to Phabricator, we are mostly done.
> The elements that a Bugzilla report includes are listed in
> http://fab.wmflabs.org/T423 with links to subtasks.
>
> Obviously, Phabricator has a different UI and different workflow
> concepts than Bugzilla.
> While it's not the goal to have complete feature parity in every
> possible way, I'm pretty confident that we are close enough.
>
> As people are likely more interested in what Bugzilla functionality will
> be different, I'll try to summarize what I'm aware of:
>   * Bugzilla's products, components and keywords will be turned into
> projects / tags in Phabricator.
>   * Bugzilla votes will be turned into tokens.
>   * Bugzilla's "Severity" field itself should get dropped - for
> example, if there is a real need to be able to search for
> critical severity (which translates to "crash"), it can become a
> "crash" project in Phabricator (think of "keywords" in terms of
> Bugzilla here).
>   * For those ~50 users who have used Bugzilla's private "Tags"
> feature so far (introduced in February), this feature will be
> dropped, but you will get warned before. Similar, some
> Whiteboard data will likely also get dropped (or moved into the
> first comment if really considered relevant).
>
> Apart from that I am not aware of any other data we might drop or
> "lose", or any other important functionality that would not be available
> in Phabricator.
>
>
> If you are passionate about a specific topic of task management /
> development workflows && if you think after reading existing comments in
> the discussion of the related task that an important aspect has not been
> considered yet, please feel free to provide your input.
>
> To follow the progress of our Phabricator migration and to help, please
> see the planning board at http://fab.wmflabs.org/project/board/31/
> Regular status updates are published at
> https://www.mediawiki.org/wiki/Phabricator/Migration#Status
>
>
> As usual, big thanks to Chase and Mukunda for their work, and to many
> others for providing input, feedback and help.
>
>
> Cheers,
> andre
>

Thanks for the update Andre, this plan sounds great.

When we've migrated from Bugzilla, are you looking for teams to be guinea
pigs and try out Phabricator? Overall, I feel like we're not going to get
the real benefit until we migrate from Gerrit and the entire toolset is on
Phabricator. That said, I think Growth would be interested in provisionally
giving Phabricator a try as a Trello/Bugzilla replacement.


> --
> Andre Klapper | Wikimedia Bugwrangler
> http://blogs.gnome.org/aklapper/
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Anonymous editors & IP addresses

2014-07-18 Thread Brian Wolff 
On 7/18/14, Ricordisamoa  wrote:
> The CC BY-SA license, used on most WMF projects, requires /attribution/.
> Attribution for edits made by unregistered/unlogged users is done by the
> exclusive means of their IP address.
> By clicking the 'Save' button, they agreed to release their edits under
> CC BY-SA, and that their IP address would have been the only form of
> attribution of their changes to them.
> While we can assume that there aren't any collisions between hashes of
> IP addresses, and we could change the attribution requirements for new
> edits, hiding or modifying the way IP addresses /of unregistered users
> who edited before that change/ are shown would be a substantial CC BY-SA
> infringement, as would be a change of registered users' names without
> their consent and without public logs of that change.

Additionally, if we used the same hash function as for new edits, it
would make it pretty trivial to figure out what most of the hashes
are. I think its safe to say we wouldn't modify old edits. After all,
you can still look at
https://en.wikipedia.org/wiki/Special:Contributions/216.143.215.xxx
despite us not using that scheme anymore.

--bawolff

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Roadmap and deployment highlights - week of July 21st

2014-07-18 Thread Greg Grossmeier 

> == Tuesday ==
> 
> * MediaWiki deploy
> ** group1 to 1.24wmf11: All non-Wikipedia sites (Wiktionary, Wikisource,

wmf14, of course

#copypastefail


-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |


signature.asc
Description: Digital signature
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Roadmap and deployment highlights - week of July 21st

2014-07-18 Thread Greg Grossmeier 
Hello and welcome to the lates edition of the WMF Engineering Roadmap
and Deployment update.

The full log of planned deployments next week can be found at:


A quick list of notable items...


== Monday ==

* Wikitech wiki
** The MediaWiki install at  will be
upgraded starting at 16:00 UTC


== Tuesday ==

* MediaWiki deploy
** group1 to 1.24wmf11: All non-Wikipedia sites (Wiktionary, Wikisource,
   Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites)
** 
** "Topic:" namespace added (for Flow) 


== Wednesday ==

* Weekly fundraising banner test


== Thursday ==

* MediaWiki deploy
** group2 to 1.24wmf14 (all Wikipedias)
*** "Topic:" namespace added (for Flow) 
** group0 to 1.24wmf15 (test/test2/testwikidata/mediawiki)



== Longer term ==

The plan (subject to change) for the next month or so:

* July 31st: Thumbnail styling change to testwikis
** 
* end of July: HHVM on all jobrunners
* end of July: Beta Feature: "in other projects" sidebar
** 

** 
* Aug 5 - 10: Wikimania 2014 (critical deploys only)
* Aug 14: VE as default editing experience for tablets
* Aug 12 - 15: Thumbnail styling change to non-wikipedias then
  wikipedias
* Mid-August: change default thumbnail size from 220px to 300px --
** 
** 



Thanks and as always, questions and comments welcome,

Greg

-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |


signature.asc
Description: Digital signature
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Phabricator migration update

2014-07-18 Thread Andre Klapper 
Hi,

this is a quick status update on the planned migration of our
development planning tools to Phabricator. See
https://www.mediawiki.org/wiki/Phabricator for general info.


Several things have been worked on and achieved in the meantime:
  * WMF SUL Authentication has been implemented for Phabricator. 
  * A separate server legalpad.wikimedia.org was deployed (a tool to
manage trusted users - workflow to be further defined with
Legal. 
  * A data backup system for Phabricator in place. 
  * Code to restrict access to tasks in a certain project is in
place (same as Bugzilla's "Security" project)
  * The dedicated Phabricator server was upgraded to Ubuntu Trusty. 
  * Packaging for Debian using pkg-php-tools/dh_php5


The identified tasks are listed on the planning board at
http://fab.wmflabs.org/project/board/31/


Bugzilla:
When it comes to the planning of how to convert data in Bugzilla tickets
to Phabricator, we are mostly done.
The elements that a Bugzilla report includes are listed in
http://fab.wmflabs.org/T423 with links to subtasks.

Obviously, Phabricator has a different UI and different workflow
concepts than Bugzilla. 
While it's not the goal to have complete feature parity in every
possible way, I'm pretty confident that we are close enough.

As people are likely more interested in what Bugzilla functionality will
be different, I'll try to summarize what I'm aware of:
  * Bugzilla's products, components and keywords will be turned into
projects / tags in Phabricator.
  * Bugzilla votes will be turned into tokens.
  * Bugzilla's "Severity" field itself should get dropped - for
example, if there is a real need to be able to search for
critical severity (which translates to "crash"), it can become a
"crash" project in Phabricator (think of "keywords" in terms of
Bugzilla here).
  * For those ~50 users who have used Bugzilla's private "Tags"
feature so far (introduced in February), this feature will be
dropped, but you will get warned before. Similar, some
Whiteboard data will likely also get dropped (or moved into the
first comment if really considered relevant).

Apart from that I am not aware of any other data we might drop or
"lose", or any other important functionality that would not be available
in Phabricator.


If you are passionate about a specific topic of task management /
development workflows && if you think after reading existing comments in
the discussion of the related task that an important aspect has not been
considered yet, please feel free to provide your input.

To follow the progress of our Phabricator migration and to help, please
see the planning board at http://fab.wmflabs.org/project/board/31/
Regular status updates are published at
https://www.mediawiki.org/wiki/Phabricator/Migration#Status


As usual, big thanks to Chase and Mukunda for their work, and to many
others for providing input, feedback and help.


Cheers,
andre
-- 
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Include an updater

2014-07-18 Thread Thomas Mulhall 
Yes because people who use Mediawiki think they are using the latest. But in 
fact they are using an unsupported version that has security issues. By 
integrating an updater it would be a lot easer for people to upgrade and we 
could include an in wiki upgraded for people that have access to shell if that 
is what needed or there own servers. It would be really useful.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Include an updater

2014-07-18 Thread Derric Atzrott 
> Hi could we develop an in wiki upgrades meaning we could ether put the 
> upgraded
> in the special version page or create its own special page and then add a
> notification to the special version page that tell them about upgrades for
> extensions and Mediawiki. It will help people migrate and know when updates
> are avalible instead of keep checking so for example a stable version would
> check for ref1_xx and the alpha one would look for the master branch.

I would support this.  Its not too uncommon for me to send an email to a wiki
administrator to let them know that their installation of Mediawiki is both out
of date and vulnerable.  Just a few days ago I let the Free Software Foundation
know that they were running Mediawiki 1.16, which is vulnerable and hasn't been
supported for some time.

Thank you,
Derric Atzrott


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Include an updater

2014-07-18 Thread Thomas Mulhall 
Hi could we develop an in wiki upgrades meaning we could ether put the upgraded 
in the special version page or create its own special page and then add a 
notification to the special version page that tell them about upgrades for 
extensions and Mediawiki. It will help people migrate and know when updates are 
avalible instead of keep checking so for example a stable version would check 
for ref1_xx and the alpha one would look for the master branch.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Anonymous editors & IP addresses

2014-07-18 Thread Ricordisamoa 

The CC BY-SA license, used on most WMF projects, requires /attribution/.
Attribution for edits made by unregistered/unlogged users is done by the 
exclusive means of their IP address.
By clicking the 'Save' button, they agreed to release their edits under 
CC BY-SA, and that their IP address would have been the only form of 
attribution of their changes to them.
While we can assume that there aren't any collisions between hashes of 
IP addresses, and we could change the attribution requirements for new 
edits, hiding or modifying the way IP addresses /of unregistered users 
who edited before that change/ are shown would be a substantial CC BY-SA 
infringement, as would be a change of registered users' names without 
their consent and without public logs of that change.


Il 11/07/2014 15:34, Gilles Dubuc ha scritto:

This interesting bot showed up on hackernews today:
https://news.ycombinator.com/item?id=8018284

While in this instance the access to anonymous' editors IP addresses is
definitely useful in terms of identifying edits with probable conflict of
interest, it makes me wonder what the history is behind the fact that
anonymous editors are identified by their IP addresses on WMF-hosted wikis.

IP addresses are closely guarded for registered users, why wouldn't
anonymous users be identified by a hash of their IP address in order to
protect their privacy as well? The exact same functionality of being able
to see all edits by a given anonymous IP would still exist, the IP itself
just wouldn't be publicly available, protected with the same access rights
as registered users'.

The "use case" that makes me think of that is someone living in a
totalitarian regime making a sensitive edit and forgetting that they're
logged out. Or just being unaware that being anonymous on the wiki doesn't
mean that their local authorities can figure out who they are based on IP
address and time. Understanding that they're somewhat protected when logged
in and not when logged out requires a certain level of technical
understanding. The easy way out of this argument is to state that these
users should be using Tor or something similar. But I still wonder why we
have this double standard of protecting registered users' privacy in
regards to IP addresses and not applying the same for anonymous users, when
simple hashing would do the job.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] RFC to close: [[Requests for comment/Alternate disclosure policy]]

2014-07-18 Thread Sébastien Santoro 
Hi,

Risker have opened June 17th a discussion to allow the MediaWiki.org
community to adopt an alternate disclosure policy.

Quickly, a consensus has been reached.

The format chosen, a formal RFC instead of a consultation of
MediaWiki.org community, doesn't allow a community member to close the
RFC. According https://www.mediawiki.org/wiki/Requests_for_comment/Process,
"Look for the decision from Tim Starling, Brion Vibber, Mark Bergsma,
or an appointed delegate."

The RFC format is maybe a peculiar chose considering this, as the
Wikimedia Foundation TOU provides the alternative policy to be chosen
by the Wikimedia Project community. This current discussion doesn't
really qualify as an engineering change.

So, I hereby request if Tim Starling, Brion Vibber or Mark Bergsma
could close the discussion, and I also offers my services to be an
appointed delegate with a mandate strictly limited to the closure of
the RFC "Alternate disclosure policy", so I could be allowed to close
it. In the last case, I'll then implement it (by documenting on meta
and creating an help page) immediately.

-- 
Sébastien Santoro aka Dereckson
http://www.dereckson.be/

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wikimedia-l] [Wikitech-ambassadors] Deprecating print-on-demand functionality

2014-07-18 Thread Luiz Augusto 
Hi Matthew,

Also on Extension:Collection, do you know what is the current stage for Bug
66597  ("Book tool
incompatible with ProofreadPage extension, again")?

Best,
[[:m:User:555]]


On Tue, Jul 15, 2014 at 1:06 PM, Matthew Walker 
wrote:

> The new renderer should already be working in Hebrew and other RTLs.
>
> ~Matt Walker
> Wikimedia Foundation
>
>
> On Mon, Jul 14, 2014 at 2:16 PM, Itzik Edri  wrote:
>
> > Any plans also to improve this module and make it work well also in
> Hebrew
> > (and maybe other RTL languages)?
> >
> >
> > On Fri, Jul 11, 2014 at 6:48 PM, Erik Moeller 
> wrote:
> >
> > > On Fri, Jul 11, 2014 at 8:45 AM, Luca Martinelli
> > >  wrote:
> > > > so the Book Creator will still be active, maybe under another name,
> > > > maybe with another engine, but still active?
> > >
> > > Same name and functionality, just the "Order a printed book" feature
> > > will disappear.
> > >
> > > Erik
> > > --
> > > Erik Möller
> > > VP of Engineering and Product Development, Wikimedia Foundation
> > >
> > > ___
> > > Wikimedia-l mailing list, guidelines at:
> > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > > wikimedi...@lists.wikimedia.org
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > 
> > >
> > ___
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > wikimedi...@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > 
> >
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> wikimedi...@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Hotmail rejecting mailing list messages

2014-07-18 Thread Tim Landscheidt 
"Andrew \"FastLizard4\" Adams"  wrote:

> [...]

> Is there anything that can be done about this, or should I just advise
> the users to switch to an alternate email provider?

The problem essentially is that someone signs up for mailing
lists/notifications/etc. and when they no longer want to re-
ceive the mails, figuring out how to unsubscribe/disable is
so much work compared to hitting the "This is spam!" button
and mumbling "fuck you".  Each time they reach a critical
mass, Hotmail and others consider us spammers.

I think that our technical processes are streamlined enough
that there is no significant potential to improve the situa-
tion on our side.  So I'd propose that this is solved at a
managerial level -- have someone brassy from WMF promise to
Microsoft that we will not send spam from mchenry & Co. and,
if otherwise, we have a 24/7 ops team on call to deal with
that, and Microsoft in return whitelists the hosts.  The
same applies to Yahoo!, Google et al. of course.

Tim


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Hotmail rejecting mailing list messages

2014-07-18 Thread Federico Leva (Nemo) 
https://bugzilla.wikimedia.org/show_bug.cgi?id=62838
TL;DR: Abandon the sinking M$ ship

Nemo

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Hotmail rejecting mailing list messages

2014-07-18 Thread Andrew "FastLizard4" Adams 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello, devs!

It appears that Hotmail may be blocking emails from Wikimedia, at least
the mailing lists.  Two users were unsubscribed forcibly from the
accounts-enwiki-l mailing list due to excessive fatal bounces (username
portion of addresses redacted):

>   [user1]@hotmail.com
> SMTP error from remote mail server after MAIL 
> FROM: SIZE=6776:
> host mx2.hotmail.com [65.54.188.126]: 550 SC-004 (BAY004-MC4F5) 
> Unfortunately, messages from 208.80.154.4 weren't sent. We recommend that you 
> contact your Internet service provider. The problem is that too many unwanted 
> messages have been sent from the following IP address above. You can also 
> refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors.
>   [user2]@live.com
> SMTP error from remote mail server after MAIL 
> FROM: SIZE=6776:
> host mx3.hotmail.com [65.55.33.135]: 550 SC-004 (COL004-MC6F21) 
> Unfortunately, messages from 208.80.154.4 weren't sent. We recommend that you 
> contact your Internet service provider. The problem is that too many unwanted 
> messages have been sent from the following IP address above. You can also 
> refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors.

According to Microsoft's troubleshooting site:
> Mail rejected by Outlook.com for policy reasons. A block has been placed 
> against your IP address because we have received complaints concerning mail 
> coming from that IP address. We recommend enrolling in our Junk Email 
> Reporting Program (JMRP), a free program intended to help senders remove 
> unwanted recipients from their email list. If you are not an email/network 
> admin please contact your Email/Internet Service Provider for help.

Is there anything that can be done about this, or should I just advise
the users to switch to an alternate email provider?

Thanks in advance for your help!
- --
Sincerely,
Andrew "FastLizard4" Adams


GPG Key ID: 0x221A627DD76E2616
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTyNIhAAoJECIaYn3XbiYWtYQP/AwtzrF656wsZm/UvFx8pZBY
Hf9UGSlG1jPsuMMWCPhK/3+5HkFXWb7fIn1BIJjfRlJmUeUkuuOCrtwAGbAaKEWb
jWd+r5QMEt6kgj57TxEz/kJnrqAPafmLcb1N6KR2AealWkYBWGzqy+c9XcnyhDBa
5ZcceYsIjEEiOLtV6KVgiooPlKSeuH3CMQayE/2qYdKCRFkstok2V/FEAHfPB7uZ
KJWP4jSVsRnYQwP4xVHK40lT8LydxgcjVY5IJ7i+wAX0RmzIN8IgCTVoLi+mJpI9
Ev/K1+6au5Yju9G+PHellTIPQMmgN84BotJNVSBlVit5zWhpcvhAricaGrmoNq6D
kh+v8OOSyb9ZY3ocEe/K7KrW0BTIfFbE5mGX+kEwcpohw8349sl0JxnWEpFvq+Ri
vObxcKav0dGDK2WgEyRmdZUbhL+PCfc5Yn5fAHQOanDSnu3HWBCvzQJGrrRnLW6Y
u05615mdqa+QshEh3gFx4bxPjo4qR7wrmvXBW38h8MxoKADxaaxgbWWhz+G2G9cW
/J1z6yxn2ZZSe8Yr34KxQ3T2+k97ueusi9YcV7TIRSQk/XE4OLiArg3HHVxN5vuf
MlL5p8izYsQLSBpZDbaMiqzRMbw6Gws99eq8nXlCadI0rHcUABSZKWLWYKvAk41/
7Tgv05ml0wuruTbvExq5
=wEyo
-END PGP SIGNATURE-

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tech Talk: Hadoop and Beyond. An overview of Analytics infrastructure, Tuesday!

2014-07-18 Thread Pine W 
Thanks for this. Forwarding to Analytics and Research for others who are
curious.

Pine


On Tue, Jul 15, 2014 at 9:29 AM, Rachel Farrand 
wrote:

> This Tech Talk will be starting in 30 minuets. Thanks!
>
>
> On Fri, Jul 11, 2014 at 3:30 PM, Rachel Farrand 
> wrote:
>
> > Hello!
> >
> > Please join Nuria Ruiz and Andrew Otto next Tuesday, July 15th at 10am SF
> > time/5pm UTC
> > <
> http://www.timeanddate.com/worldclock/fixedtime.html?msg=Analytics+Tech+Talk&iso=20140715T10&p1=224&am=30
> >
> > for a 30 min tech talk. You can join our hangout or follow along on
> > youtube:
> >
> https://plus.google.com/u/0/b/103470172168784626509/events/c53ho5esd0luccd09a1c30rlrmg
> > (please note that a link to join the hangout will be posted in the
> comments
> > of this event just as it starts).
> >
> > You can follow ask questions on IRC during the talk in #wikimedia-dev.
> >
> > If you are not able to follow along live, a video recording will be
> posted
> > here
> > <
> https://plus.google.com/u/0/b/103470172168784626509/103470172168784626509/videos
> >,
> > to the MediaWiki YouTube channel immediately following the tech talk for
> > you to view at any time.
> >
> > More information about the tech talk:
> >
> > *Hadoop and Beyond. An overview of Analytics infrastructure*In this tech
> > talk we will be presenting the analytics infrastructure that we have
> > recently rolled out in production. By now probably everybody knows that
> > wikimedia hosts an instance of hadoop from which we are going to extract
> > pageview data in the near future. But .. how exactly does the data get
> > there?
> >
> > We will go over the path that webrequest log data takes from varnish to
> > kafka (a distributed log buffer) to hadoop and the challenges of
> deploying
> > this java-based infrastructure in production. We will also talk about how
> > can we query the data with hive, an SQL-like interface. How can you set
> up
> > this stack on vagrant to play with and, last but not least, how we used
> > hive recently to provide GLAM folks with image view stats:
> >
> https://commons.wikimedia.org/wiki/Commons:GLAMwiki_Toolset_Project/NARA_analytics_pilot
> >
> > Thanks!
> >
> >
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Naigos and Icinga

2014-07-18 Thread Petr Bena 
Even these multi-use machines we have infront of us are still called
computers although they are rarely used for computing :P

On Fri, Jul 18, 2014 at 8:02 AM, Brian Wolff  wrote:
> I imagine old names die hard. People still say mysql instead of mariadb.
> Most of the varnish related code in mediawiki is still labelled squid. The
> stuff related to libav in our video handling code calls it ffmpeg. Etc.
>
> --bawolff
>
> On Jul 18, 2014 1:01 AM, "Pine W"  wrote:
>>
>> OK, is there a reason I still here people referring to Naigos or are all
> of
>> those outdated references?
>>
>> Pine
>>
>>
>> On Thu, Jul 17, 2014 at 8:59 PM, Jeremy Baron 
> wrote:
>>
>> > On Jul 17, 2014 11:55 PM, "Pine W"  wrote:
>> > > Is there a plan to switch from Naigos to Icinga, or is that merely
> under
>> > > discussion?
>> >
>> > Happened many moons ago.
>> >
>> > -Jeremy
>> > ___
>> > Wikitech-l mailing list
>> > Wikitech-l@lists.wikimedia.org
>> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l