[Wikitech-l] ResourceLoader addModuleStyles() issues

[Krinkle]

TL;DR: The current addModuleStyles() method no longer meets our
requirements. This mismatch causes bugs (e.g. user styles load twice). The
current logic also doesn't support dynamic modules depending on style
modules. I'm looking for feedback on how to best address these issues.


ResourceLoader is designed with two module types: Page style modules and
dynamic modules.

Page style modules are part of the critical rendering path and should work
without JavaScript being enabled or supported. Their URL must be referenced
directly in the HTML to allow browsers to discover them statically for
optimal performance.  As such, this URL can't use dynamic information from
the startup module (no dependencies[1], no version hashes).

Dynamic modules have their names listed in the page HTML. Their
dependencies and version hashes are resolved at run-time by JavaScript via
the startup manifest. We then generate the urls and request them from the
server. There is also a layer of object caching in-between (localStorage)
which often optimises the module request to not involve an HTTP request at
all.

Below I explain the two issues, followed by a proposed solution.

## Dependency

Historically there was no overlap between these two kinds of modules. Page
style modules were mostly dominated by the skin and apply to skin-specific
server-generated html. Dynamic modules (skin agnostic) would make their own
DOM and apply their own styles.

Now that we're reusing styles more, we're starting seeing to see overlap.
In the past we used jQuery UI - its styles never applied to PHP-generated
output. Now, with OOUI, its styles do apply to both server-side and
client-side generated elements. Its styles are preloaded as a page style
module on pages that contain OOUI widgets.

The OOjs UI bundle (and its additional styles) shouldn't need to know
whether the current page already got some of the relevant styles. This is
what dependencies are for. For OOUI specifically, we currently have a
hardcoded work around that adds a hidden marker to pages where OOUI is
preloaded. The OOUI style module has a skipFunction that forgoes loading if
the marker is present.

## Implicit type

Aside from the need for dependencies between dynamic and page style
modules. There is another bug related to this. We don't currently require
modules to say whether they are a dynamic module or a page style module. In
most cases this doesn't matter since a developer would only load it one way
and the module type is implied. For example, if you only ever pass a module
to addModules() or mw.loader() it is effectively a dynamic module. If you
only ever pass a module to addModuleStyles() loaded via a  then it is a page style module.

A problem happens if one tries to load the same module both ways. This
might seem odd (and it is), but happens unintentionally right now with wiki
modules (specifically, user/site modules and gadgets).

For user/site modules, we don't know whether common.css relates to the page
content, or whether it relates to dynamic content produced by common.js.
The same for gadgets. A gadget may produce an AJAX interface and register
styles for it, or the gadget may be styles-only and intended as a skin
customisation. Right now the Gadgets extension works around this problem
with a compromise: Load it both ways. First it loads all gadgets as page
style modules (ignoring the script portion), and then it loads the same
modules again as dynamic modules. Thus loading the styles twice.

## Proposed solution

In order to allow dependency relationships between a dynamic module and a
page style module, we need to inform mw.loader in JavaScript about which
modules have already been loaded by different means. We do this already
with the user modules (by setting mw.loader.state directly).

This would work but means that if you then load the same module again as
dynamic module, it will assume the module is already loaded and thus never
deliver the script portion (for the case where the gadget wasn't meant to
be a page style module). Similarly, it would mean that common.js wouldn't
get delivered if common.css exists.

For user/site modules I propose to solve this by splitting them up into
'user', 'user.styles', 'site' and 'site.styles'. Existing dependency
relationships between other modules and 'user' or 'site' will continue to
work. It'd mostly be an internal detail. This allows us to load one as a
page style module and the other dynamically.

For gadgets we can try to infer the intent (styles-only = page style
module, both = dynamic module), with perhaps a way to declare the desired
load method explicitly in Gadgets-definition if the default is wrong.

With that resolved, we can export mw.loader.state information for page
style modules, which then allows dynamic modules to depend on them.

Thoughts?

https://phabricator.wikimedia.org/T87871
https://phabricator.wikimedia.org/T92459

-- Krinkle


[1] If one would allow page style modules to have dependencies and resolve
t

[Wikitech-l] New mirror of 'other' datasets

[Ariel Glenn WMF]

I'm happy to announce a new mirror for datasets other than the XML dumps.
This mirror comes to us courtesy of the Center for Research Computing,
University of Notre Dame, and covers everything "other" [1] which includes
such goodies as Wikidata entity dumps, pageview counts, titles of all files
on each wiki (daily), titles of all articles of each wiki (daily), and the
so-called "adds-changes" dumps, among other things. You can access it at
http://wikimedia.crc.nd.edu/other/ so please do!

Ariel

[1] https://dumps.wikimedia.org/other/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] ResourceLoader addModuleStyles() issues

[Brion Vibber]

Quick notes on the migration path:


*Cached page HTML*

HTML cached under the old regime would still be served for a while, but
ResourceLoader would load the newer style. I *think* that should work as
long as the new versions of the modules that were included before still
list the style-only modules as dependencies, assuming load.php doesn't
throw an exception when the code-plus-style modules are requested.

If load.php would throw an exception in this case, then that's going to be
a tricky problem to figure out for end-users, who will be presented with
unstyled pages and no visible error message.


*Extension authors and users of extensions*

If addModuleStyles() throws a PHP exception at page-output time for modules
that include scripts, that's a breaking change for extension authors and
the people who use their extensions; but at least the error message will be
very direct and immediate.

It'll need to be called out in the release notes with a section about
breaking upgrade changes.

Ideally, the resulting error message that is displayed should also be very
clear and include a link to a documentation page explaining how extension
authors can update their code appropriately.

-- brion



On Wed, May 4, 2016 at 3:34 AM, Krinkle  wrote:

> TL;DR: The current addModuleStyles() method no longer meets our
> requirements. This mismatch causes bugs (e.g. user styles load twice). The
> current logic also doesn't support dynamic modules depending on style
> modules. I'm looking for feedback on how to best address these issues.
>
>
> ResourceLoader is designed with two module types: Page style modules and
> dynamic modules.
>
> Page style modules are part of the critical rendering path and should work
> without JavaScript being enabled or supported. Their URL must be referenced
> directly in the HTML to allow browsers to discover them statically for
> optimal performance.  As such, this URL can't use dynamic information from
> the startup module (no dependencies[1], no version hashes).
>
> Dynamic modules have their names listed in the page HTML. Their
> dependencies and version hashes are resolved at run-time by JavaScript via
> the startup manifest. We then generate the urls and request them from the
> server. There is also a layer of object caching in-between (localStorage)
> which often optimises the module request to not involve an HTTP request at
> all.
>
> Below I explain the two issues, followed by a proposed solution.
>
> ## Dependency
>
> Historically there was no overlap between these two kinds of modules. Page
> style modules were mostly dominated by the skin and apply to skin-specific
> server-generated html. Dynamic modules (skin agnostic) would make their own
> DOM and apply their own styles.
>
> Now that we're reusing styles more, we're starting seeing to see overlap.
> In the past we used jQuery UI - its styles never applied to PHP-generated
> output. Now, with OOUI, its styles do apply to both server-side and
> client-side generated elements. Its styles are preloaded as a page style
> module on pages that contain OOUI widgets.
>
> The OOjs UI bundle (and its additional styles) shouldn't need to know
> whether the current page already got some of the relevant styles. This is
> what dependencies are for. For OOUI specifically, we currently have a
> hardcoded work around that adds a hidden marker to pages where OOUI is
> preloaded. The OOUI style module has a skipFunction that forgoes loading if
> the marker is present.
>
> ## Implicit type
>
> Aside from the need for dependencies between dynamic and page style
> modules. There is another bug related to this. We don't currently require
> modules to say whether they are a dynamic module or a page style module. In
> most cases this doesn't matter since a developer would only load it one way
> and the module type is implied. For example, if you only ever pass a module
> to addModules() or mw.loader() it is effectively a dynamic module. If you
> only ever pass a module to addModuleStyles() loaded via a  rel=stylesheet> then it is a page style module.
>
> A problem happens if one tries to load the same module both ways. This
> might seem odd (and it is), but happens unintentionally right now with wiki
> modules (specifically, user/site modules and gadgets).
>
> For user/site modules, we don't know whether common.css relates to the page
> content, or whether it relates to dynamic content produced by common.js.
> The same for gadgets. A gadget may produce an AJAX interface and register
> styles for it, or the gadget may be styles-only and intended as a skin
> customisation. Right now the Gadgets extension works around this problem
> with a compromise: Load it both ways. First it loads all gadgets as page
> style modules (ignoring the script portion), and then it loads the same
> modules again as dynamic modules. Thus loading the styles twice.
>
> ## Proposed solution
>
> In order to allow dependency relationships between a dynamic module and a
> page styl

[Wikitech-l] "Troubleshooting Git/Gerrit/git-review" docs: Help welcome.

[Andre Klapper]

Hej,

I went ahead & centralized the 5 git/Gerrit/git-review troubleshooting
sections that I've found so far on random mediawiki.org pages into one
single page (and eliminated duplicates with different solutions):
 
https://www.mediawiki.org/wiki/Gerrit/Troubleshooting

1) More help is welcome to clean up and structure that page (plain git
vs. git-review vs. Gerrit UI).

2) As a user, I prefer section headings to describe problems instead of
solutions (as I don't know which solution is related to my problem).
On https://www.mediawiki.org/wiki/Gerrit/Tutorial there is one section
called "Pushing via HTTPS when SSH is not functional" which I'd also
like to move to [[mw:Gerrit/Troubleshooting]].
Anyone knows how users would actually realize that SSH is not
functional? (Specific output after a specific command?)
How would Gerrit users realize they are behind a proxy server?

Thanks for your help.

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] "Troubleshooting Git/Gerrit/git-review" docs: Help welcome.

[Tony Thomas]

On Wed, May 4, 2016 at 7:29 PM, Andre Klapper 
wrote:

> Anyone knows how users would actually realize that SSH is not
> functional? (Specific output after a specific command?)
>

They run $ ssh -p 29418 @gerrit.wikimedia.org -v  and would not
get a welcome message!

Simpler method would be $ telnet gerrit.wikimedia.org 29418   and it would
hang up like anything!

Thanks,
Tony Thomas 
Home  | Blog  |
ThinkFOSS 
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] ResourceLoader addModuleStyles() issues

[Brad Jorsch (Anomie)]

On Wed, May 4, 2016 at 6:34 AM, Krinkle  wrote:

> ## Implicit type
>
> Aside from the need for dependencies between dynamic and page style
> modules. There is another bug related to this. We don't currently require
> modules to say whether they are a dynamic module or a page style module.


Maybe we *should* require that.

Then that could allow us to resolve one of my pet peeves with
ResourceLoader: we can remove the need for general developers to know which
modules need addModules() and which need addModuleStyles(). They can use
addModules() for all modules and RL can just do the right thing based on
the information provided by the creator of the module who is more likely to
actually know whether something needs to be in  or JS-loaded.

Although for maximum benefit there, we would also have to make RL resolve
dependencies to collect all the page style modules on the server side (more
on that below). This would also be an improvement for general developers,
as they would no longer need to know that the module they want to use has
some dependency that needs to have addModuleStyles() manually called.

>
> For gadgets we can try to infer the intent (styles-only = page style
> module, both = dynamic module), with perhaps a way to declare the desired
> load method explicitly in Gadgets-definition if the default is wrong.
>

A gadget might want both: a handful of "page" styles to prevent FoUC, and a
much larger set of "dynamic" styles that can be loaded asynchronously along
with the JS so as to not delay the rest of the page.


> [1] If one would allow page style modules to have dependencies and resolve
> them server-side in the HTML output, this would cause corruption when the
> relationship between two modules changes as existing pages would have the
> old relationship cached but do get the latest content from the server.
> Adding versions wouldn't help since the server can't feasibly have access
> to previous versions (too many page/skin/language combinations).
>

But don't we have the corruption anyway? Say page Foo has a page style
module 'foo', so it calls addModuleStyles( [ 'foo' ] ). Then module 'foo'
is changed so it also needs 'bar', so page Foo now has to call
addModuleStyles( [ 'foo', 'bar' ] ). What is avoided there that isn't
avoided when addModuleStyles( [ 'foo' ] ) is smart enough to internally see
that 'foo' depends on 'bar' and act as if it were passed [ 'foo', 'bar' ]?
Or what case am I missing?

On the other hand, dependencies avoid the case where the developer
modifying 'foo' doesn't realize that he has to search for everything
everywhere that passes 'foo' to addModuleStyles() and manually add 'bar' to
each one.

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] "Troubleshooting Git/Gerrit/git-review" docs: Help welcome.

[Brad Jorsch (Anomie)]

On Wed, May 4, 2016 at 9:59 AM, Andre Klapper 
wrote:

> On https://www.mediawiki.org/wiki/Gerrit/Tutorial there is one section
> called "Pushing via HTTPS when SSH is not functional" which I'd also
> like to move to [[mw:Gerrit/Troubleshooting]].
> Anyone knows how users would actually realize that SSH is not
> functional? (Specific output after a specific command?)
>

They'd probably realize it when they run any git command that tries to
communicate with the server and it outputs an error message that refers to
connecting via ssh, e.g. "ssh: connect to host gerrit.wikimedia.org port
29418: Connection refused" or "ssh: connect to host gerrit.wikimedia.org
port 29418: Network is unreachable" from the command-line git client.

Then they can more directly test that it's ssh with the commands Tony
Thomas posted.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Ownership of Selenium tests

[Željko Filipin]

TLDR: If you care about Selenium tests that run daily[1], please take
ownership of repository (or repositories) that you care about.

Our Selenium tests provide useful feedback, finding problems in several
places, when there is something wrong with:

#1 the repository they are testing (broken production or test code),
#2 beta and/or production clusters,
#3 continuous integration.

It is really important that all tests that run daily are green all the
time. I have started cleaning up tests[2-3].

If there is a failure, we have to investigate and fix it as soon as
possible, ideally in one business day. To be able to do that, we need
contact information for each repository. I have started collecting contact
details [3] from various sources.

What does taking ownership mean? Your e-mail address will be added to
Jenkins job repository configuration[4] and you will receive one e-mail a
day per repository and job, but only if there are any failed jobs. In
short, if you are an owner of one repository with one job, you will receive
0-2 e-mails a day, depending on the stability of the job. It will be your
responsibility to fix the job. If you need help, I will be glad to help.

The contact e-mail address can be one or more people, or a team mailing
list. All I need is a reply if I send an e-mail message to that address,
without having to be a member of a lot of mailing lists.

Jobs for repositories without contact person will be running while they are
passing, and will be deleted when they start failing.

To become a contact person, submit a patch[4] or let me know off-list.

Questions? Comments? Please do let me know.

Željko
--
1: https://integration.wikimedia.org/ci/view/Selenium/
2: https://phabricator.wikimedia.org/T94150
3: https://phabricator.wikimedia.org/T128190
4:
https://phabricator.wikimedia.org/diffusion/CICF/browse/master/jjb/selenium.yaml$1-18
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] ResourceLoader addModuleStyles() issues

[Brion Vibber]

On Wed, May 4, 2016 at 8:23 AM, Brad Jorsch (Anomie) 
wrote:

> On Wed, May 4, 2016 at 6:34 AM, Krinkle  wrote:
> > [1] If one would allow page style modules to have dependencies and
> resolve
> > them server-side in the HTML output, this would cause corruption when the
> > relationship between two modules changes as existing pages would have the
> > old relationship cached but do get the latest content from the server.
> > Adding versions wouldn't help since the server can't feasibly have access
> > to previous versions (too many page/skin/language combinations).
> >
>
> But don't we have the corruption anyway? Say page Foo has a page style
> module 'foo', so it calls addModuleStyles( [ 'foo' ] ). Then module 'foo'
> is changed so it also needs 'bar', so page Foo now has to call
> addModuleStyles( [ 'foo', 'bar' ] ). What is avoided there that isn't
> avoided when addModuleStyles( [ 'foo' ] ) is smart enough to internally see
> that 'foo' depends on 'bar' and act as if it were passed [ 'foo', 'bar' ]?
> Or what case am I missing?
>
> On the other hand, dependencies avoid the case where the developer
> modifying 'foo' doesn't realize that he has to search for everything
> everywhere that passes 'foo' to addModuleStyles() and manually add 'bar' to
> each one.
>

H... wait, does load.php not resolve dependencies server-side when
producing concatenated CSS output? That would seem to break the
transitional model I proposed if so.

Ah, fun. :)

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

Re: [Wikitech-l] New mirror of 'other' datasets

[Jonathan Morgan]

Awesome! Great to hear that we're making these resources more widely
available. Nice to have good partners :) - Jonathan

On Wed, May 4, 2016 at 5:33 AM, Ariel Glenn WMF  wrote:

> I'm happy to announce a new mirror for datasets other than the XML dumps.
> This mirror comes to us courtesy of the Center for Research Computing,
> University of Notre Dame, and covers everything "other" [1] which includes
> such goodies as Wikidata entity dumps, pageview counts, titles of all files
> on each wiki (daily), titles of all articles of each wiki (daily), and the
> so-called "adds-changes" dumps, among other things. You can access it at
> http://wikimedia.crc.nd.edu/other/ so please do!
>
> Ariel
>
> [1] https://dumps.wikimedia.org/other/
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Jonathan T. Morgan
Senior Design Researcher
Wikimedia Foundation
User:Jmorgan (WMF) 
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Phabricator upgrade and UI changes

[Federico Leva (Nemo)]

AFAICT, in the last few days there were two unannounced upgrades of 
Phabricator, to an unspecified version of the software, the second of 
which applied rather radical UI changes, especially to Maniphest.


Initially I wasn't sure most/which UI changes were bad/good or why, but 
now I've observed myself for a few days and I took the time to take 
screenshots and describe my findings. Of course, most are about

* the consistent enlargement of some items to the expense of others,
* the introduction of a sidebar to host an ever-growing amount of buttons,
* the move of most task information under the description or under the 
sidebar.


Please comment on the reports, add your findings and file new reports 
for separate issues (I've not tested areas outside Maniphest, for instance):

* https://phabricator.wikimedia.org/T134393
* https://phabricator.wikimedia.org/T134394
* https://phabricator.wikimedia.org/T134398

It would also be nice to have some precise and authoritative information 
on when Phabricator was upgrade to what version, what the release notes 
and gotchas are, etc. Did I miss such an announcement and if yes where 
is it?


Nemo

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

Re: [Wikitech-l] Phabricator upgrade and UI changes

[James Forrester]

On 4 May 2016 at 11:57, Federico Leva (Nemo)  wrote:

> It would also be nice to have some precise and authoritative information
> on when Phabricator was upgrade to what version, what the release notes and
> gotchas are, etc.
> ​ ​
>

​It'd be great if there was more content from upstream on this, yes;
https://secure.phabricator.com/w/changelog/ is very detailed which is great
for adjusting code but doesn't summarise the 2–3 most important parts, I
agree. I'm sure they'd welcome some help if someone was so-minded to
assist.​


Did I miss such an announcement and if yes where is it?


​The best place for the WMF-side updates is
​
https://phabricator.wikimedia.org/T128009
​, part of the regular (monthly?) series listed on the Deployments page. I
note though this one wasn't listed in ​Tech/News, which might have helped a
little.

-- 
James D. Forrester
Lead Product Manager, Editing
Wikimedia Foundation, Inc.

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

Re: [Wikitech-l] "Troubleshooting Git/Gerrit/git-review" docs: Help welcome.

[Tony Thomas]

Something I always found missing in
https://www.mediawiki.org/wiki/Gerrit/Tutorial is:

'Amending a change using HTTPS '

Is this documented somewhere ? Usually in campus networks SSH ports are
blocked, and this one is a huge blocker to University Hackathons!

Thanks,
Tony Thomas 
Home  | Blog  |
ThinkFOSS 


On Wed, May 4, 2016 at 9:12 PM, Brad Jorsch (Anomie) 
wrote:

> On Wed, May 4, 2016 at 9:59 AM, Andre Klapper 
> wrote:
>
> > On https://www.mediawiki.org/wiki/Gerrit/Tutorial there is one section
> > called "Pushing via HTTPS when SSH is not functional" which I'd also
> > like to move to [[mw:Gerrit/Troubleshooting]].
> > Anyone knows how users would actually realize that SSH is not
> > functional? (Specific output after a specific command?)
> >
>
> They'd probably realize it when they run any git command that tries to
> communicate with the server and it outputs an error message that refers to
> connecting via ssh, e.g. "ssh: connect to host gerrit.wikimedia.org port
> 29418: Connection refused" or "ssh: connect to host gerrit.wikimedia.org
> port 29418: Network is unreachable" from the command-line git client.
>
> Then they can more directly test that it's ssh with the commands Tony
> Thomas posted.
>
>
> --
> Brad Jorsch (Anomie)
> Senior Software 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

Re: [Wikitech-l] Phabricator upgrade and UI changes

[Brion Vibber]

I find it very aggravating the that the author of a task is now very far
away on screen from their comment. Makes it difficult to tell what's going
on and harder to target a reply directly at them.

-- brion

On Wed, May 4, 2016 at 8:57 AM, Federico Leva (Nemo) 
wrote:

> AFAICT, in the last few days there were two unannounced upgrades of
> Phabricator, to an unspecified version of the software, the second of which
> applied rather radical UI changes, especially to Maniphest.
>
> Initially I wasn't sure most/which UI changes were bad/good or why, but
> now I've observed myself for a few days and I took the time to take
> screenshots and describe my findings. Of course, most are about
> * the consistent enlargement of some items to the expense of others,
> * the introduction of a sidebar to host an ever-growing amount of buttons,
> * the move of most task information under the description or under the
> sidebar.
>
> Please comment on the reports, add your findings and file new reports for
> separate issues (I've not tested areas outside Maniphest, for instance):
> * https://phabricator.wikimedia.org/T134393
> * https://phabricator.wikimedia.org/T134394
> * https://phabricator.wikimedia.org/T134398
>
> It would also be nice to have some precise and authoritative information
> on when Phabricator was upgrade to what version, what the release notes and
> gotchas are, etc. Did I miss such an announcement and if yes where is it?
>
> Nemo
>
> ___
> 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] Phabricator upgrade and UI changes

[Andre Klapper]

Hej,

On Wed, 2016-05-04 at 17:57 +0200, Federico Leva (Nemo) wrote:
> It would also be nice to have some precise and authoritative information 
> on when Phabricator was upgrade to what version, what the release notes 
> and gotchas are, etc. Did I miss such an announcement and if yes where 
> is it?

Upgrades happen in the weekly Phab maintenance window (Thu -0100UTC):
https://www.mediawiki.org/wiki/Phabricator/Maintenance 

The latest upgrade was on Thu April 28th:
https://phabricator.wikimedia.org/T128009
The next upgrade is tracked in
https://phabricator.wikimedia.org/T133820

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] [Wikimediaindia-l] How to click custom html option button via api?

[Shrinivasan T]

import pywikibot
from pywikibot import proofreadpage

site = pywikibot.Site('ta','wikisource')
page = pywikibot.Page(site, u"Page:")
text = page.text

pa = proofreadpage.ProofreadPage(page)


pa.text = pa.text.replace('level="1"','level="3"')

pa.save(summary="demo")


===

When I ran the above code now,

It gives the following error.

Run the following code.

it shows the following error.

ERROR: editpage: unknown failure reason {u'edit': {u'result': u'Failure',
u'notallowed': u'\u0b87\u0ba8\u0bcd\u0ba4
\u0baa\u0b95\u0bcd\u0b95\u0ba4\u0bcd\u0ba4\u0bbf\u0ba9\u0bcd
\u0bae\u0bc6\u0baf\u0bcd\u0baa\u0bcd\u0baa\u0bc1
\u0baa\u0bbe\u0bb0\u0bcd\u0b95\u0bcd\u0b95\u0bc1\u0bae\u0bcd
\u0ba8\u0bbf\u0bb2\u0bc8\u0baf\u0bc8 \u0bae\u0bbe\u0bb1\u0bcd\u0bb1
\u0ba4\u0b99\u0bcd\u0b95\u0bb3\u0bc1\u0b95\u0bcd\u0b95\u0bc1
\u0b89\u0bb0\u0bbf\u0bae\u0bc8 \u0b87\u0bb2\u0bcd\u0bb2\u0bc8'}}
WARNING: Page [[Page:x?r?nxc? mlrx.pdf/100]] not saved


on running on jupyter,

ERROR: editpage: unknown failure reason {'edit': {'result': 'Failure',
'notallowed': 'you
dont have permissions to change the proof read status of this
page'}}


The above error happens for my account and my friend account with sysop
permission.

But we can manually change the proof read page quality status.

What may be the reason?

Help to solve this.

Thanks.


-- 
Regards,
T.Shrinivasan


My Life with GNU/Linux : http://goinggnu.wordpress.com
Free E-Magazine on Free Open Source Software in Tamil : http://kaniyam.com

Get Free Tamil Ebooks for Android, iOS, Kindle, Computer :
http://FreeTamilEbooks.com
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Last call: on the idea of "last call"

[Rob Lanphier]

Hi folks,

One thing we've implicitly adopted is "last calls" for ArchCom-RFCs.
I filed it as an RFC to get it on our workboard:
https://phabricator.wikimedia.org/T120164

However, what that means is that we need to have a last call on the
"last call" RFC.  Obligatory xkcd reference: https://xkcd.com/244/

Barring objection in Phab, we'll consider T120164 approved then.

Rob

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

Re: [Wikitech-l] Phabricator upgrade and UI changes

[Mukunda Modell]

I held off on this upgrade for a while trying to let the changes mature
upstream, hoping that they might come to their senses. That never happened.

Many people might prefer the 'tablet' layout which can be activated by
changing the css class on the  element from 'device-desktop' to
'device'

Phabricator automatically switches to this mode when the window is between
400px and 768px wide, however, I find that it is a pleasant alternative to
the desktop layout, even at resolutions much greater than 768px.


On Wed, May 4, 2016 at 12:19 PM, Andre Klapper 
wrote:

> Hej,
>
> On Wed, 2016-05-04 at 17:57 +0200, Federico Leva (Nemo) wrote:
> > It would also be nice to have some precise and authoritative information
> > on when Phabricator was upgrade to what version, what the release notes
> > and gotchas are, etc. Did I miss such an announcement and if yes where
> > is it?
>
> Upgrades happen in the weekly Phab maintenance window (Thu -0100UTC):
> https://www.mediawiki.org/wiki/Phabricator/Maintenance
>
> The latest upgrade was on Thu April 28th:
> https://phabricator.wikimedia.org/T128009
> The next upgrade is tracked in
> https://phabricator.wikimedia.org/T133820
>
> 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
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Fwd: [Wikimedia-l] Invitation to upcoming office hours with interim ED

[Pine W]

Forwarding.

Pine
-- Forwarded message --
From: "Katherine Maher" 
Date: May 4, 2016 17:47
Subject: [Wikimedia-l] Invitation to upcoming office hours with interim ED
To: , , <
wikimediaannounc...@lists.wikimedia.org>
Cc:

Hi everyone,

**Summary: I am delighted to invite you to join me for two upcoming office
hours, where I’ll answer community questions and share updates on the
Foundation’s work.**

It’s been a busy few weeks around the Wikimedia Foundation offices. We
shared our 2016-2017 annual plan, finished our quarterly reviews, and
attended Wikimedia Conference 2016 in Berlin with the Wikimedia affiliates.
[1]

In Berlin, I had the chance to do one of my favorite things: sit with
Wikimedians, listen, debate, and plan for the future. Of course, Berlin is
just one gathering, and there are thousands of other perspectives out
there. I want to hear more of these perspectives, and so I’m looking
forward to hosting two office hours over the coming weeks.

We plan to hold a traditional office hours on IRC, and will also experiment
with a video Q&A. We hope these different formats will make it easier for
more people to participate using their preferred communications channels.
We’ve chosen two different time zones, with the goal of reaching as many
people as possible. They are as follows:

*Video session*
*This session will be recorded, and the video will be posted on
Commons/Meta. Due to video conferencing limitations, we encourage advance
questions.*
Wednesday, 11 May 2016
00:00-1:00 UTC | 17:00-18:00 PDT [2]

*IRC session*
*This session follows the May monthly metrics meeting.[4] Like other office
hours, it will be held in #Wikimedia-office on Freenode.*
Thursday, 26 May 2016
19:00-20:00 UTC | 12:00-13:00 PDT [3]

We’re also collecting questions in advance for those who can’t make either
of those sessions. We’ve created a page on Meta where you can leave
questions or comments, check the details on the location of each session:
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Executive_Director/May_2016_office_hours

Please share this invitation with others you think may be interested!

I look forward to speaking soon,
Katherine

Translation notice - This message is available for translation on
Meta-Wiki:
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Executive_Director/May_2016_office_hours/Announcement

[1] https://meta.wikimedia.org/wiki/Wikimedia_Conference_2016
[2] Time converter link:
http://www.timeanddate.com/worldclock/fixedtime.html?hour=0&min=00&sec=0&day=12&month=05&year=2016
[3] Time converter link:
http://www.timeanddate.com/worldclock/fixedtime.html?hour=19&min=00&sec=0&day=26&month=05&year=2016
[4] https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings


--
Katherine Maher

Wikimedia Foundation
149 New Montgomery Street
San Francisco, CA 94105

+1 (415) 839-6885 ext. 6635
+1 (415) 712 4873
kma...@wikimedia.org
___
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: 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

[Wikitech-l] REL1_27 branches up

[Chad]

Hi,

Sorry for the delay, I've had a few too many things to get done this week
so I haven't communicated as clearly as I should've.

The release branches (REL1_27) have been created for MW core, vendor,
all extensions and all skins. MediaWiki core is now on 1.28.0-alpha.

It's time to start testing out the release branch and make sure everything
is good and polished. You can do this on your vagrant by navigating to
the mediawiki/ directory and checking out the branches.

If you find a problem in the release, please file a task in Phabricator or
submit a patch.

Minor reminder: please don't start landing large breaking changes on
master now that we've swapped...it makes porting patches between
branches way more difficult than they need to be :)

Thanks and have a great week!

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

[Wikitech-l] Fall 2015 Tool Labs user survey data published

[Bryan Davis]

[0]: https://meta.wikimedia.org/wiki/Research:Annual_Tool_Labs_Survey
-- 
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

Re: [Wikitech-l] Fall 2015 Tool Labs user survey data published

[Bryan Davis]

On Wed, May 4, 2016 at 7:57 PM, Bryan Davis  wrote:
> [0]: https://meta.wikimedia.org/wiki/Research:Annual_Tool_Labs_Survey

Apologies for that abrupt initial message, that was a great example of
hitting the wrong key in a mail client. :)

Between 2015-09-25 and 2015-10-08, the Wikimedia Foundation ran a
direct response user survey of registered Tool Labs users. 106 users
responded to the survey.

Based on responses to demographic questions, the average[1] respondent:
* Has used Tool Labs for 1-3 years
* Developed & maintains 1-3 tools
* Spends an hour or less a week using Tool Labs
* Programs using PHP and/or Python
* Does the majority of their work locally
* Uses source control
* Was not a developer or maintainer on Toolserver

[1]: "Average" here means a range of responses covering 50% or more of
responses to the question. This summarization is coarse, but useful as
a broad generalization. Detailed demographic response data will be
made available on wiki.

Qualitative questions:
64% agree that services have high reliability (up time).
69% agree that it is easy to write code and have it running on Tool Labs.
67% agree that they feel they are supported by the Tool Labs team when
they contact them via labs-l mailing list, #wikimedia-labs IRC
channel, or phabricator.
53% agree that they receive useful information via labs-announce /
labs-l mailing lists.
52% disagree that documentation is easy-to-find.
71% find the support they receive when using Tool Labs as good or
better than the support they received when using Toolserver.
50% disagree that Tool Labs documentation is comprehensive.
50% agree that Tool Labs documentation is clear.

Service usage:
45% use LabsDB often.
60% use webservices often.
54% use cronjobs often.
75% never use redis.
41% never use continuous jobs .

The survey included several free form response sections. Survey
participants were told that we would only publicly share their
responses or survey results in aggregate or anonymized form. The
freeform responses include comments broadly falling into these
categories:

Documentation (33 comments)
Stability and performance (18 comments)
Version control and Deployment (14 comments)
Logs, Metrics, and Monitoring (12 comments)
Package management (10 comments)
SGE (8 comments)
Database (7 comments)
Account/Tool creation (5 comments)
SSH (5 comments)
Other (11 comments)

Additonal details are available on meta [2].

[2]: https://meta.wikimedia.org/wiki/Research:Annual_Tool_Labs_Survey

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

Re: [Wikitech-l] Fwd: [Wikimedia-l] Invitation to upcoming office hours with interim ED

[Risker]

Just noting that 1700-1800 PDT on Wednesday May 11 is -0100 UTC on
Thursday May 12. Based on the link given, this seems to be when the meeting
will be held. Please verify.

Risker/Anne

On 4 May 2016 at 21:28, Pine W  wrote:

> Forwarding.
>
> Pine
> -- Forwarded message --
> From: "Katherine Maher" 
> Date: May 4, 2016 17:47
> Subject: [Wikimedia-l] Invitation to upcoming office hours with interim ED
> To: , , <
> wikimediaannounc...@lists.wikimedia.org>
> Cc:
>
> Hi everyone,
>
> **Summary: I am delighted to invite you to join me for two upcoming office
> hours, where I’ll answer community questions and share updates on the
> Foundation’s work.**
>
> It’s been a busy few weeks around the Wikimedia Foundation offices. We
> shared our 2016-2017 annual plan, finished our quarterly reviews, and
> attended Wikimedia Conference 2016 in Berlin with the Wikimedia affiliates.
> [1]
>
> In Berlin, I had the chance to do one of my favorite things: sit with
> Wikimedians, listen, debate, and plan for the future. Of course, Berlin is
> just one gathering, and there are thousands of other perspectives out
> there. I want to hear more of these perspectives, and so I’m looking
> forward to hosting two office hours over the coming weeks.
>
> We plan to hold a traditional office hours on IRC, and will also experiment
> with a video Q&A. We hope these different formats will make it easier for
> more people to participate using their preferred communications channels.
> We’ve chosen two different time zones, with the goal of reaching as many
> people as possible. They are as follows:
>
> *Video session*
> *This session will be recorded, and the video will be posted on
> Commons/Meta. Due to video conferencing limitations, we encourage advance
> questions.*
> Wednesday, 11 May 2016
> 00:00-1:00 UTC | 17:00-18:00 PDT [2]
>
> *IRC session*
> *This session follows the May monthly metrics meeting.[4] Like other office
> hours, it will be held in #Wikimedia-office on Freenode.*
> Thursday, 26 May 2016
> 19:00-20:00 UTC | 12:00-13:00 PDT [3]
>
> We’re also collecting questions in advance for those who can’t make either
> of those sessions. We’ve created a page on Meta where you can leave
> questions or comments, check the details on the location of each session:
>
> https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Executive_Director/May_2016_office_hours
>
> Please share this invitation with others you think may be interested!
>
> I look forward to speaking soon,
> Katherine
>
> Translation notice - This message is available for translation on
> Meta-Wiki:
>
> https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Executive_Director/May_2016_office_hours/Announcement
>
> [1] https://meta.wikimedia.org/wiki/Wikimedia_Conference_2016
> [2] Time converter link:
>
> http://www.timeanddate.com/worldclock/fixedtime.html?hour=0&min=00&sec=0&day=12&month=05&year=2016
> [3] Time converter link:
>
> http://www.timeanddate.com/worldclock/fixedtime.html?hour=19&min=00&sec=0&day=26&month=05&year=2016
> [4] https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings
>
>
> --
> Katherine Maher
>
> Wikimedia Foundation
> 149 New Montgomery Street
> San Francisco, CA 94105
>
> +1 (415) 839-6885 ext. 6635
> +1 (415) 712 4873
> kma...@wikimedia.org
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> New messages to: 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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Labs-l] Fall 2015 Tool Labs user survey data published

[Pine W]

Hi Bryan,

Thanks for the report. With this information in hand, what follow up is
planned?

Pine
On May 4, 2016 19:01, "Bryan Davis"  wrote:

> On Wed, May 4, 2016 at 7:57 PM, Bryan Davis  wrote:
> > [0]: https://meta.wikimedia.org/wiki/Research:Annual_Tool_Labs_Survey
>
> Apologies for that abrupt initial message, that was a great example of
> hitting the wrong key in a mail client. :)
>
> Between 2015-09-25 and 2015-10-08, the Wikimedia Foundation ran a
> direct response user survey of registered Tool Labs users. 106 users
> responded to the survey.
>
> Based on responses to demographic questions, the average[1] respondent:
> * Has used Tool Labs for 1-3 years
> * Developed & maintains 1-3 tools
> * Spends an hour or less a week using Tool Labs
> * Programs using PHP and/or Python
> * Does the majority of their work locally
> * Uses source control
> * Was not a developer or maintainer on Toolserver
>
> [1]: "Average" here means a range of responses covering 50% or more of
> responses to the question. This summarization is coarse, but useful as
> a broad generalization. Detailed demographic response data will be
> made available on wiki.
>
> Qualitative questions:
> 64% agree that services have high reliability (up time).
> 69% agree that it is easy to write code and have it running on Tool Labs.
> 67% agree that they feel they are supported by the Tool Labs team when
> they contact them via labs-l mailing list, #wikimedia-labs IRC
> channel, or phabricator.
> 53% agree that they receive useful information via labs-announce /
> labs-l mailing lists.
> 52% disagree that documentation is easy-to-find.
> 71% find the support they receive when using Tool Labs as good or
> better than the support they received when using Toolserver.
> 50% disagree that Tool Labs documentation is comprehensive.
> 50% agree that Tool Labs documentation is clear.
>
> Service usage:
> 45% use LabsDB often.
> 60% use webservices often.
> 54% use cronjobs often.
> 75% never use redis.
> 41% never use continuous jobs .
>
> The survey included several free form response sections. Survey
> participants were told that we would only publicly share their
> responses or survey results in aggregate or anonymized form. The
> freeform responses include comments broadly falling into these
> categories:
>
> Documentation (33 comments)
> Stability and performance (18 comments)
> Version control and Deployment (14 comments)
> Logs, Metrics, and Monitoring (12 comments)
> Package management (10 comments)
> SGE (8 comments)
> Database (7 comments)
> Account/Tool creation (5 comments)
> SSH (5 comments)
> Other (11 comments)
>
> Additonal details are available on meta [2].
>
> [2]: https://meta.wikimedia.org/wiki/Research:Annual_Tool_Labs_Survey
>
> Bryan
> --
> Bryan Davis  Wikimedia Foundation
> [[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
> irc: bd808v:415.839.6885 x6855
>
> ___
> Labs-l mailing list
> lab...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/labs-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] "Troubleshooting Git/Gerrit/git-review" docs: Help welcome.

[Andrew Bogott]

On 5/4/16 8:59 AM, Andre Klapper wrote:

Hej,

I went ahead & centralized the 5 git/Gerrit/git-review troubleshooting
sections that I've found so far on random mediawiki.org pages into one
single page (and eliminated duplicates with different solutions):
  
https://www.mediawiki.org/wiki/Gerrit/Troubleshooting




Knee-jerk ahead:

Although technically correct, some of those instructions encourage users 
to use 'git pull.'  Git doc writers, please join me in my crusade to 
stop gerrit users from ever, ever using 'git pull.' There's no end to 
the heartbreak that can result from pulling. Pulling merges, and merging 
is gerrit's job.


https://wikitech.wikimedia.org/wiki/Help:Git_rebase



Thanks for your help.
Thank you for compiling these docs!  I will think about how to politely 
introduce the above screed into your new page :)


-A



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