[Wikitech-l] Status of collation config updates?

[Bartosz Dziewoński]

Hi,

There are currently three pending patches to change category collation  
configuration for various Wikimedia wikis:


https://gerrit.wikimedia.org/r/140580
https://gerrit.wikimedia.org/r/147922
https://gerrit.wikimedia.org/r/154213

(This generally makes it so that accented letters like 'é' or 'ą' are not  
sorted at the end of lists, after 'z', and fixed ordering for languages  
with interesting alphabets; see  
https://www.mediawiki.org/wiki/Manual:$wgCategoryCollation.)


I have previously been told that these are on hold because of WMF's Trusty  
migration and the need to rebuild all existing collation data. (No one  
told me how long that might take, but by my estimates that can't possibly  
take more than two or three weeks, and I know for a fact that it can be  
done with no downtime and minimal problems.)


That was about two months ago.

Is anything known about the current status of the collation things, and  
the Trusty migration in general? Is there any public venue that I could  
follow to know what is going on, or at least a private one I could be cc'd  
on if I asked pretty-please? Is there any ETA, even vague, as to when  
things might get done?


I would like to update the bugs that are stuck with this information.

--
Matma Rex

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

[Wikitech-l] Deployment targets and preferences (was: Superprotect user right, Comming to a wiki near you)

[Seb35]

Hi,

I propose some constructive ideas to improve the deployment of new features:

* granular deployments: create "user profiles" where the users can choose
  if they want an overall appearance:
  * "never ever change my interface": some experienced authors do not like
 when one change every month their workflow if they are happy with it,
  * "experienced editor": some experienced editors want new features or see
 what the newbies see,
  * "newbie": the newbies/editors-to-be could expect an editing environment
 possibly different than the reader environment,
  * "reader": the readers have their own expectations for easy reading,
  * etc.
  The features could be deployed only for some groups, giving more flexibility
  to deploy "reader features" for readers, etc. Obviously there are
  preferences, but the newbies have no experience about it, and the
  experienced editors have to be discover new preferences on a case-by-case
  basis, making it difficult to everybody to track the preferences.

* implement global preferences (and the possibility to change locally or
  globally, like in Mailman) [bug 14950][]

* when a new feature is introduced, propose to users (not in "never ever
  change my interface") if they want the new feature, locally or globally,
  possibly using the Notifications bar, or with some message in the prefs
  page and highlighting it on the prefs page

* work on a better organisation of the preferences, e.g. add an exhaustive
  preference panel similarly to Firefox’s about:config to permit the
  developers to add more preferences and hence offering more customisation
  possibilities for advanced users, by nullifying the argument "the
  preferences page is too complicated for new users"

* as it was proposed, add a review process for the gadgets+JS pages to avoid
  performance, security, usability issues, possibly with the help of the tech
  staff, and possibly with the general MediaWiki code review
  (gerrit/Phabricator) with some gateway between it and the MediaWiki
  websites [bug 69445][] [bug 20153][]


In other words, improve the deployment targets and give easy choices to users
to opt-in/opt-out/etc the new features depending on their willingness to
change their environment.

And although I’m neither a loudly people neither the community, I vote to
remove the superprotect right and any other enforcement of this type in the
future. It’s like an edit war where one party has the power to silence the
other, and like all edit wars there are at least two wrong versions.


[bug 69445]: https://bugzilla.wikimedia.org/show_bug.cgi?id=69445
[bug 14950]: https://bugzilla.wikimedia.org/show_bug.cgi?id=14950
[bug 20153]: https://bugzilla.wikimedia.org/show_bug.cgi?id=20153

~ Seb35

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

Re: [Wikitech-l] Bikeshedding a good name for "the api.php API"

[Brad Jorsch (Anomie)]

Summing up, it seems like "action API" and "api.php" are the two contenders.

"api.php" is least likely to be confused with anything (only its own entry
point file). But as a name it's somewhat awkward.

"action API" might be confused with the Action class and its subclasses,
although that doesn't seem like a big deal.


As for the rest:

Just "API" is already causing confusion. Although it'll certainly continue
to be used in many contexts.

"MediaWiki API", "Web API", and "MediaWiki web API" are liable to be
confused with the proposed REST API, which is also supposed to be
web-accessible and will theoretically part of MediaWiki (even though I'd
guess it's probably going to be implemented as an -oid). "MediaWiki web
APIs" may well grow to encompass the api.php action API, the REST API, and
maybe even stuff like Parsoid.

"MediaWiki API" and "Core API" are liable to be confused with the various
hooks and PHP classes used by extensions.

"JSON API" wouldn't be accurate for well into the future, and would likely
be confused with other JSON-returning APIs such as Parsoid and maybe REST.

"Classic API" makes it sound like there's a full replacement.

All the code name suggestions would be making things less clear, not more.
If it had started out with a code name there would be historical inertia,
but using a code name now would just be silly.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] PHP 5.3 EOL and MediaWiki 1.24

[Tyler Romeo]

Ah, I was not aware WMF has still on 5.3. I guess we’ll revisit this in a few 
months or something then.
-- 
Tyler Romeo
0x405D34A7C86B42DF

From: Brad Jorsch (Anomie) 
Reply: Wikimedia developers >
Date: August 14, 2014 at 15:13:03
To: Wikimedia developers >
Subject:  Re: [Wikitech-l] PHP 5.3 EOL and MediaWiki 1.24  

This.

At the least, any change to the supported version of PHP isn't going to
happen until the WMF cluster gets updated, and the decision must be
informed by what version the WMF cluster gets updated to (which may be HHVM
rather than Zend).

signature.asc
Description: Message signed with OpenPGP using AMPGpg
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] PHP 5.3 EOL and MediaWiki 1.24

[Brad Jorsch (Anomie)]

On Thu, Aug 14, 2014 at 3:06 PM, Brian Wolff  wrote:

> Additionally, looking at Special:Version on 'pedia:
>
> PHP 5.3.10-1ubuntu3.10+wmf1 (apache2handler)
>
> I know that's going to change very soon, but until it does, this
> conversation seems like a non-starter.
>

This.

At the least, any change to the supported version of PHP isn't going to
happen until the WMF cluster gets updated, and the decision must be
informed by what version the WMF cluster gets updated to (which may be HHVM
rather than Zend).


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

Re: [Wikitech-l] PHP 5.3 EOL and MediaWiki 1.24

[Brian Wolff]

On 8/14/14, Tyler Romeo  wrote:
> Hi everybody,
>
> So we had a discussion about this a while ago, but just recently PHP let
> out the final 5.3 release. [0] Back in the previous thread concerning PHP
> 5.3, there seemed to be general agreement toward upping our PHP minimum
> requirements for the 1.24 release of MediaWiki.
>
> Here are the stats:
> * Soon Ubuntu (trusty) and Debian (jessie) releases will be running PHP 5.5
> and 5.6, respectively.
> * MediaWiki 1.23 ends support in May 2017
> * PHP 5.4 is estimated to be supported until 2015
> * Ubuntu 12.04 LTS (PHP 5.3) ends support on April 26, 2017
> * Debian Squeeze (PHP 5.3) ends support in February 2016
> * Debian Wheezy (PHP 5.4) *might* be supported until May 2018, depending on
> the feedback received from the Squeeze LTS trial
>

These aren't the sort of stats I think we should base the decision on.
Instead we should look at what most popular hosts support (Which will
probably be correlated with what is written above). Although I don't
know if those stats are easily available.

Additionally, looking at Special:Version on 'pedia:

PHP 5.3.10-1ubuntu3.10+wmf1 (apache2handler)

I know that's going to change very soon, but until it does, this
conversation seems like a non-starter.


>1) Raise to PHP 5.5 for MW 1.24
>2) Raise to PHP 5.4 for MW 1.24, and then when a release with support past
2018 is made, go to 5.5.

imo, deciding what min version to require should be based on a
combination of: use cases for features in the new version that we want
to use, maintenance burden of supporting old versions, and the amount
of inconvenience caused to re-users by the version requirement change.
This seems more like requiring a new version of php simply because its
new.

--bawolff

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

[Wikitech-l] PHP 5.3 EOL and MediaWiki 1.24

[Tyler Romeo]

Hi everybody,

So we had a discussion about this a while ago, but just recently PHP let
out the final 5.3 release. [0] Back in the previous thread concerning PHP
5.3, there seemed to be general agreement toward upping our PHP minimum
requirements for the 1.24 release of MediaWiki.

Here are the stats:
* Soon Ubuntu (trusty) and Debian (jessie) releases will be running PHP 5.5
and 5.6, respectively.
* MediaWiki 1.23 ends support in May 2017
* PHP 5.4 is estimated to be supported until 2015
* Ubuntu 12.04 LTS (PHP 5.3) ends support on April 26, 2017
* Debian Squeeze (PHP 5.3) ends support in February 2016
* Debian Wheezy (PHP 5.4) *might* be supported until May 2018, depending on
the feedback received from the Squeeze LTS trial

The results of this timeline are that when MediaWiki 1.23 ends support,
most supported distros will be on PHP 5.5 or higher (yes, not 5.4, but 5.5).

With that in mind, I'd like to move to raise our PHP minimum version.
Unless there are people that disagree, it is no longer a question of
whether to raise it or not, but rather what we want to raise it to. I
believe we have a couple of options:

1) Raise to PHP 5.5 for MW 1.24
2) Raise to PHP 5.4 for MW 1.24, and then when a release with support past
2018 is made, go to 5.5.

Option 2 takes advantage of the possible gap in coverage we will face
should Debian Wheezy receive LTS support.

Thoughts?

[0] http://php.net/archive/2014.php?050329#id2014-08-14-1

*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] tomorrow: RfC/Wikimania catchup meeting

[Quim Gil]

On Thu, Aug 14, 2014 at 1:13 PM, Brion Vibber  wrote:

>
>> Brion reported that there's discussion of how to expand the committee and
>> delegate from it, but nothing's finalized yet.
>>
>
> We'll follow up on this once Tim and I are back from the UK and on regular
> schedules. I think we can get out of the "cabal of 3" situation and get
> more folks involved and this should help keep things active and fresh!
>

Related task:

Start the process of expanding the arch committee
http://fab.wmflabs.org/T525

-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] tomorrow: RfC/Wikimania catchup meeting

[Brion Vibber]

On Thursday, August 14, 2014, Sumana Harihareswara 
wrote:

> Summary and logs now up:
> https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-08-13#Summary_and_logs
>
> Andrew Russell Green is the new CentralNotice Caching Overhaul - Frontend
> Proxy point person. Most of the rest of the TODOs remain the same. Yuri
> Astrakhan is checking with analytics to follow up on the image quality
> reduction.
>
> Today's was the last RfC meeting coordinated by me. Going forward, per the
> process at https://www.mediawiki.org/wiki/Architecture_meetings , the
> architecture committee will be setting these up and announcing them.
>

Thanks again for running these -- We've got a pretty good idea how to go
about them in future now that you've established a pattern!


> Brion reported that there's discussion of how to expand the committee and
> delegate from it, but nothing's finalized yet.
>

We'll follow up on this once Tim and I are back from the UK and on regular
schedules. I think we can get out of the "cabal of 3" situation and get
more folks involved and this should help keep things active and fresh!

-- brion


> Sumana Harihareswara
> Senior Technical Writer
> Wikimedia Foundation
>
>
> On Tue, Aug 12, 2014 at 11:14 PM, Sumana Harihareswara <
> suma...@wikimedia.org
> > wrote:
>
>> Open questions I suggest we try to answer tomorrow:
>>
>>1. Who is now the point person for *CentralNotice Caching Overhaul -
>>Frontend Proxy
>>
>> ?*
>>2. Followup from 23 July
>>
>> :
>>have we done security update planning on Composer managed libraries
>>for use on WMF cluster
>>
>> 
>>?
>>3. Followup from 21 May
>>
>> :
>>have we run the requested stats on Square bounding boxes
>>
>> 
>>?
>>4. Followup from 16 July
>>
>> :
>>do we know the next steps regarding CSSJanus on vertical writing
>>support
>>
>> 
>>?
>>5. Followup from 11 June
>>
>> :
>>how has the bandwidth savings been on Reducing image quality for
>>mobile
>>
>> ?
>>Will we change regular/original images as well as thumbnails?
>>
>>
>>
>> Sumana Harihareswara
>> Senior Technical Writer
>> Wikimedia Foundation
>>
>>
>> On Tue, Aug 12, 2014 at 5:51 PM, Sumana Harihareswara <
>> suma...@wikimedia.org
>> > wrote:
>>
>>> Tomorrow at 2100 UTC
>>> http://www.timeanddate.com/worldclock/fixedtime.html?hour=21&min=00&sec=0&day=13&month=08&year=2014
>>> , we're having an RfC/architecture meeting in #wikimedia-office on Freenode
>>> IRC
>>> https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-08-13
>>> . We'll talk about things discussed/made at Wikimania, and about some
>>> lingering next steps from previous RfC meetings.
>>>
>>> Going forward, per the process at
>>> https://www.mediawiki.org/wiki/Architecture_meetings , the architecture
>>> committee will be setting these up and announcing them.
>>>
>>> (haven't put up calendar entries/links everywhere yet about this
>>> meeting, will do later today)
>>>
>>> Sumana Harihareswara
>>> Senior Technical Writer
>>> Wikimedia Foundation
>>>
>>
>>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wikimedia-l] Superprotect user right, Comming to a wiki near you

[Pine W]

FYI, Lila had chosen to engage in discussion on her meta talk page.
Numerous editors are commenting there. Discussion also continues on the
meta RFC and on the English Wikipedia arbitration workshop page.

Pine
On Aug 14, 2014 12:03 AM, "Russavia"  wrote:

Erik

On Thu, Aug 14, 2014 at 5:32 AM, Erik Moeller  wrote:

>
> This is why on all major sites, you see a gradual ramp-up of a new
> feature, and continued improvement once it's widely used. Often
> there's an opt-in and then an opt-out to ease users into the change.
> But once a change is launched, it very rarely gets rolled back unless
> it's just clearly not doing what it's supposed to.


Are you are familiar with the Flickr experience in the last 12 months by
any chance? I think that is a very pertinent and prominent example of what
goes against what you say. The Flickr attitude was much the same as the
WMF's. That ended up in a revolt, much like the WMF is seeing against it.
In the end, they ended up doing what Erik?

Also, the other day I received a Flickr email from someone wishing to use
an image which I had not taken, but which I had uploaded to Commons. They
mentioned that they saw the photo on Commons.

When I told them that I am not the author, and that they would need to
contact Joe Bloggs, their response: "I'm sorry, this is SO confusing to me."

I put that down to MediaViewer and its adding irrelevant information, and
also the fact that file information is more difficult to find.

Russavia
___
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