[Wikitech-l] Prefix search refactoring

[Stas Malyshev]

Hi!

In order to make prefix search better, and to bring all variants of
prefix search under one roof, we did some refactoring in the search
engine implementation, so that various prefix searches now use the same
code path and all use the SearchEngine class.

The changes are as follows:

SearchEngine gets the following new API functions:

* public function completionSearch( $search ) - implements prefix
completion search, returns SearchSuggestionSet
* public function completionSearchWithVariants( $search ) - implements
prefix completion search including variants handling, returns
SearchSuggestionSet.
* public function defaultPrefixSearch( $search ) - basic prefix search
without fuzzy matching, etc., to be used in scenarios like special pages
search, etc. Returns Title[].

The implementation does not have to implement all three methods
differently, they can all use the same code if needed.

The default implementation still supports the PrefixSearchBackend hook
but we plan to deprecate it, and the CirrusSearch implementation does
not use it anymore. Instead, there is a private function, protected
function completionSearchBackend( $search ), which implementations
(including CirrusSearch) should implement to provide search results.

SearchEngine implementations can make use of services provided by the
base SearchEngine including:

- namespace resolution and normalization. The
PrefixSearchExtractNamespace hook is still supported for engines wishing
to implement namespace lookup not featured in the standard implementation.
- fetching titles for result sets (the implementing engine does not have
to fetch titles from DB for suggestions)
- result reordering to ensure exact matches are on top
- basic prefix search implementation using the database
- Special: namespace search implementation

== Deprecations ==
We plan to deprecate the PrefixSearchBackend hook and classes
TitlePrefixSearch and StringPrefixSearch. We will keep those classes
around for basic search fallback implementation and for old extensions,
but no new code should be using these classes, instead they should use
SearchEngine APIs described above. Mediawiki code has already been fixed
to do that. Extensions implementing search engines should also extend
SearchEngine and override the APIs above. CirrusSearch is the example of
how to do it.

== Show me the code ==
The patches implementing the refactoring are linked from:
https://phabricator.wikimedia.org/T121430

Pretty version of the same:
https://www.mediawiki.org/wiki/User:Smalyshev_(WMF)/Suggester

If you have questions on this, please contact the Discovery team:
https://www.mediawiki.org/wiki/Wikimedia_Discovery#Communications
-- 
Stas Malyshev
smalys...@wikimedia.org

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

Re: [Wikitech-l] Looking for information about LUA loading/parsing

[Brad Jorsch (Anomie)]

On Fri, Feb 12, 2016 at 6:07 AM, Strainu  wrote:

> There are obviously some optimizations there and I would be curious
> what they are? Do you use some CoW or other trick to prevent loading
> that table 100 times?


Regarding memory usage, much of the actual data generated during an #invoke
is no longer referenced afterward and can be garbage collected, so the peak
memory usage won't necessarily increase.

Regarding loading, Lua has a two-step process for loading a package: the
searcher returns a loader function, then the loader function returns the
actual package table. Scribunto's searcher caches the loader functions
inside Lua across #invokes, which can speed up subsequent loads. For
modules loaded from the wiki, the PHP code that fetches the text of the
module page also caches that text across #invokes.

If your table is static data, you can go one better by using mw.loadData()
to load it. This caches the actual data table inside Lua across #invokes.


> Do you have the loading/parsing process documented somewhere?
>

The standard Lua package module is documented at
http://www.lua.org/manual/5.1/manual.html#5.3

mw.loadData() is documented from an end-user standpoint at
https://www.mediawiki.org/wiki/Extension:Scribunto/Lua_reference_manual#mw.loadData

If you want to look at the actual code, the package module is implemented
in engines/LuaCommon/lualib/package.lua, the searcher is near the top of
engines/LuaCommon/lualib/mw.lua (look in makePackageModule()), the PHP code
behind the searcher starts in engines/LuaCommon/LuaCommon.php
(Scribunto_LuaEngine::loadPackage()), and mw.loadData is near the end of
engines/LuaCommon/lualib/mw.lua.

-- 
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] Developer Relations Weekly Summary

[Quim Gil]

Developer Relations focus this week:

* 2017 Wikimedia Hackathon: Looking for Proposals.[0]
* Review Wikimedia Hackathon 2016 [1] travel sponsorship requests.
* Wikimedia applications for Google Summer of Code 2016 [2] and Outreachy
Round 12.[3]
* Now Developer Relations is a subteam of Technical Collaboration,[4] see
our quarterly goals,[5] annual plan [6] (WIP), strategy [7] (WIP), and
planning process.[8]

There is plenty more at
https://www.mediawiki.org/wiki/Developer_Relations/Weekly_summary#2016-02-12

[0]
http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/85651
[1] https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2016
[2] https://www.mediawiki.org/wiki/Google_Summer_of_Code_2016
[3] https://www.mediawiki.org/wiki/Outreachy/Round_12
[4] https://meta.wikimedia.org/wiki/Technical_Collaboration
[5] https://meta.wikimedia.org/wiki/Technical_Collaboration/Goals
[6] https://phabricator.wikimedia.org/T124420
[7] https://meta.wikimedia.org/wiki/Technical_Collaboration/Strategy
[8] https://www.mediawiki.org/wiki/Developer_Relations/Planning

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

[Wikitech-l] Looking for information about LUA loading/parsing

[Strainu]

Hi,

I plan to try and use a big (~67K entries) table as a "database" in a
LUA script, with a basic lookup function. One call of the module would
be well within the time and memory limits, but I'm worried for pages
that might invoke the module several hundred times, so I did an
experiment with only a single entry in the table and the results are
encouraging:

1 call:
Lua time usage0.006/10.000 seconds
Lua memory usage513 KB/50 MB

10 calls:
Lua time usage0.010/10.000 seconds
Lua memory usage873 KB/50 MB

100 calls:
Lua time usage0.074/10.000 seconds
Lua memory usage1,35 MB/50 MB

There are obviously some optimizations there and I would be curious
what they are? Do you use some CoW or other trick to prevent loading
that table 100 times? Do you have the loading/parsing process
documented somewhere?

Thanks,
  Strainu

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

Re: [Wikitech-l] Mass migration to new syntax - PRO or CON?

[Chad]

On Fri, Feb 12, 2016 at 7:27 AM Daniel Kinzler  wrote:

> CON: don't do mass migration to new syntax, only start using new styles and
> features when touching the respective bit of code anyway. The argument is
> here
> that touching many lines of code, even if it's just for whitespace changes,
> causes merge conflicts when doing backports and when rebasing patches.
> E.g. if
> we touch half the files in the codebase to change to the new array syntax,
> who
> is going to manually rebase the couple of hundred patches we have open?
>
>
> As can be seen on the proposed patch I linked, several of the long term
> developers oppose mass changes like this. A quick round of feedback in the
> architecture committee draws a similar picture. However, perhaps there are
> compelling arguments for doing the mass migration that we haven't heard
> yet. So
> please give a quick PRO or CON, optionally with some rationale.
>
> My personal vote is CON. No rebase hell please! Changing to the syntax
> doesn't
> buy us anything.
>
>
CON, for all the reasons you mentioned. Also: style only changes are pain
when you're
trying to annotate/blame a particular line of code.

ESPECIALLY for something so silly as array formatting which gains us
*absolutely nothing*

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

Re: [Wikitech-l] Mass migration to new syntax - PRO or CON?

[Jon Robson]

On Fri, Feb 12, 2016 at 9:14 AM, Chad  wrote:

> On Fri, Feb 12, 2016 at 7:27 AM Daniel Kinzler 
> wrote:
>
> > CON: don't do mass migration to new syntax, only start using new styles
> and
> > features when touching the respective bit of code anyway. The argument is
> > here
> > that touching many lines of code, even if it's just for whitespace
> changes,
> > causes merge conflicts when doing backports and when rebasing patches.
> > E.g. if
> > we touch half the files in the codebase to change to the new array
> syntax,
> > who
> > is going to manually rebase the couple of hundred patches we have open?
> >
> >
> > As can be seen on the proposed patch I linked, several of the long term
> > developers oppose mass changes like this. A quick round of feedback in
> the
> > architecture committee draws a similar picture. However, perhaps there
> are
> > compelling arguments for doing the mass migration that we haven't heard
> > yet. So
> > please give a quick PRO or CON, optionally with some rationale.
> >
> > My personal vote is CON. No rebase hell please! Changing to the syntax
> > doesn't
> > buy us anything.
> >
> >
> CON, for all the reasons you mentioned. Also: style only changes are pain
> when you're
> trying to annotate/blame a particular line of code.
>
> ESPECIALLY for something so silly as array formatting which gains us
> *absolutely nothing*
>

Agree on many levels.
Please, let's focus on solving problems and improving how our code works
rather than how our code looks.

>
> -Chad
> ___
> 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] Mass migration to new syntax - PRO or CON?

[Marius Hoch]

I also think we shouldn't mass migrate.

New code should use the new syntax and old code can be converted during 
larger refactors or similar things (when it is being touched anyway), 
but we shouldn't have "update syntax" only patches.


Cheers,

Marius

On 12.02.2016 16:27, Daniel Kinzler wrote:

Now that we target PHP 5.5, some people are itching to make use of some new
language features, like the new array syntax, e.g.
.

Mass changes like this, or similar changes relating to coding style, tend to
lead to controversy. I want to make sure we have a discussion about this here,
to avoid having the argument over and over on any such patch.

Please give a quick PRO or CON response as a basis for discussion.

In essence, the discussion boils down to two conflicting positions:

PRO: do mass migration to the new syntax, style, or whatever, as soon as
possible. This way, the codebase is in a consistent form, and that form is the
one we agreed is the best for readability. Doing changes like this is
gratifying, because it's low hanging fruit: it's easy to do, and has large
visible impact (well ok, visible in the source).

CON: don't do mass migration to new syntax, only start using new styles and
features when touching the respective bit of code anyway. The argument is here
that touching many lines of code, even if it's just for whitespace changes,
causes merge conflicts when doing backports and when rebasing patches. E.g. if
we touch half the files in the codebase to change to the new array syntax, who
is going to manually rebase the couple of hundred patches we have open?


As can be seen on the proposed patch I linked, several of the long term
developers oppose mass changes like this. A quick round of feedback in the
architecture committee draws a similar picture. However, perhaps there are
compelling arguments for doing the mass migration that we haven't heard yet. So
please give a quick PRO or CON, optionally with some rationale.

My personal vote is CON. No rebase hell please! Changing to the syntax doesn't
buy us anything.

-- daniel

___
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] Mass migration to new syntax - PRO or CON?

[Daniel Kinzler]

Now that we target PHP 5.5, some people are itching to make use of some new
language features, like the new array syntax, e.g.
.

Mass changes like this, or similar changes relating to coding style, tend to
lead to controversy. I want to make sure we have a discussion about this here,
to avoid having the argument over and over on any such patch.

Please give a quick PRO or CON response as a basis for discussion.

In essence, the discussion boils down to two conflicting positions:

PRO: do mass migration to the new syntax, style, or whatever, as soon as
possible. This way, the codebase is in a consistent form, and that form is the
one we agreed is the best for readability. Doing changes like this is
gratifying, because it's low hanging fruit: it's easy to do, and has large
visible impact (well ok, visible in the source).

CON: don't do mass migration to new syntax, only start using new styles and
features when touching the respective bit of code anyway. The argument is here
that touching many lines of code, even if it's just for whitespace changes,
causes merge conflicts when doing backports and when rebasing patches. E.g. if
we touch half the files in the codebase to change to the new array syntax, who
is going to manually rebase the couple of hundred patches we have open?


As can be seen on the proposed patch I linked, several of the long term
developers oppose mass changes like this. A quick round of feedback in the
architecture committee draws a similar picture. However, perhaps there are
compelling arguments for doing the mass migration that we haven't heard yet. So
please give a quick PRO or CON, optionally with some rationale.

My personal vote is CON. No rebase hell please! Changing to the syntax doesn't
buy us anything.

-- daniel

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

Re: [Wikitech-l] Mass migration to new syntax - PRO or CON?

[Toby Negrin]

First, a thank you for Daniel for writing such a balanced, informative
email on a somewhat contentious subject!

As someone who will probably never touch a line of MW code, I'm not going
to actually vote. But I do have experience in large, complex codebases and
I'm going to argue for PRO.

We need to acknowledge that our codebase is going to change over time and
if we aren't explicit and accepting of this reality, we're not going to be
able to manage it well. Consider future developers who may only ever know
new syntax and their desire and ability to work on a codebase that doesn't
reflect new techniques and syntax in its implementation.

-Toby

On Fri, Feb 12, 2016 at 9:44 AM, Purodha Blissenbach <
puro...@blissenbach.org> wrote:

> CON, for all the reasons mentioned.
>
> Purodha
>
>
>
> ___
> 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] Mass migration to new syntax - PRO or CON?

[Ori Livneh]

On Fri, Feb 12, 2016 at 7:27 AM, Daniel Kinzler 
wrote:

> Now that we target PHP 5.5, some people are itching to make use of some new
> language features, like the new array syntax, e.g.
> .
>
> Mass changes like this, or similar changes relating to coding style, tend
> to
> lead to controversy. I want to make sure we have a discussion about this
> here,
> to avoid having the argument over and over on any such patch.
>
> Please give a quick PRO or CON response as a basis for discussion.
>

PRO. These syntax changes were implemented in PHP at the cost of breaking
backward-compatibility, which tells you that people understood their value
and were willing to pay a cost for modernizing and simplifying the
language. If PHP was willing to pay it, why wouldn't we?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Mass migration to new syntax - PRO or CON?

[Stas Malyshev]

Hi!

> Please give a quick PRO or CON response as a basis for discussion.

My opinion: if it ain't broke, don't fix it. It's ok to use new syntax
in new code, but spending time on changing perfectly working code just
to use new array syntax looks like misplaced effort to me.

There are new features that I would have more support immediate change,
like $this in closures - that makes code much more readable and less
bug-prone. Even then, I'm ambivalent whether we need to touch the code
that much, but I see a point of cleaning it up. But with array syntax,
it's just a different syntax, and I don't see a lot of reason to mess
with existing working code just to use it.
-- 
Stas Malyshev
smalys...@wikimedia.org

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

Re: [Wikitech-l] Mass migration to new syntax - PRO or CON?

[Stas Malyshev]

Hi!

> PRO. These syntax changes were implemented in PHP at the cost of breaking
> backward-compatibility, which tells you that people understood their value

Wait, are we talking about the same thing? New array syntax does not
break BC. Or you mean that if we use new array syntax, we'd break BC
with older PHP versions? I'm not sure I understand your argument here.

-- 
Stas Malyshev
smalys...@wikimedia.org

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

Re: [Wikitech-l] Mass migration to new syntax - PRO or CON?

[Purodha Blissenbach]

CON, for all the reasons mentioned.

Purodha


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

Re: [Wikitech-l] Wikitech maintenance and CI downtime tomorrow, 2015-02-12 16:00 UTC

[Andrew Bogott]

Update:

This migration is complete.  There are a bunch of bugs with labs 
features in wikitech which I'm now hunting down one by one.  In the 
meantime, CI should be working again, and most common wikitech actions 
should mostly work.


I'll send another 'all clear' once I've stamped out some of the more 
obvious bugs.  In the meantime maybe hold off on filing phab tickets 
since most likely we already know :)


-Andrew


On 2/11/16 9:54 AM, Andrew Bogott wrote:

Executive summary:

CI tests won't run for a while tomorrow.  Also you won't be able 
to log into Wikitech.  This will begin at 16:00 UTC (8:00 AM in 
California) and may take a couple of hours.


Full story:

As part of a long-overdue tech-debt payment[0], I'll be migrating 
all of the Labs project, membership and role data from ldap into 
mysql[1].  Keystone (the Labs Openstack authentication layer) will be 
shut off briefly, and subsequently will have incomplete data while 
things are gradually copied over from Ldap.
At the same time, Alex will be rolling out a bunch of 
OpenStackManager patches[2] to cope with the new reality.  I've tested 
these quite a lot, but no doubt there will be unexpected issues with 
such a big refactor.


Existing, running labs and tools sessions should not be affected.  
New instance creation will be disabled for part of the window, which 
will prevent CI from starting new tests.  Wikitech login will be 
disabled, and users will have to login afresh after logins are restored.


There is, unfortunately, no user-facing improvement associated 
with this update.  If all goes perfectly, Wikitech will be restored to 
its original state but be slightly slower.  If, after the update, 
anyone encounters new Wikitech issues (and I emphasize the NEW), 
please open a phab ticket and inform me immediately.


As always, in the worst case scenario you can refer to our doc 
site of last resort, https://wikitech-static.wikimedia.org



-Andrew


[0] https://phabricator.wikimedia.org/T115029
[1] https://wikitech.wikimedia.org/wiki/Labs_keystone_roles
[2] The patchset begins with https://gerrit.wikimedia.org/r/#/c/252615/



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

Re: [Wikitech-l] Mass migration to new syntax - PRO or CON?

[Alex Monk]

PRO from me, for all the reasons mentioned by legoktm

On 12 February 2016 at 19:26, Legoktm  wrote:

> Hi,
>
> On 02/12/2016 07:27 AM, Daniel Kinzler wrote:
> > Now that we target PHP 5.5, some people are itching to make use of some
> new
> > language features, like the new array syntax, e.g.
> > .
> >
> > Mass changes like this, or similar changes relating to coding style,
> tend to
> > lead to controversy. I want to make sure we have a discussion about this
> here,
> > to avoid having the argument over and over on any such patch.
> >
> > Please give a quick PRO or CON response as a basis for discussion.
> >
> > In essence, the discussion boils down to two conflicting positions:
> >
> > PRO: do mass migration to the new syntax, style, or whatever, as soon as
> > possible. This way, the codebase is in a consistent form, and that form
> is the
> > one we agreed is the best for readability. Doing changes like this is
> > gratifying, because it's low hanging fruit: it's easy to do, and has
> large
> > visible impact (well ok, visible in the source).
>
> I'll offer an alternative, which is to convert all of them at once using
> PHPCS and then enforce that all new patches use [] arrays. You then only
> have one commit which changes everything, not hundreds you have to go
> through while git blaming or looking in git log.
>
> > CON: don't do mass migration to new syntax, only start using new styles
> and
> > features when touching the respective bit of code anyway. The argument
> is here
> > that touching many lines of code, even if it's just for whitespace
> changes,
> > causes merge conflicts when doing backports and when rebasing patches.
> E.g. if
> > we touch half the files in the codebase to change to the new array
> syntax, who
> > is going to manually rebase the couple of hundred patches we have open?
>
> There's no need to do it manually. Just tell people to run the phpcs
> autofixer before they rebase, and the result should be identical to
> what's already there. And we can have PHPCS run in the other direction
> for backports ([] -> array()).
>
> But if we don't do that, people are going to start converting things
> manually whenever they work on the code, and you'll still end up with
> hundreds of open patches needing rebase, except it can't be done
> automatically anymore.
>
> > My personal vote is CON. No rebase hell please! Changing to the syntax
> doesn't
> > buy us anything.
>
> Consistency buys us a lot. New developers won't be confused on whether
> to use [] or array(). It makes entry easier for people coming from other
> languages where [] is used for lists.
>
> I think you're going to end up in rebase hell regardless, so we should
> rip off the bandaid quickly and get it over with, and use the automated
> tools we have to our advantage.
>
> So, if we're voting, I'm PRO.
>
> -- Legoktm
>
> ___
> 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] Mass migration to new syntax - PRO or CON?

[Jon Robson]

On Fri, Feb 12, 2016 at 10:26 AM, Stas Malyshev 
wrote:

> Hi!
>
> > PRO. These syntax changes were implemented in PHP at the cost of breaking
> > backward-compatibility, which tells you that people understood their
> value
>
> Wait, are we talking about the same thing? New array syntax does not
> break BC. Or you mean that if we use new array syntax, we'd break BC
> with older PHP versions? I'm not sure I understand your argument here.
>

I'm also a little puzzled. I thought it was a given we are embracing and
modernizing newer PHP versions.

The question as I understood it, is should we touch every piece of our
codebase in one big mega patch or update it gradually as and when we visit
bits of the codebase (I get the impression the latter isn't happening due
to a desire to have mega patches).


>
> --
> Stas Malyshev
> smalys...@wikimedia.org
>
> ___
> 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] Mass migration to new syntax - PRO or CON?

[Stas Malyshev]

Hi!

> The question as I understood it, is should we touch every piece of our
> codebase in one big mega patch or update it gradually as and when we visit
> bits of the codebase (I get the impression the latter isn't happening due
> to a desire to have mega patches).

Same here and just to be clear, I'm for the gradual approach.

-- 
Stas Malyshev
smalys...@wikimedia.org

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

Re: [Wikitech-l] Mass migration to new syntax - PRO or CON?

[Legoktm]

Hi,

On 02/12/2016 07:27 AM, Daniel Kinzler wrote:
> Now that we target PHP 5.5, some people are itching to make use of some new
> language features, like the new array syntax, e.g.
> .
> 
> Mass changes like this, or similar changes relating to coding style, tend to
> lead to controversy. I want to make sure we have a discussion about this here,
> to avoid having the argument over and over on any such patch.
> 
> Please give a quick PRO or CON response as a basis for discussion.
> 
> In essence, the discussion boils down to two conflicting positions:
> 
> PRO: do mass migration to the new syntax, style, or whatever, as soon as
> possible. This way, the codebase is in a consistent form, and that form is the
> one we agreed is the best for readability. Doing changes like this is
> gratifying, because it's low hanging fruit: it's easy to do, and has large
> visible impact (well ok, visible in the source).

I'll offer an alternative, which is to convert all of them at once using
PHPCS and then enforce that all new patches use [] arrays. You then only
have one commit which changes everything, not hundreds you have to go
through while git blaming or looking in git log.

> CON: don't do mass migration to new syntax, only start using new styles and
> features when touching the respective bit of code anyway. The argument is here
> that touching many lines of code, even if it's just for whitespace changes,
> causes merge conflicts when doing backports and when rebasing patches. E.g. if
> we touch half the files in the codebase to change to the new array syntax, who
> is going to manually rebase the couple of hundred patches we have open?

There's no need to do it manually. Just tell people to run the phpcs
autofixer before they rebase, and the result should be identical to
what's already there. And we can have PHPCS run in the other direction
for backports ([] -> array()).

But if we don't do that, people are going to start converting things
manually whenever they work on the code, and you'll still end up with
hundreds of open patches needing rebase, except it can't be done
automatically anymore.

> My personal vote is CON. No rebase hell please! Changing to the syntax doesn't
> buy us anything.

Consistency buys us a lot. New developers won't be confused on whether
to use [] or array(). It makes entry easier for people coming from other
languages where [] is used for lists.

I think you're going to end up in rebase hell regardless, so we should
rip off the bandaid quickly and get it over with, and use the automated
tools we have to our advantage.

So, if we're voting, I'm PRO.

-- Legoktm

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

Re: [Wikitech-l] Mass migration to new syntax - PRO or CON?

[Joaquin Oltra Hernandez]

PRO from me too.

Doing it gradually is just going to make the codebase inconsistent, and
tooling can help point patches to the old style to migrate to the new one.

I'd rather do it quickly than have the inconsistency bleed through months
or years.

On Fri, Feb 12, 2016 at 8:28 PM, Alex Monk  wrote:

> PRO from me, for all the reasons mentioned by legoktm
>
> On 12 February 2016 at 19:26, Legoktm  wrote:
>
> > Hi,
> >
> > On 02/12/2016 07:27 AM, Daniel Kinzler wrote:
> > > Now that we target PHP 5.5, some people are itching to make use of some
> > new
> > > language features, like the new array syntax, e.g.
> > > .
> > >
> > > Mass changes like this, or similar changes relating to coding style,
> > tend to
> > > lead to controversy. I want to make sure we have a discussion about
> this
> > here,
> > > to avoid having the argument over and over on any such patch.
> > >
> > > Please give a quick PRO or CON response as a basis for discussion.
> > >
> > > In essence, the discussion boils down to two conflicting positions:
> > >
> > > PRO: do mass migration to the new syntax, style, or whatever, as soon
> as
> > > possible. This way, the codebase is in a consistent form, and that form
> > is the
> > > one we agreed is the best for readability. Doing changes like this is
> > > gratifying, because it's low hanging fruit: it's easy to do, and has
> > large
> > > visible impact (well ok, visible in the source).
> >
> > I'll offer an alternative, which is to convert all of them at once using
> > PHPCS and then enforce that all new patches use [] arrays. You then only
> > have one commit which changes everything, not hundreds you have to go
> > through while git blaming or looking in git log.
> >
> > > CON: don't do mass migration to new syntax, only start using new styles
> > and
> > > features when touching the respective bit of code anyway. The argument
> > is here
> > > that touching many lines of code, even if it's just for whitespace
> > changes,
> > > causes merge conflicts when doing backports and when rebasing patches.
> > E.g. if
> > > we touch half the files in the codebase to change to the new array
> > syntax, who
> > > is going to manually rebase the couple of hundred patches we have open?
> >
> > There's no need to do it manually. Just tell people to run the phpcs
> > autofixer before they rebase, and the result should be identical to
> > what's already there. And we can have PHPCS run in the other direction
> > for backports ([] -> array()).
> >
> > But if we don't do that, people are going to start converting things
> > manually whenever they work on the code, and you'll still end up with
> > hundreds of open patches needing rebase, except it can't be done
> > automatically anymore.
> >
> > > My personal vote is CON. No rebase hell please! Changing to the syntax
> > doesn't
> > > buy us anything.
> >
> > Consistency buys us a lot. New developers won't be confused on whether
> > to use [] or array(). It makes entry easier for people coming from other
> > languages where [] is used for lists.
> >
> > I think you're going to end up in rebase hell regardless, so we should
> > rip off the bandaid quickly and get it over with, and use the automated
> > tools we have to our advantage.
> >
> > So, if we're voting, I'm PRO.
> >
> > -- Legoktm
> >
> > ___
> > 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

Re: [Wikitech-l] Mass migration to new syntax - PRO or CON?

[Tyler Romeo]

I think it's also pertinent to note that we are finally reaching a state where 
PHP-CS can be voting, which was only achieved after a lot of hard work to make 
our codebase consistent.

If we make these changes gradually, we're basically throwing away all of the 
work that was just done recently.

Regards,
-- 
Tyler Romeo
https://parent5446.nyc
0x405D34A7C86B42DF

From: Joaquin Oltra Hernandez 
Reply: Wikimedia developers 
Date: February 12, 2016 at 14:31:54
To: Wikimedia developers 
Subject:  Re: [Wikitech-l] Mass migration to new syntax - PRO or CON?  

PRO from me too.

Doing it gradually is just going to make the codebase inconsistent, and
tooling can help point patches to the old style to migrate to the new one.

I'd rather do it quickly than have the inconsistency bleed through months
or years.

On Fri, Feb 12, 2016 at 8:28 PM, Alex Monk  wrote:

> PRO from me, for all the reasons mentioned by legoktm
>
> On 12 February 2016 at 19:26, Legoktm  wrote:
>
> > Hi,
> >
> > On 02/12/2016 07:27 AM, Daniel Kinzler wrote:
> > > Now that we target PHP 5.5, some people are itching to make use of some
> > new
> > > language features, like the new array syntax, e.g.
> > > .
> > >
> > > Mass changes like this, or similar changes relating to coding style,
> > tend to
> > > lead to controversy. I want to make sure we have a discussion about
> this
> > here,
> > > to avoid having the argument over and over on any such patch.
> > >
> > > Please give a quick PRO or CON response as a basis for discussion.
> > >
> > > In essence, the discussion boils down to two conflicting positions:
> > >
> > > PRO: do mass migration to the new syntax, style, or whatever, as soon
> as
> > > possible. This way, the codebase is in a consistent form, and that form
> > is the
> > > one we agreed is the best for readability. Doing changes like this is
> > > gratifying, because it's low hanging fruit: it's easy to do, and has
> > large
> > > visible impact (well ok, visible in the source).
> >
> > I'll offer an alternative, which is to convert all of them at once using
> > PHPCS and then enforce that all new patches use [] arrays. You then only
> > have one commit which changes everything, not hundreds you have to go
> > through while git blaming or looking in git log.
> >
> > > CON: don't do mass migration to new syntax, only start using new styles
> > and
> > > features when touching the respective bit of code anyway. The argument
> > is here
> > > that touching many lines of code, even if it's just for whitespace
> > changes,
> > > causes merge conflicts when doing backports and when rebasing patches.
> > E.g. if
> > > we touch half the files in the codebase to change to the new array
> > syntax, who
> > > is going to manually rebase the couple of hundred patches we have open?
> >
> > There's no need to do it manually. Just tell people to run the phpcs
> > autofixer before they rebase, and the result should be identical to
> > what's already there. And we can have PHPCS run in the other direction
> > for backports ([] -> array()).
> >
> > But if we don't do that, people are going to start converting things
> > manually whenever they work on the code, and you'll still end up with
> > hundreds of open patches needing rebase, except it can't be done
> > automatically anymore.
> >
> > > My personal vote is CON. No rebase hell please! Changing to the syntax
> > doesn't
> > > buy us anything.
> >
> > Consistency buys us a lot. New developers won't be confused on whether
> > to use [] or array(). It makes entry easier for people coming from other
> > languages where [] is used for lists.
> >
> > I think you're going to end up in rebase hell regardless, so we should
> > rip off the bandaid quickly and get it over with, and use the automated
> > tools we have to our advantage.
> >
> > So, if we're voting, I'm PRO.
> >
> > -- Legoktm
> >
> > ___
> > 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

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] Mass migration to new syntax - PRO or CON?

[Max Semenik]

PRO: preserving the blame history is a false hope because we liberally move
files around, extract classes to separate files and so on. In other words,
we do the usual refactoring work and in process we break blame at all
times. Syntax updates are just another refactoring, nothing principally
new. And no, when hell freezes over are inconsistent code standards better:
we already have a code base inconsistent enough after 15 years of
development and MUST avoid creating more.

On Fri, Feb 12, 2016 at 11:28 AM, Alex Monk  wrote:

> PRO from me, for all the reasons mentioned by legoktm
>
> On 12 February 2016 at 19:26, Legoktm  wrote:
>
> > Hi,
> >
> > On 02/12/2016 07:27 AM, Daniel Kinzler wrote:
> > > Now that we target PHP 5.5, some people are itching to make use of some
> > new
> > > language features, like the new array syntax, e.g.
> > > .
> > >
> > > Mass changes like this, or similar changes relating to coding style,
> > tend to
> > > lead to controversy. I want to make sure we have a discussion about
> this
> > here,
> > > to avoid having the argument over and over on any such patch.
> > >
> > > Please give a quick PRO or CON response as a basis for discussion.
> > >
> > > In essence, the discussion boils down to two conflicting positions:
> > >
> > > PRO: do mass migration to the new syntax, style, or whatever, as soon
> as
> > > possible. This way, the codebase is in a consistent form, and that form
> > is the
> > > one we agreed is the best for readability. Doing changes like this is
> > > gratifying, because it's low hanging fruit: it's easy to do, and has
> > large
> > > visible impact (well ok, visible in the source).
> >
> > I'll offer an alternative, which is to convert all of them at once using
> > PHPCS and then enforce that all new patches use [] arrays. You then only
> > have one commit which changes everything, not hundreds you have to go
> > through while git blaming or looking in git log.
> >
> > > CON: don't do mass migration to new syntax, only start using new styles
> > and
> > > features when touching the respective bit of code anyway. The argument
> > is here
> > > that touching many lines of code, even if it's just for whitespace
> > changes,
> > > causes merge conflicts when doing backports and when rebasing patches.
> > E.g. if
> > > we touch half the files in the codebase to change to the new array
> > syntax, who
> > > is going to manually rebase the couple of hundred patches we have open?
> >
> > There's no need to do it manually. Just tell people to run the phpcs
> > autofixer before they rebase, and the result should be identical to
> > what's already there. And we can have PHPCS run in the other direction
> > for backports ([] -> array()).
> >
> > But if we don't do that, people are going to start converting things
> > manually whenever they work on the code, and you'll still end up with
> > hundreds of open patches needing rebase, except it can't be done
> > automatically anymore.
> >
> > > My personal vote is CON. No rebase hell please! Changing to the syntax
> > doesn't
> > > buy us anything.
> >
> > Consistency buys us a lot. New developers won't be confused on whether
> > to use [] or array(). It makes entry easier for people coming from other
> > languages where [] is used for lists.
> >
> > I think you're going to end up in rebase hell regardless, so we should
> > rip off the bandaid quickly and get it over with, and use the automated
> > tools we have to our advantage.
> >
> > So, if we're voting, I'm PRO.
> >
> > -- Legoktm
> >
> > ___
> > 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
>



-- 
Best regards,
Max Semenik ([[User:MaxSem]])
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Mass migration to new syntax - PRO or CON?

[Brad Jorsch (Anomie)]

On Fri, Feb 12, 2016 at 2:26 PM, Legoktm 
wrote:

> I think you're going to end up in rebase hell regardless, so we should
> rip off the bandaid quickly and get it over with, and use the automated
> tools we have to our advantage.
>

This. Just get it over with, and then it's only one patch screwing up
rebases and blames instead of lots.



-- 
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] Mass migration to new syntax - PRO or CON?

[Ricordisamoa]

Il 12/02/2016 20:26, Legoktm ha scritto:

Hi,

On 02/12/2016 07:27 AM, Daniel Kinzler wrote:

Now that we target PHP 5.5, some people are itching to make use of some new
language features, like the new array syntax, e.g.
.

Mass changes like this, or similar changes relating to coding style, tend to
lead to controversy. I want to make sure we have a discussion about this here,
to avoid having the argument over and over on any such patch.

Please give a quick PRO or CON response as a basis for discussion.

In essence, the discussion boils down to two conflicting positions:

PRO: do mass migration to the new syntax, style, or whatever, as soon as
possible. This way, the codebase is in a consistent form, and that form is the
one we agreed is the best for readability. Doing changes like this is
gratifying, because it's low hanging fruit: it's easy to do, and has large
visible impact (well ok, visible in the source).

I'll offer an alternative, which is to convert all of them at once using
PHPCS and then enforce that all new patches use [] arrays. You then only
have one commit which changes everything, not hundreds you have to go
through while git blaming or looking in git log.


CON: don't do mass migration to new syntax, only start using new styles and
features when touching the respective bit of code anyway. The argument is here
that touching many lines of code, even if it's just for whitespace changes,
causes merge conflicts when doing backports and when rebasing patches. E.g. if
we touch half the files in the codebase to change to the new array syntax, who
is going to manually rebase the couple of hundred patches we have open?

There's no need to do it manually. Just tell people to run the phpcs
autofixer before they rebase, and the result should be identical to
what's already there. And we can have PHPCS run in the other direction
for backports ([] -> array()).

But if we don't do that, people are going to start converting things
manually whenever they work on the code, and you'll still end up with
hundreds of open patches needing rebase, except it can't be done
automatically anymore.


My personal vote is CON. No rebase hell please! Changing to the syntax doesn't
buy us anything.

Consistency buys us a lot. New developers won't be confused on whether
to use [] or array(). It makes entry easier for people coming from other
languages where [] is used for lists.


Objection: other languages may use [] for lists, but array() is more 
similar to {} used for hash tables.




I think you're going to end up in rebase hell regardless, so we should
rip off the bandaid quickly and get it over with, and use the automated
tools we have to our advantage.

So, if we're voting, I'm PRO.

-- Legoktm

___
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] Wikitech maintenance and CI downtime tomorrow, 2015-02-12 16:00 UTC

[Andrew Bogott]

Alex and I have spent much of the day hunting down bugs, and the obvious 
ones are now fixed.  The only issue that I'm still seeing is that if 
you're a member of every single project, logins are very slow... 
fortunately I am probably the only user bit by this :)


So, now:  please open a phab task if you encounter bad behavior on 
wikitech, and assign it to me or direct my attention to it via email or IRC.


Many thanks to Alex Monk for all his code review, and thanks to everyone 
for your patience with the downtime.


-Andrew


On 2/12/16 12:11 PM, Andrew Bogott wrote:

Update:

This migration is complete.  There are a bunch of bugs with labs 
features in wikitech which I'm now hunting down one by one.  In the 
meantime, CI should be working again, and most common wikitech actions 
should mostly work.


I'll send another 'all clear' once I've stamped out some of the more 
obvious bugs.  In the meantime maybe hold off on filing phab tickets 
since most likely we already know :)


-Andrew


On 2/11/16 9:54 AM, Andrew Bogott wrote:

Executive summary:

CI tests won't run for a while tomorrow.  Also you won't be able 
to log into Wikitech.  This will begin at 16:00 UTC (8:00 AM in 
California) and may take a couple of hours.


Full story:

As part of a long-overdue tech-debt payment[0], I'll be migrating 
all of the Labs project, membership and role data from ldap into 
mysql[1].  Keystone (the Labs Openstack authentication layer) will be 
shut off briefly, and subsequently will have incomplete data while 
things are gradually copied over from Ldap.
At the same time, Alex will be rolling out a bunch of 
OpenStackManager patches[2] to cope with the new reality.  I've 
tested these quite a lot, but no doubt there will be unexpected 
issues with such a big refactor.


Existing, running labs and tools sessions should not be 
affected.  New instance creation will be disabled for part of the 
window, which will prevent CI from starting new tests. Wikitech login 
will be disabled, and users will have to login afresh after logins 
are restored.


There is, unfortunately, no user-facing improvement associated 
with this update.  If all goes perfectly, Wikitech will be restored 
to its original state but be slightly slower. If, after the update, 
anyone encounters new Wikitech issues (and I emphasize the NEW), 
please open a phab ticket and inform me immediately.


As always, in the worst case scenario you can refer to our doc 
site of last resort, https://wikitech-static.wikimedia.org



-Andrew


[0] https://phabricator.wikimedia.org/T115029
[1] https://wikitech.wikimedia.org/wiki/Labs_keystone_roles
[2] The patchset begins with https://gerrit.wikimedia.org/r/#/c/252615/





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

Re: [Wikitech-l] Mass migration to new syntax - PRO or CON?

[Gabriel Wicke]

Overall I'm PRO, as consistency is worth a lot, and tools can apply
such changes consistently and efficiently.

We have applied broad formatting changes to large JS codebases using
jscs, which has worked well when those changes were well prepared.
Typically, this involved gradually refining the tool settings until a
reasonable diff was achieved.

On Fri, Feb 12, 2016 at 12:44 PM, Chad  wrote:
> On Fri, Feb 12, 2016 at 9:14 AM Chad  wrote:
>
>> On Fri, Feb 12, 2016 at 7:27 AM Daniel Kinzler 
>> wrote:
>>
>>> CON: don't do mass migration to new syntax, only start using new styles
>>> and
>>> features when touching the respective bit of code anyway. The argument is
>>> here
>>> that touching many lines of code, even if it's just for whitespace
>>> changes,
>>> causes merge conflicts when doing backports and when rebasing patches.
>>> E.g. if
>>> we touch half the files in the codebase to change to the new array
>>> syntax, who
>>> is going to manually rebase the couple of hundred patches we have open?
>>>
>>>
>>> As can be seen on the proposed patch I linked, several of the long term
>>> developers oppose mass changes like this. A quick round of feedback in the
>>> architecture committee draws a similar picture. However, perhaps there are
>>> compelling arguments for doing the mass migration that we haven't heard
>>> yet. So
>>> please give a quick PRO or CON, optionally with some rationale.
>>>
>>> My personal vote is CON. No rebase hell please! Changing to the syntax
>>> doesn't
>>> buy us anything.
>>>
>>>
>> CON, for all the reasons you mentioned. Also: style only changes are pain
>> when you're
>> trying to annotate/blame a particular line of code.
>>
>> ESPECIALLY for something so silly as array formatting which gains us
>> *absolutely nothing*
>>
>> -Chad
>>
>
> I change my vote to PRO.
>
> Mainly because people are gonna do it anyway...
>
> Last thoughts on the thread, I got bigger fish to fry than array syntax
> sugar :D
>
> -Chad
> ___
> 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

Re: [Wikitech-l] Mass migration to new syntax - PRO or CON?

[Guillaume Lederrey]

I'm not going to touch much PHP code any time soon, so feel free to ignore
my opinion.

I'm all for a consistent code base, or at least for a clear rule, even if a
bit arbitrary. Style issues are too often a matter of taste, so having a
clear and enforced rule allows us to stop the discussion and focus on
something more important.

Since we should have a rule, that rule should be as much as possible the
"state of the art". In this case it seems clear that new array syntax is a
winner.

Now that we have a rule, we need to enforce it (style check during CI).
This is a clear communication of the intent and again helps us stop wasting
time on manual reviews to enforce the rule. Code review time is precious
and should be spent on important stuff.

Last question: how do we manage the transition? Changing perfectly working
code just for the sake of style seems a bit like wasted resources. So we
should ensure that new code, or any code that is touched follows the new
rule, we ignore existing untouched code. We need the appropriate tooling to
make that possible, and that's why I need to find some time to deploy a
SonarQube instance as a proof of concept.


Sorry if I'm rambling, it's a bit late and my English is rusty... but I
always find discussions about code style interesting. Mostly because I want
us to stop having them ...



On Fri, Feb 12, 2016 at 9:54 PM, Gabriel Wicke  wrote:

> Overall I'm PRO, as consistency is worth a lot, and tools can apply
> such changes consistently and efficiently.
>
> We have applied broad formatting changes to large JS codebases using
> jscs, which has worked well when those changes were well prepared.
> Typically, this involved gradually refining the tool settings until a
> reasonable diff was achieved.
>
> On Fri, Feb 12, 2016 at 12:44 PM, Chad  wrote:
> > On Fri, Feb 12, 2016 at 9:14 AM Chad  wrote:
> >
> >> On Fri, Feb 12, 2016 at 7:27 AM Daniel Kinzler 
> >> wrote:
> >>
> >>> CON: don't do mass migration to new syntax, only start using new styles
> >>> and
> >>> features when touching the respective bit of code anyway. The argument
> is
> >>> here
> >>> that touching many lines of code, even if it's just for whitespace
> >>> changes,
> >>> causes merge conflicts when doing backports and when rebasing patches.
> >>> E.g. if
> >>> we touch half the files in the codebase to change to the new array
> >>> syntax, who
> >>> is going to manually rebase the couple of hundred patches we have open?
> >>>
> >>>
> >>> As can be seen on the proposed patch I linked, several of the long term
> >>> developers oppose mass changes like this. A quick round of feedback in
> the
> >>> architecture committee draws a similar picture. However, perhaps there
> are
> >>> compelling arguments for doing the mass migration that we haven't heard
> >>> yet. So
> >>> please give a quick PRO or CON, optionally with some rationale.
> >>>
> >>> My personal vote is CON. No rebase hell please! Changing to the syntax
> >>> doesn't
> >>> buy us anything.
> >>>
> >>>
> >> CON, for all the reasons you mentioned. Also: style only changes are
> pain
> >> when you're
> >> trying to annotate/blame a particular line of code.
> >>
> >> ESPECIALLY for something so silly as array formatting which gains us
> >> *absolutely nothing*
> >>
> >> -Chad
> >>
> >
> > I change my vote to PRO.
> >
> > Mainly because people are gonna do it anyway...
> >
> > Last thoughts on the thread, I got bigger fish to fry than array syntax
> > sugar :D
> >
> > -Chad
> > ___
> > 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

Re: [Wikitech-l] Mass migration to new syntax - PRO or CON?

[bawolff]

> Last thoughts on the thread, I got bigger fish to fry than array syntax
> sugar :D
>
> -Chad

+1 to that.

--
bawolff

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

Re: [Wikitech-l] Mass migration to new syntax - PRO or CON?

[Chad]

On Fri, Feb 12, 2016 at 9:14 AM Chad  wrote:

> On Fri, Feb 12, 2016 at 7:27 AM Daniel Kinzler 
> wrote:
>
>> CON: don't do mass migration to new syntax, only start using new styles
>> and
>> features when touching the respective bit of code anyway. The argument is
>> here
>> that touching many lines of code, even if it's just for whitespace
>> changes,
>> causes merge conflicts when doing backports and when rebasing patches.
>> E.g. if
>> we touch half the files in the codebase to change to the new array
>> syntax, who
>> is going to manually rebase the couple of hundred patches we have open?
>>
>>
>> As can be seen on the proposed patch I linked, several of the long term
>> developers oppose mass changes like this. A quick round of feedback in the
>> architecture committee draws a similar picture. However, perhaps there are
>> compelling arguments for doing the mass migration that we haven't heard
>> yet. So
>> please give a quick PRO or CON, optionally with some rationale.
>>
>> My personal vote is CON. No rebase hell please! Changing to the syntax
>> doesn't
>> buy us anything.
>>
>>
> CON, for all the reasons you mentioned. Also: style only changes are pain
> when you're
> trying to annotate/blame a particular line of code.
>
> ESPECIALLY for something so silly as array formatting which gains us
> *absolutely nothing*
>
> -Chad
>

I change my vote to PRO.

Mainly because people are gonna do it anyway...

Last thoughts on the thread, I got bigger fish to fry than array syntax
sugar :D

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

Re: [Wikitech-l] Mass migration to new syntax - PRO or CON?

[Purodha Blissenbach]

A quick asking around among programmers here gives 7:1 pro array() and 
con [] syntax.
The latter is seen as less readable. Is there a technical advantage of 
[] over array()

that we should harvest?

Purodha

On 12.02.2016 21:06, Ricordisamoa wrote:

Il 12/02/2016 20:26, Legoktm ha scritto:

Hi,

On 02/12/2016 07:27 AM, Daniel Kinzler wrote:
Now that we target PHP 5.5, some people are itching to make use of 
some new

language features, like the new array syntax, e.g.
.

Mass changes like this, or similar changes relating to coding 
style, tend to
lead to controversy. I want to make sure we have a discussion about 
this here,

to avoid having the argument over and over on any such patch.

Please give a quick PRO or CON response as a basis for discussion.

In essence, the discussion boils down to two conflicting positions:

PRO: do mass migration to the new syntax, style, or whatever, as 
soon as
possible. This way, the codebase is in a consistent form, and that 
form is the
one we agreed is the best for readability. Doing changes like this 
is
gratifying, because it's low hanging fruit: it's easy to do, and 
has large

visible impact (well ok, visible in the source).
I'll offer an alternative, which is to convert all of them at once 
using
PHPCS and then enforce that all new patches use [] arrays. You then 
only
have one commit which changes everything, not hundreds you have to 
go

through while git blaming or looking in git log.

CON: don't do mass migration to new syntax, only start using new 
styles and
features when touching the respective bit of code anyway. The 
argument is here
that touching many lines of code, even if it's just for whitespace 
changes,
causes merge conflicts when doing backports and when rebasing 
patches. E.g. if
we touch half the files in the codebase to change to the new array 
syntax, who
is going to manually rebase the couple of hundred patches we have 
open?

There's no need to do it manually. Just tell people to run the phpcs
autofixer before they rebase, and the result should be identical to
what's already there. And we can have PHPCS run in the other 
direction

for backports ([] -> array()).

But if we don't do that, people are going to start converting things
manually whenever they work on the code, and you'll still end up 
with

hundreds of open patches needing rebase, except it can't be done
automatically anymore.

My personal vote is CON. No rebase hell please! Changing to the 
syntax doesn't

buy us anything.
Consistency buys us a lot. New developers won't be confused on 
whether
to use [] or array(). It makes entry easier for people coming from 
other

languages where [] is used for lists.


Objection: other languages may use [] for lists, but array() is more
similar to {} used for hash tables.



I think you're going to end up in rebase hell regardless, so we 
should
rip off the bandaid quickly and get it over with, and use the 
automated

tools we have to our advantage.

So, if we're voting, I'm PRO.

-- Legoktm

___
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

Re: [Wikitech-l] Mass migration to new syntax - PRO or CON?

[Bryan Davis]

On Fri, Feb 12, 2016 at 12:26 PM, Legoktm  wrote:
> I think you're going to end up in rebase hell regardless, so we should
> rip off the bandaid quickly and get it over with, and use the automated
> tools we have to our advantage.
>
> So, if we're voting, I'm PRO.

+2

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] Mass migration to new syntax - PRO or CON?

[Denny Vrandečić]

Although I haven't touched MediaWiki code for a year or so, based on my
experience with large codebases with tons of contributors, I would be very
much PRO.

I understand it is a pain, but as Legoktm points out, it is a manageable
pain. Having a consistent and higher-quality code base is worth the
migration pain. Three more advantages:
* future changesets are cleaner, as one does not have to do the clean up in
addition to the actual change they wanted to do
* automatic testing tools can capture issues with a higher confidence if it
doesn't have to take historical exceptions into account
* most developers code by copy-and-paste of style, structures, and ideas.
So even if a new styleguide is in place, it can often be the case that a
developer will start building off the old styleguide as they simply keep
their code consistent with the code that they are looking at

hth


On Fri, Feb 12, 2016 at 11:57 AM Brad Jorsch (Anomie) 
wrote:

> On Fri, Feb 12, 2016 at 2:26 PM, Legoktm 
> wrote:
>
> > I think you're going to end up in rebase hell regardless, so we should
> > rip off the bandaid quickly and get it over with, and use the automated
> > tools we have to our advantage.
> >
>
> This. Just get it over with, and then it's only one patch screwing up
> rebases and blames instead of lots.
>
>
>
> --
> 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] Mass migration to new syntax - PRO or CON?

[Jon Robson]

On 12 Feb 2016 12:44 p.m., "Chad"  wrote:
>
> On Fri, Feb 12, 2016 at 9:14 AM Chad  wrote:
>
> > On Fri, Feb 12, 2016 at 7:27 AM Daniel Kinzler 
> > wrote:
> >
> >> CON: don't do mass migration to new syntax, only start using new styles
> >> and
> >> features when touching the respective bit of code anyway. The argument
is
> >> here
> >> that touching many lines of code, even if it's just for whitespace
> >> changes,
> >> causes merge conflicts when doing backports and when rebasing patches.
> >> E.g. if
> >> we touch half the files in the codebase to change to the new array
> >> syntax, who
> >> is going to manually rebase the couple of hundred patches we have open?
> >>
> >>
> >> As can be seen on the proposed patch I linked, several of the long term
> >> developers oppose mass changes like this. A quick round of feedback in
the
> >> architecture committee draws a similar picture. However, perhaps there
are
> >> compelling arguments for doing the mass migration that we haven't heard
> >> yet. So
> >> please give a quick PRO or CON, optionally with some rationale.
> >>
> >> My personal vote is CON. No rebase hell please! Changing to the syntax
> >> doesn't
> >> buy us anything.
> >>
> >>
> > CON, for all the reasons you mentioned. Also: style only changes are
pain
> > when you're
> > trying to annotate/blame a particular line of code.
> >
> > ESPECIALLY for something so silly as array formatting which gains us
> > *absolutely nothing*
> >
> > -Chad
> >
>
> I change my vote to PRO.
>
> Mainly because people are gonna do it anyway...
>
> Last thoughts on the thread, I got bigger fish to fry than array syntax
> sugar :D

PRO for me too. If we do this with automated tools we avoid the human
error. You have me convinced.

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