Re: [Wikitech-l] [Engineering] Scap 3.4.0-1 is live

[Bryan Davis]

On Mon, Nov 28, 2016 at 7:25 PM, Tyler Cipriani  wrote:
>
> * Scap3 (non-mediawiki) deploys will now announce deploys in IRC -- you
>  can specify a message for IRC via:
>
>scap deploy 'A message for the SAL'
>
> * Scap lockfile errors now show you (a) who has the lockfile and (b) their
>  deploy message. The output you'll see if another person is deploying
>  looks like:
>
>sync-file failed:  Failed to acquire lock 
> "/var/lock/scap"; owner is "thcipriani"; reason is "scap 3.4 sync file"

These two changes in particular are awesome! The lack of automatic
!log messages for trebuchet and scap3 always bugged me. Thanks for all
the work folks.

Bryan
-- 
Bryan Davis  Wikimedia Foundation
[[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
irc: bd808v:415.839.6885 x6855

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

[Wikitech-l] Scap 3.4.0-1 is live

[Tyler Cipriani]

Hi all,

A new version of Scap has been released and with it comes a few changes.

tl;dr highlights:

* Old scap bin stubs (e.g., /usr/bin/sync-file, /usr/bin/sync-dir,
 /usr/bin/mwversionsinuse, etc) will now exit 1.

 Subcommands are now the only way to interact with scap, i.e., `sync-file` is
 now `scap sync-file`.

* Scap3 (non-mediawiki) deploys will now announce deploys in IRC -- you
 can specify a message for IRC via:

   scap deploy 'A message for the SAL'

* Scap lockfile errors now show you (a) who has the lockfile and (b) their
 deploy message. The output you'll see if another person is deploying
 looks like:

   sync-file failed:  Failed to acquire lock "/var/lock/scap"; owner is 
"thcipriani"; reason is "scap 3.4 sync file"

You can see a full changelog for both the 3.4.0-1 and the 3.3.1-1 release on
phabricator[0]. If you spot any issues, file a phabricator task tagged with the
`Scap3` project[1].

-- Your Humble Scap Toilers

[0]. 
[1]. 


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

Re: [Wikitech-l] Deployments: upcoming holidays and their impact

[Greg Grossmeier]

Reminder. We are now in the 3 weeks of normalcy before the end-of-year
holiday freeze begins.

Greg


> It's that time of year again; the holiday season.
> 
> Different from last year: 
> In the interest of both 1) giving engineers full time off at the end of the
> year (not needing to be aware of what code they wrote is being deployed)
> and 2) to keep the site reliable during our end-of-year fundraising
> pushes there will be 2 weeks (instead of just 1) at the end of December
> that are NO DEPLOYS weeks.
> 
> Here's the basic outline from now until mid-January (by week):
> * Nov 7th: normal
> * Nov 14th: normal
> * Nov 21st: (Thanksgiving)
> ** All week: no train
> ** Mon/Tues: SWATs only 
> ** Wed/Thur/Fri: NO DEPLOYS
> * Nov 28th: normal
> * Dec 5th: normal
> * Dec 12th: normal
> * Dec 19th: NO DEPLOYS (XMAS)
> * Dec 26th: NO DEPLOYS (XMAS)
> * Jan 2nd: normal (with train)
> * Jan 9th: no train, SWATs only (but no one from RelEng is garaunteed to
> * be around) (DevSummit+All Hands)
> * Jan 16th: resume normalcy (Monday is MLK Day)
> 
> As always, the canonical location for deployment information is at:
> https://wikitech.wikimedia.org/wiki/Deployments
> 
> Best,
> 
> Greg
> 
> -- 
> | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
> | Release Team ManagerA18D 1138 8E47 FAC8 1C7D |



-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| Release Team ManagerA18D 1138 8E47 FAC8 1C7D |


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

Re: [Wikitech-l] [reading-wmf] Upcoming changes to PageImages

[Dan Garry]

Hey Olga,

I am very glad to hear about these changes! Thanks to your team for working
on them.

Dan

On 28 November 2016 at 11:20, Olga Vasileva  wrote:

> Hello everyone!
>
> In preparation for getting hovercards ready for release, the reading-web
> team has been working on some changes to the PageImages extension
>  to account for a
> number of bug reports on incorrect images or images that may appear out of
> context.  We are working on the following changes:
>
> 1. Allowing Non-free images to appear (when allowed)
> 2. Allowing PageImages to select images only from the lead section or
> infobox of an article
> 3. Allowing editors to set the PageImage for a page
>
> From these, we will be applying 1 and 2 within this quarter (and most
> likely by the end of this sprint).  More details on the changes, including
> corresponding tasks can be found here - https://www.mediawiki.org/
> wiki/Reading/Web/Projects/PageImagesChanges
>
> Thanks and let us know if there’s any questions!
>
> Cheers,
>
> - Olga
>
> --
> Olga Vasileva // Product Manager // Reading Web Team
> https://wikimediafoundation.org/
>
> ___
> reading-wmf mailing list
> reading-...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/reading-wmf
>
>


-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [MediaWiki-announce] MediaWiki 1.28 now available!

[Chad Horohoe]

On Mon, Nov 28, 2016 at 12:08 PM Chad Horohoe 
wrote:

> Hello everyone,
>
> I am happy to announce the availability the general release of MediaWiki
> 1.28!
>
>
Hi!

One minor note. The RELEASE-NOTES-1.28 was not updated prior to release and
still mentions that the software is an alpha/beta and not suitable for
production use.

It certainly is, and I apologize for the oversight. This is fixed in the
REL1_28 release branch and will be included in a 1.28.1, if/when it's
announced (I didn't figure a whole release bump was necessary for a
documentation fix).

Sorry if this caused any confusion!

-Chad
___
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] [MediaWiki-announce] MediaWiki 1.28 now available!

[Chad Horohoe]

Hello everyone,

I am happy to announce the availability the general release of MediaWiki
1.28!

MediaWiki 1.28 includes all changes released in the smaller 1.28.0-wmf.*
software deployments to Wikimedia sites over six months, totaling
approximately 2100 commits by around 120 authors. This is a large release
that contains many new features and bug fixes.

This is a summary of the major changes of interest to users and
administrators:
* https://www.mediawiki.org/wiki/MediaWiki_1.28

You can always consult the RELEASE-NOTES-1.28 file for the full list of
changes in this version.

Full release notes:
*
https://phabricator.wikimedia.org/diffusion/MW/browse/REL1_28/RELEASE-NOTES-1.28
* https://www.mediawiki.org/wiki/Release_notes/1.28

**
Download:
https://releases.wikimedia.org/mediawiki/1.28/mediawiki-1.28.0.tar.gz
https://releases.wikimedia.org/mediawiki/1.28/mediawiki-core-1.28.0.tar.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.28/mediawiki-1.28.0.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.28/mediawiki-core-1.28.0.tar.gz.sig

Public keys:
https://www.mediawiki.org/keys/keys.html

-Chad
___
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] WikipediaP2P

[Chad]

On Tue, Nov 22, 2016 at 11:33 AM bawolff  wrote:

> See also related discussion last year
> https://lists.wikimedia.org/pipermail/wikitech-l/2015-November/084143.html
>
>
And the year before, and before that, and before that... it's a perennial
proposal ;-)


> Personally I think this whole thing is a bad idea
> * Its questionable how much this would actually save anything. Cached
> anon hits are pretty cheap
>

Indeed.


> * This basically doesn't do cach invalidation. Lets just have
> vandalism stay around for long periods of time
>

Yep, that's always been a problem in these proposals.

* Probably makes it much easier for third parties to determine what
> you are browsing. (Censorship resistant p2p networks is still an open
> research problem last I checked)
>

Plus this.


> * Probably makes it easier for adversaries to selectively censor
> specific articles
> [I haven't looked at the implementation, but I'm going to guess here]
>

Basically because of the above.


> * Questionable how it would verify content is legit. What's stopping a
> malicious actor from putting random malicious js into the p2p network,
> or someone replacing articles with biased versions.
>
>
Same thing here. That being saidI'm curious if there's some sort of
middle ground here. I wonder how much (c|w)ould be saved by serving
static assets (CSS, UI images, etc etc) via P2P. Prolly not much in the
US/Europe, but in places with poor latency this could be interesting.

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

[Wikitech-l] [MediaWiki-announce] 1.26 EOL announcement

[Chad Horohoe]

Hi,

With the release of MediaWiki 1.28, the lifetime of MediaWiki version
1.26.x has come to an end.

Users still using MediaWiki 1.26.x are advised to upgrade to version
1.28.0, the latest stable version.

-Chad
___
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] WikipediaP2P

[Pine W]

I'd love to have Wikimedia content not be dependent on WMF servers, but as
noted by others, there are a lot of problems to address, including privacy
and security issues. At some point I think it might be good to have an
office hour or some other kind of meeting about this subject to discuss
possibilities. I won't be involved in this for the for the foreseeable
future due to the many other issues that are on my task list, but +1 moral
support. I'd like to see reduced dependency of Wikimedia content on WMF
included in the WMF strategic plan.

Pine


On Tue, Nov 22, 2016 at 11:48 AM, Gabriel Wicke 
wrote:

> For offline / poor connectivity use cases, I am more excited about
> https://wiki.mozilla.org/FlyWeb. In contrast to WebRTC based solutions,
> this enables completely local discovery and sharing of resources, without
> requiring an internet connection.
>
> WebRTC based P2P CDNs are not very useful for the most common Wikipedia
> session, which is a single page lookup after following a link from a search
> engine. They are more useful for live video streaming, where session
> length, resource size, and number of simultaneous users interested in the
> same chunks is more favorable.
>
> On Tue, Nov 22, 2016 at 11:33 AM, bawolff  wrote:
>
> > See also related discussion last year
> > https://lists.wikimedia.org/pipermail/wikitech-l/2015-
> November/084143.html
> >
> > Personally I think this whole thing is a bad idea
> > * Its questionable how much this would actually save anything. Cached
> > anon hits are pretty cheap
> > * This basically doesn't do cach invalidation. Lets just have
> > vandalism stay around for long periods of time
> > * Probably makes it much easier for third parties to determine what
> > you are browsing. (Censorship resistant p2p networks is still an open
> > research problem last I checked)
> > * Probably makes it easier for adversaries to selectively censor
> > specific articles
> > [I haven't looked at the implementation, but I'm going to guess here]
> > * Questionable how it would verify content is legit. What's stopping a
> > malicious actor from putting random malicious js into the p2p network,
> > or someone replacing articles with biased versions.
> >
> > --
> > bawolff
> >
> > On Tue, Nov 22, 2016 at 5:00 PM, Joaquin Oltra Hernandez
> >  wrote:
> > > Hi,
> > >
> > > I saw this project and I thought it was very interesting:
> > >
> > > https://www.wikipediap2p.org/
> > >
> > > Basically, it makes the clients connect to each other to share pages
> > > between each other using webrtc before going to the centralized server.
> > >
> > > It would probably be a bad idea to convert mobile devices into network
> > > peers given the data restrictions and quality of connections but it
> seems
> > > like something very interesting for the desktop clients.
> > >
> > > Cheers
> > > ___
> > > 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
> >
>
>
>
> --
> Gabriel Wicke
> Principal Engineer, Wikimedia Foundation
> ___
> 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] Per-language URLs for multilingual wiki pages (RFC discussion on Wednesday)

[Daniel Kinzler]

Hi all!

For this week's RFC discussion [1], let's talk about per-language URLs for
multilingual wiki pages[2]. The basic idea is to encode the uselang parameter
the the url path so it doesn't break caching. This raises some questions about
purging, and about rendering links.


The meeting will be the usual time (Wednesday 21 UTC, 14 PDT, 23 CEST)
and place (#wikimedia-office).


A brief synopsis of the RFC:

* Need: we want anon visitors to browse multilingual wikis in their language
* Problem: Serving different renderings for the same URL messes with web caches.
* Solution: Encode uselang in the URL path, generate links to the same URL path.

Discussion points:
* Is the proposed solution viable and useful?
* Can we use varnish's xkey feature to purge all language versions of a page?
* What should the path scheme look like? /wiki-fr/Foo or /fr/Foo or...
* On which wiki shall we try this first?
* How do we make a wiki-link to a specific language version of a page?


If you are interested, please comment on the ticket[2] and join the meeting[1].


[1] https://phabricator.wikimedia.org/E384
[2] https://phabricator.wikimedia.org/T114662

-- 
Daniel Kinzler
Senior Software Developer

Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.

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

[Wikitech-l] Upcoming changes to PageImages

[Olga Vasileva]

Hello everyone!

In preparation for getting hovercards ready for release, the reading-web
team has been working on some changes to the PageImages extension
 to account for a
number of bug reports on incorrect images or images that may appear out of
context.  We are working on the following changes:

1. Allowing Non-free images to appear (when allowed)
2. Allowing PageImages to select images only from the lead section or
infobox of an article
3. Allowing editors to set the PageImage for a page

From these, we will be applying 1 and 2 within this quarter (and most
likely by the end of this sprint).  More details on the changes, including
corresponding tasks can be found here -
https://www.mediawiki.org/wiki/Reading/Web/Projects/PageImagesChanges

Thanks and let us know if there’s any questions!

Cheers,

- Olga

-- 
Olga Vasileva // Product Manager // Reading Web Team
https://wikimediafoundation.org/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Voting's open on 2016 Community Wishlist Survey

[Danny Horn]

Hi everyone,

The voting has started on the 2016 Community Wishlist Survey, and all
Wikimedia contributors are invited to come and vote on the projects that
WMF's Community Tech team will work on next year:

https://meta.wikimedia.org/wiki/2016_Community_Wishlist_Survey

There are 267 proposals this year, on a wide range of subjects that I'm
pretty sure you have an opinion about.

You've got two weeks to vote, from now through December 12th. You can vote
for as many proposals as you like, by adding a {{support}} tag under the
proposals that you think are worthwhile.

Once the voting's over, we'll have a ranked list of projects for the
Community Tech team to work on, as well as other developers and volunteers
who want to build features and make changes that the core contributors
really want.

This is an opportunity for you to help set the agenda for a WMF product
team, so I hope everybody comes and participates!


Danny Horn
WMF Product Manager
Community Tech
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Google Code-in 2016 just started and we need your help!

[Andre Klapper]

Google Code-in 2016 just started:
https://www.mediawiki.org/wiki/Google_Code-in_2016

In the next seven weeks, many young people are going to make their
first contributions to Wikimedia. Expect many questions on IRC and
mailing lists by onboarding newcomers who have never used IRC or lists
before. Your help and patience is welcome to provide a helping hand!

Thanks to all mentors who have already registered & provided tasks!

You have not become a mentor yet? Please do consider it.
It is fun and we do need more tasks! :)

* Think of easy tasks in your area that you could mentor.
  Areas are: Code, docs/training, outreach/research, quality
  assurance, and user interface. "Easy" means 2-3h to complete for
  you, or less technical ~30min "beginner tasks" for onboarding).
* OR: provide an easy 'clonable' task (a task that is generic and
  could be repeated many times by different students).
* Note that you commit to answer to students' questions and to
  evaluate their work within 36 hours (but the better your task
  description the less questions. No worries, we're here to help!)

For the full info, please check out
https://www.mediawiki.org/wiki/Google_Code-in_2016/Mentors
and ask if something is unclear!

Thank you again for giving young contributors the opportunity to learn
about and work on all aspects of Free & Open Source Software projects!

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] Hovercards update

[Olga Vasileva]

Hi all, hi DJ

Thank you for your comments! Those are some valid concerns.  A few
clarifications and related updates:

   1. Current bugs: We have been tracking all current issues from the
   Greek/Catalan test. The page for the results also has some updates on each
   task here
   
.
   I'd also like to point out that we do not plan on releasing the feature
   before all these issues are resolved (except for the ones marked for future
   implementation) and thoroughly tested.
   2. Expected Functionality: The list of acceptance criteria before
   release, in terms of functionality, can be found here
   .
   All criteria necessary prior to release is noted on this page.  The page
   also has some ideas/new functionality which are marked for future
   iterations.
   3. Phabricator: since we are refactoring the hovercards code, we have
   decided to stall current bugs until after the refactor - we are hoping that
   most of them will no longer be applicable and can be immediately closed,
   but we're currently keeping them around to account for any edge cases that
   might occur.  The phabricator tasks currently lined up/in progress are the
   following:
  1. Refactoring and accounting for basic functionality:
  https://phabricator.wikimedia.org/T149801
  
  2. Visual design: https://phabricator.wikimedia.org/T150814
  3. Accounting for edge cases where previews are not available:
  https://phabricator.wikimedia.org/T151054
  4. Building preferences for logged-in users:
  https://phabricator.wikimedia.org/T146889
  5. Identifying service that will allow optimal summaries:
  https://phabricator.wikimedia.org/T113094,
https://phabricator.wikimedia.org/T151055,
  https://phabricator.wikimedia.org/T141766
   and
  https://phabricator.wikimedia.org/T141651
  6. Allowing hovercards to use RESTbase API endpoint:
  https://phabricator.wikimedia.org/T145429

Cheers,

Olga

On Tue, Nov 22, 2016 at 12:50 PM Derk-Jan Hartman <
d.j.hartman+wmf...@gmail.com> wrote:

> I'm glad to see progress on this front. I do however have one concern, and
> that is that multiple of the issues identified in A/B testing of 2015, are
> still open. I know there has been progress in several areas (esp. some of
> the objections raised in the en.wp consultation of early 2016), but if
> issues were important enough to mention them in the Greek Catalan report,
> and 80% of those issues are still open today, then this seems worthy
> evaluating to me.
>
> I also see little management and sorting of issues on the Phabricator
> dashboard, which gives me no ability to assess potential impact and make
> distinction between bugs that might impact the release, vs things that are
> enhancements, non-issues etc etc.
>
> DJ
>
>
> On Thu, Nov 17, 2016 at 6:00 PM, Chris Koerner 
> wrote:
>
> > Hello,
> > Hovercards, currently a beta feature, is nearing release. [0] We'd like
> to
> > encourage communities to adopt Hovercards as a default option for
> > logged-out readers. [1] Hovercards provide a preview of any linked
> article,
> > giving readers a quick understanding of a related article without leaving
> > the current page. The Reading web team recently completed a series of A/B
> > tests to gather information on how Hovercards are used.
> >
> > * April 2015 - Catalan and Greek A/B test results [2]
> > * Summer/Fall 2016 Hungarian, Italian, and Russian Wikipedia A/B test
> > results [3]
> > * 2016 Reading team UX research [4]
> >
> > As you can see the results of the tests were generally positive. A few
> key
> > highlights:
> >
> > * During the Catalan and Greek A/B test, 79% of respondents either Agreed
> > or Strongly Agreed that Hovercards were easy to use, 76% of respondents
> > either Agreed or Strongly Agreed that Hovercards were useful for their
> > needs.
> > * Users are viewing approximately 0.99 hovercards per session, and
> > interacting with approximately 31% more pages each session. [5]
> > * The disable rate was very low: the rate of clicking the settings cog
> for
> > Hovercards was 0.02% for Hungarian, 0.034% for Italian, and 0.016% for
> > Russian Wikipedia. The rates for disabling the feature were even lower.
> > * In our qualitative tests, 13 out of 15 questionnaire participants
> > reported positive experiences with Hovercards.
> >
> > == Rollout plan ==
> > The next step for Hovercards is to develop a plan for rolling the feature
> > out to all projects. We have created a draft proposal for which projects
> to
> > discuss Hovercards with and approximate timeline for deployments. [6]
> >
> > The Reading Web team will be reaching out to the communities in the order
> > listed above to discuss how to implement the feature. We want