Re: [Wikitech-l] JetBrains licenses for Volunteers and Staff

[Pine W]

Hi Yuri,

ReSharper interests me. This email refers to license upgrades. What is
involved in initially qualifying for a license?

Thanks,

Pine
On Apr 18, 2016 09:44, "Yuri Astrakhan"  wrote:

> PhpStorm, InteliJ IDEA, Resharper and other JetBrain users, we just
> received free upgraded licenses for all of their products.
>
> Check your account at https://account.jetbrains.com/licenses and login
> with
> that account inside your application to automatically use that license. If
> you don't see the license, contact me or Sam Reed, and we will add you
> right away.  On IRC: yurik or reedy, or via email.  We could also use a few
> more admins for these licenses. You will no longer need to copy/paste any
> licenses manually.
>
> IDEA:  use for PHP, JavaScript, Puppets, Ruby, and other web-related
> technologies
> https://www.jetbrains.com/idea/
>
> Resharper: for C# and Microsoft Visual Studio C++
> https://www.jetbrains.com/resharper/
>
> CLion: for C++
> https://www.jetbrains.com/clion/
> ___
> 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] historical trivia: who first picked UTC as Wikimedia time, when and why?

[MZMcBride]

David Gerard wrote:
>Question about obscure historical detail: Who picked UTC as Wikimedia
>time? When was this, and what was the thought process?
>
>(the answer is almost certainly "Brion or Jimbo, early 2001, it's the
>obvious choice", but I'm just curious as to details.)

Maybe Lee in 2002? Here's what I dug up.


https://phabricator.wikimedia.org/rSVN633

This revision by Lee from July 10, 2002 added the ability for users to
specify a time zone offset in hours. It also added three messages:
timezonetext, localtime, and timezoneoffset.

Of particular note, the text for the timezonetext key reads:

Enter number of hours your local time differs from server (U.S.
Pacific) time. For example, for U.S. East coast, enter "3".



https://phabricator.wikimedia.org/rSVN635

This revision (same author and day) reiterates that the server time is
"U.S. Pacific" when establishing the dellogpagetext and uploadlogpagetext
messages.



https://phabricator.wikimedia.org/rSVN723

This revision by Brion from August 28, 2002 adds a first draft of
Esperanto translations. I believe (I don't read and write Esperanto) that
the uploadlogpagetext and dellogpagetext messages say that the server time
is UTC. However, the timezonetext message appears to say that the server
time is UTC-8 and that if you want to use Central European Time, you need
to specify an offset of 9 hours.



https://phabricator.wikimedia.org/rSVN744

This revision by Lee from September 5, 2002 changes the timezonetext,
uploadlogpagetext, and dellogpagetext messages to read "UTC" instead of
"U.S. Pacific".



https://phabricator.wikimedia.org/rSVN773

This revision by Brion from September 18, 2002 introduces the
$wgLocaltimezone configuration variable. I've updated
https://www.mediawiki.org/wiki/Manual:$wgLocaltimezone to note this.


Looking at early English Wikipedia contributions,
 is the oldest edit I
can find of a signed comment that includes a time zone: "05:42 Jul 21,
2002 (PDT)". There are many older signatures, to be sure, and some of
them in early 2002 include a date, but without a time zone. This signature
seems to confirm that the time zone was U.S. Pacific time in 2002.

 
MZMcBride



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

Re: [Wikitech-l] JetBrains licenses for Volunteers and Staff

[Danny B.]

For the list people - Please ignore the first sentence... That has its own 
context known by the intended recipient and was supposed to be sent 
somewhere else... My now-already-former email client accidentaly sent it 
before I changed the recipient's address... :-/



-- Původní zpráva --
Od: Danny B. 
Komu: Wikimedia developers 
Datum: 10. 5. 2016 2:14:51
Předmět: Re: [Wikitech-l] JetBrains licenses for Volunteers and Staff

"And this is coming from the non-serious-Wikimedia-business address... ;-)

However: 
" We could also use a few more admins for these licenses." - if it is still 
valid, I'm reporting to the duty, sir!


Danny B.


-- Původní zpráva --
Od: Yuri Astrakhan 
Komu: Wikimedia developers 
Datum: 18. 4. 2016 18:45:10
Předmět: [Wikitech-l] JetBrains licenses for Volunteers and Staff

"PhpStorm, InteliJ IDEA, Resharper and other JetBrain users, we just
received free upgraded licenses for all of their products.

Check your account at https://account.jetbrains.com/licenses and login with
that account inside your application to automatically use that license. If
you don't see the license, contact me or Sam Reed, and we will add you
right away. On IRC: yurik or reedy, or via email. We could also use a few
more admins for these licenses. You will no longer need to copy/paste any
licenses manually.

IDEA: use for PHP, JavaScript, Puppets, Ruby, and other web-related
technologies
https://www.jetbrains.com/idea/

Resharper: for C# and Microsoft Visual Studio C++
https://www.jetbrains.com/resharper/

CLion: for C++
https://www.jetbrains.com/clion/
___
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] Phabricator Differential lackings

[Derk-Jan Hartman]

As someone who has worked with Differential outside of Wikimedia projects, I 
can summarize this back as: The problem of Differential is not the 
possibilities and functionality, it is a problem of usability (UX). Github, 
Gitlab and Bitbucket have the UX of using tons of different repo's down, and 
Differential/Phab does not. And the reason is that the first three have been 
developed as massive community projects that could not afford to NOT focus on 
usability of one user interacting with many repo's, owning them etc. (they have 
traditionally traded down on ticket management and projects, because people 
already had good options outside of repo hosting for this, only in the past 2 
years or so you see this part quickly evolving for them as well).

Phabricator however has always been much more driven technology-first, focused 
on smaller numbers of developers and Enterprise situations. This does have some 
advantages, I think the way that Maniphest, tags and workboards for instance 
have evolved to being very useful, is partly due to the fact of building a 
solid technology stack first. But unfortunately, the UI for the differential 
stuff has sort of lagged behind and is not properly exposing and simplifying 
the power of differential (likely because there has not been enough need yet to 
fix it). The problem is that you have to hunt for an app called Owners, instead 
of pressing a 'Claim ownership'-button, not the fact that you cannot have an 
owner.

DJ


> On 9 mei 2016, at 21:42, Mukunda Modell  wrote:
> 
> Hi Krinkle,
> 
> I think you've raised some valid points, however, you've missed a couple of
> details that are relevant. I'll try to fill in the details so that we can
> get a better vision of what the workflow looks like with Differential. Rest
> assured, those of us who advocate for using Differential do not want to
> break your workflow, or anyone else's.  There will be some changes for sure
> but we've been working extremely hard to address everyone's concerns for
> many months and the only reason that concerns have not been addressed is
> because we weren't aware of them or we haven't gotten to them yet.
> 
> I'll address each of your major points inline below the quoted text:
> 
> 
> On Mon, May 9, 2016 at 1:26 PM, Krinkle  > wrote:
> 
>> I apologise if some of the below does in fact exist, I'd gladly find out!
>> 
>> There are three major parts of my workflow as project maintainer and
>> contributor that I find lacking in Differential right now and are strong
>> reason for me to discourage anyone from migrating to it. In addition,
>> projects that have already migrated are essentially non-existent and blind
>> to my workflow as a result. I've tried but even if I accept loss in
>> productivity, I can't even find a workaround for these.
>> 
>> 1. Casual notifications about new patches and merged commits (IRC
>> notifications). - https://phabricator.wikimedia.org/T116330 
>> 
>> 
>> 
> If you follow the trail of blockers on that task you end up at
> https://phabricator.wikimedia.org/T123417 
>  which is assigned to me and will
> be addressed.  This will be a small amount of work and it just hasn't
> happened yet because it hasn't been the highest priority, especially when
> people still regard migration to Differential as "premature."
> 
> 
>> 2. Discover pending patches.
>> 
>> While Diffusion is a fine repo browser, it appears to lack any link back to
>> Differential. Even when manually going to Differential, it doesn't appear
>> to be any concept of "repo". It only has a global concept of "diff" and
>> "reviewer" (e.g. you can list diffs for review, and your own open diffs).
>> Unlike Maniphest (which has a concept of projects that have their own pages
>> with useful outgoing links). There is no list of projects with a link to
>> see a project's patches. This unlike Gerrit or GitHub where projects are
>> linked to searches for open patches or open pull-requests. This makes it
>> very non-transparent for potential consumers of our code, and casual
>> contributors to find out about open patches. This is an important indicator
>> for developers to determine the health of a project. It's also an easy
>> way-in to for new reviewers, and an important interface for project
>> maintainers to easily list open patches from time to time. Without this, I
>> expect our code review habits to become even worse than they already are.
>> 
>> https://phabricator.wikimedia.org/differential/ (no projects listed) ->
>> https://phabricator.wikimedia.org/differential/query/all/ (no repos named
>> alongside the diffs) -> https://phabricator.wikimedia.org/D229 (links to
>> diffusion) -> https://phabricator.wikimedia.org/diffusion/GOJR/ (no link
>> to
>> query to differential).
>> 
>> If I see this correctly, there is simply no way to naturally get to 

Re: [Wikitech-l] JetBrains licenses for Volunteers and Staff

[Danny B.]

And this is coming from the non-serious-Wikimedia-business address... ;-)

However: 
" We could also use a few more admins for these licenses." - if it is still 
valid, I'm reporting to the duty, sir!


Danny B.


-- Původní zpráva --
Od: Yuri Astrakhan 
Komu: Wikimedia developers 
Datum: 18. 4. 2016 18:45:10
Předmět: [Wikitech-l] JetBrains licenses for Volunteers and Staff

"PhpStorm, InteliJ IDEA, Resharper and other JetBrain users, we just
received free upgraded licenses for all of their products.

Check your account at https://account.jetbrains.com/licenses and login with
that account inside your application to automatically use that license. If
you don't see the license, contact me or Sam Reed, and we will add you
right away. On IRC: yurik or reedy, or via email. We could also use a few
more admins for these licenses. You will no longer need to copy/paste any
licenses manually.

IDEA: use for PHP, JavaScript, Puppets, Ruby, and other web-related
technologies
https://www.jetbrains.com/idea/

Resharper: for C# and Microsoft Visual Studio C++
https://www.jetbrains.com/resharper/

CLion: for C++
https://www.jetbrains.com/clion/
___
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] historical trivia: who first picked UTC as Wikimedia time, when and why?

[Tim Starling]

UseMod had a concept of "server time", and early versions of the main
page stated that server time was US Pacific Time. The date on the main
page was heroically updated manually by Malcolm Farmer, for example:



This archived RecentChanges gives you an idea of what the interface
looked like, the timezone is not specified ($ScriptTZ was not set) but
it is presumably all Pacific Time:



UseMod stored dates in UNIX time (integer since epoch), which is
implicitly UTC, but converted them to server time for display.

Magnus's Wikipedia script also stored dates in UTC format, and
defaulted to server time for display. It had a user preference called
"hourDiff" which was relative to server time. For example in
special_recentchangeslayout.php:

  $adjusted_time_sc = tsc ( $s->cur_timestamp ) + 3600 *
$user->options["hourDiff"];
  $day = date ( "l, F d, Y" , $adjusted_time_sc);
  $time = date ( "H:i" , $adjusted_time_sc ) ;

tsc() converts the database time to UNIX time.

There were actually no references to UTC or GMT in the code base, and
it never calls gmdate() . So it seems Magnus more or less carried on
the same UI time zone policy as UseMod. If it was installed on the
same server as UseMod, then it presumably would have displayed Pacific
Time.

On the other hand, the early version of phase3 I have here does make
references to UTC, for example:

"timezonetext"  => "Enter number of hours your local time differs
from server time (UTC).",

Instead of converting database dates to server time, phase3's
Language::date() and Language::time() just takes substrings of the
database date:

if( $wgAmericanDates ) {
  $d = $this->getMonthAbbreviation( substr( $ts, 4, 2 ) ) .
" " . (0 + substr( $ts, 6, 2 )) . ", " .
substr( $ts, 0, 4 );
} else {
  $d = (0 + substr( $ts, 6, 2 )) . " " .
$this->getMonthAbbreviation( substr( $ts, 4, 2 ) ) . " " .
substr( $ts, 0, 4 );
}

So for the elevation of UTC as a standard in the UI, I think we can
safely credit Lee Daniel Crocker.

-- Tim Starling

On 10/05/16 02:15, Brion Vibber wrote:
> In 2001 when Magnus was writing the initial attempt at a custom wiki engine
> in PHP backed by MySQL, he chose to use the TIMESTAMP column type.
> 
> TIMESTAMPs in MySQL 3 were automatically filled out by the server at INSERT
> time, normalized to UTC, and exposed in the 14-digit MMDDHHMMSS format
> we still know and love today.
> 
> The first TIMESTAMP column in a row also got automatically updated when you
> changed something in a row, so we ended up switching them from TIMESTAMP
> type to text strings and just filled out the initial values on the PHP
> side. We could have used DATETIME but that would have been a slightly
> harder transition at the time, and would have introduced the fun of the
> server settings trying to give you local time half the time...
> 
> -- brion
> 
> On Mon, May 9, 2016 at 1:39 AM, David Gerard  wrote:
> 
>> Question about obscure historical detail: Who picked UTC as Wikimedia
>> time? When was this, and what was the thought process?
>>
>> (the answer is almost certainly "Brion or Jimbo, early 2001, it's the
>> obvious choice", but I'm just curious as to details.)
>>
>>
>> - d.
>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> 



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

[Wikitech-l] Help improve search relevance with Discernatron 烙

[Chris Koerner]

The Discovery department's [1] work to improve search continues with a new
tool! We are asking volunteers to help choose, or discern, which search
results are the most relevant.

One way of improving search results relevance is to provide search results
from multiple search engines side-by-side for comparison. Participants pick
the best, most relevant results, which are then used to tune our own search
results. It's one way to help improve search with human assistance, by
showing articles that are most relevant to search queries. This system is
used by many R departments and gives great results.

Discernatron is a tool developed by the Discovery department for just this
sort of work. Visitors are asked to pick the most relevant results across
four different search result sets. The data is then used to help improve
our relevancy model for search. Screenshot at [2]

If you are interested in helping, you can access Discernatron at
https://discernatron.wmflabs.org/ and authenticate with your unified user
account.

To learn more about the tool visit Mediawiki.org. [3]

[1] https://www.mediawiki.org/wiki/Discovery
[2] https://meta.wikimedia.org/wiki/File:Discernatron_screenshot.png
[3] https://www.mediawiki.org/wiki/Discernatron


-- 
Yours,
Chris Koerner
Community Liaison - Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Phabricator Differential lackings

[Mukunda Modell]

Hi Krinkle,

I think you've raised some valid points, however, you've missed a couple of
details that are relevant. I'll try to fill in the details so that we can
get a better vision of what the workflow looks like with Differential. Rest
assured, those of us who advocate for using Differential do not want to
break your workflow, or anyone else's.  There will be some changes for sure
but we've been working extremely hard to address everyone's concerns for
many months and the only reason that concerns have not been addressed is
because we weren't aware of them or we haven't gotten to them yet.

I'll address each of your major points inline below the quoted text:


On Mon, May 9, 2016 at 1:26 PM, Krinkle  wrote:

> I apologise if some of the below does in fact exist, I'd gladly find out!
>
> There are three major parts of my workflow as project maintainer and
> contributor that I find lacking in Differential right now and are strong
> reason for me to discourage anyone from migrating to it. In addition,
> projects that have already migrated are essentially non-existent and blind
> to my workflow as a result. I've tried but even if I accept loss in
> productivity, I can't even find a workaround for these.
>
> 1. Casual notifications about new patches and merged commits (IRC
> notifications). - https://phabricator.wikimedia.org/T116330
>
>
If you follow the trail of blockers on that task you end up at
https://phabricator.wikimedia.org/T123417 which is assigned to me and will
be addressed.  This will be a small amount of work and it just hasn't
happened yet because it hasn't been the highest priority, especially when
people still regard migration to Differential as "premature."


> 2. Discover pending patches.
>
> While Diffusion is a fine repo browser, it appears to lack any link back to
> Differential. Even when manually going to Differential, it doesn't appear
> to be any concept of "repo". It only has a global concept of "diff" and
> "reviewer" (e.g. you can list diffs for review, and your own open diffs).
> Unlike Maniphest (which has a concept of projects that have their own pages
> with useful outgoing links). There is no list of projects with a link to
> see a project's patches. This unlike Gerrit or GitHub where projects are
> linked to searches for open patches or open pull-requests. This makes it
> very non-transparent for potential consumers of our code, and casual
> contributors to find out about open patches. This is an important indicator
> for developers to determine the health of a project. It's also an easy
> way-in to for new reviewers, and an important interface for project
> maintainers to easily list open patches from time to time. Without this, I
> expect our code review habits to become even worse than they already are.
>
> https://phabricator.wikimedia.org/differential/ (no projects listed) ->
> https://phabricator.wikimedia.org/differential/query/all/ (no repos named
> alongside the diffs) -> https://phabricator.wikimedia.org/D229 (links to
> diffusion) -> https://phabricator.wikimedia.org/diffusion/GOJR/ (no link
> to
> query to differential).
>
> If I see this correctly, there is simply no way to naturally get to a list
> of open patches of a project.
>

This is a valid concern and I think Differential really is lacking in ways
to browse open patches, however, I think you've missed some critical
details.


   1. https://phabricator.wikimedia.org/differential/query/advanced/  gives
   you a way to query by project tags
   2. Phabricator is almost completely organized around tasks.  You can add
   a differential revision to a task and the final commit also gets attached
   to the task.  The way to browse units of work is by searching maniphest,
   not searching differential or diffusion.
   3. Phabricator does not consider 'one repository' to be equal to 'one
   project' and there is a tool specifically designed for organizing
   repositories in to larger units called 'packages' - that tool is
   https://phabricator.wikimedia.org/owners/  by combining owners with
   herald rules you can get granular notifications of patches submitted in
   your area of interest/expertise/responsibility. Not only is this granular
   but it's automated - appropriate reviewers get added automatically to
   patches that affect the specific code that they are qualified to review.
   After you've been added as a reviewer then revisions show up in
   Differential and there is visibility into new patches as well as "stale"
   patches which are blocking others and have been waiting for some
   (configurable) amount of time.
   4. Differential links to 'recent similar revisions' on the differential
   revision page: https://phabricator.wikimedia.org/D224

So while I agree that diffusion should really have better integration with
differential, and differential browsing is less than perfect, I disagree
with the statement that there is no way to "naturally get to a list of open
patches of a 

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

[Krinkle]

On Mon, May 9, 2016 at 7:17 PM, Brion Vibber  wrote:

>
>
> So, step 2 happens at least 30 days after deploying step 1? Or step 2
> retains same behavior for Output A?
>
> -- brion
>
>
14 days [1]. But yes, we'll need some breathing room after step 1.

After step 2, old output A would try to load "site" as style module still
(which no longer has styles). Though after a FOUC, it would still fallback
by loading 'site.styles' on-demand as dependency of "site".

[1] https://phabricator.wikimedia.org/T124954

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

[Wikitech-l] Phabricator Differential lackings

[Krinkle]

I apologise if some of the below does in fact exist, I'd gladly find out!

There are three major parts of my workflow as project maintainer and
contributor that I find lacking in Differential right now and are strong
reason for me to discourage anyone from migrating to it. In addition,
projects that have already migrated are essentially non-existent and blind
to my workflow as a result. I've tried but even if I accept loss in
productivity, I can't even find a workaround for these.

1. Casual notifications about new patches and merged commits (IRC
notifications). - https://phabricator.wikimedia.org/T116330

2. Discover pending patches.

While Diffusion is a fine repo browser, it appears to lack any link back to
Differential. Even when manually going to Differential, it doesn't appear
to be any concept of "repo". It only has a global concept of "diff" and
"reviewer" (e.g. you can list diffs for review, and your own open diffs).
Unlike Maniphest (which has a concept of projects that have their own pages
with useful outgoing links). There is no list of projects with a link to
see a project's patches. This unlike Gerrit or GitHub where projects are
linked to searches for open patches or open pull-requests. This makes it
very non-transparent for potential consumers of our code, and casual
contributors to find out about open patches. This is an important indicator
for developers to determine the health of a project. It's also an easy
way-in to for new reviewers, and an important interface for project
maintainers to easily list open patches from time to time. Without this, I
expect our code review habits to become even worse than they already are.

https://phabricator.wikimedia.org/differential/ (no projects listed) ->
https://phabricator.wikimedia.org/differential/query/all/ (no repos named
alongside the diffs) -> https://phabricator.wikimedia.org/D229 (links to
diffusion) -> https://phabricator.wikimedia.org/diffusion/GOJR/ (no link to
query to differential).

If I see this correctly, there is simply no way to naturally get to a list
of open patches of a project.

3. Notification about new patches and merged commits.

There is appears to be no way to subscribe to a repo (e.g. as a maintainer
of that repo) so that I may be notified of new diffs and/or landed commits.
This is worse due to #2, which would've been a workaround (albeit a costly
one, due to pull:N vs push:1).

In addition to these workflow concerns, there is also Continuous
integration of course. But that's a separate issue.

I'm bringing up these concerns now because contrary to what I expected,
Differential is being adopted by quite a few repos now despite it being
premature.

-- Krinkle
___
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 Monday, May 9, 2016, Krinkle  wrote:

> On Wed, May 4, 2016 at 1:43 PM, Brion Vibber  > wrote:
>
> > 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.
> >
>
>
> The restriction added for T92459 only applies to addModuleStyles() calls.
> No changes to load.php HTTP response behaviour.
>
> There is one change required before we enable the new restriction: Convert
> internal details of how user/site/gadget modules are registered and loaded.
> These will be forward and backward compatible.
>
> The new rule doesn't enable conceptually new features. We are currently
> avoiding a certain kind of relationship for performance reasons (dynamic
> modules depending on style modules) - which we won't need to avoid any
> longer. We'll need to wait for cache to roll over in between two steps to
> avoid styles from going missing.
>
> Currently:
> * Output A:  (loads site styles), mw.loader.load('site')
> - (loads site scripts and styles)
>
> Step 1:
> * Create 'site.styles'
> * Output A behaviour unchanged
> * New Output B: , site.styles=ready,
> mw.loader.load('site') - (loads site scripts and styles)
>
> Step 2:
> * Remove styles from 'site', make 'site' depend on 'site.styles' (only
> affects startup module)
> * No change in HTML output
> * Output B new behaviour: , site.styles=ready,
> mw.loader.load('site') - (loads site scripts)


So, step 2 happens at least 30 days after deploying step 1? Or step 2
retains same behavior for Output A?

-- brion


>
>
> On Wed, May 4, 2016 at 1:43 PM, Brion Vibber  > wrote:
>
>
> > *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.
> >
> >
> Yeah, we'll provide good release notes upfront. And probably 1 or 2 week
> iteration in git-master with warning only before enforcing with a run-time
> exception.
>
>
> -- Timo
> ___
> 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] Thursday: Get your patch reviewed during "Code Review office hours"

[Jon Robson]

Thanks for setting this up  Mukunda!

On Sun, May 8, 2016 at 8:48 PM, Mukunda Modell  wrote:
> Starting Thursday May 12th, 13:00 PDT ( 20:00 GMT ) we will be having the
> first weekly Code Review office hours on freenode IRC in the
> #wikimedia-codereview channel.
>
> Event details: https://phabricator.wikimedia.org/E179
> Background: https://phabricator.wikimedia.org/T128371
>
> Thanks to everyone who's been helping to organize this. We would welcome
> people to submit your patches for review as well as reviewers who can spare
> a few minutes to provide feedback and hopefully merge some patches!
>
> If you can't make it during the scheduled time period then please feel free
> to suggest other times that would be better for you. I intend to set up one
> or two other weekly time slots, at least one of which should be at a time
> that's more convenient for people in Europe and Asia.
>
> Looking forward to seeing you in #wikimedia-codereview
>
> __
>  Mukunda Modell,
>  Release 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] historical trivia: who first picked UTC as Wikimedia time, when and why?

[Brion Vibber]

In 2001 when Magnus was writing the initial attempt at a custom wiki engine
in PHP backed by MySQL, he chose to use the TIMESTAMP column type.

TIMESTAMPs in MySQL 3 were automatically filled out by the server at INSERT
time, normalized to UTC, and exposed in the 14-digit MMDDHHMMSS format
we still know and love today.

The first TIMESTAMP column in a row also got automatically updated when you
changed something in a row, so we ended up switching them from TIMESTAMP
type to text strings and just filled out the initial values on the PHP
side. We could have used DATETIME but that would have been a slightly
harder transition at the time, and would have introduced the fun of the
server settings trying to give you local time half the time...

-- brion

On Mon, May 9, 2016 at 1:39 AM, David Gerard  wrote:

> Question about obscure historical detail: Who picked UTC as Wikimedia
> time? When was this, and what was the thought process?
>
> (the answer is almost certainly "Brion or Jimbo, early 2001, it's the
> obvious choice", but I'm just curious as to details.)
>
>
> - d.
>
> ___
> 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] ResourceLoader addModuleStyles() issues

[Jon Robson]

Okay great! :)
I got lost in the details. Lets make it so!

On Mon, May 9, 2016 at 6:50 AM, Krinkle  wrote:
> On Sun, May 8, 2016 at 5:47 PM, Jon Robson  wrote:
>
>> Apologies if I'm missing something that makes this so complicated but
>> could we not simply throw an error/warning if you use addModuleStyles
>> on a module with scripts set
>
>
>
> That's exactly what I'm proposing we do.
> https://phabricator.wikimedia.org/T92459
>
>
> -- Timo
> ___
> 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] ResourceLoader addModuleStyles() issues

[Brad Jorsch (Anomie)]

On Mon, May 9, 2016 at 9:40 AM, Krinkle  wrote:

> The corruption I hypothesised is avoided because by design, page styles
> modules may not have dependencies. If a module 'foo' ignores that design
> requirement and changes regardless to require 'bar', then that change is in
> error and should be reverted.
>

https://gerrit.wikimedia.org/r/#/c/258662/ comes to mind, although you
could play semantic games there with respect to what exactly depends on
what since it seems pretty hard for a CSS file in isolation to actually
depend on another CSS file versus the HTML output that uses the first CSS
file also requiring the second for proper rendering.

-- 
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] ResourceLoader addModuleStyles() issues

[Krinkle]

On Sun, May 8, 2016 at 5:47 PM, Jon Robson  wrote:

> Apologies if I'm missing something that makes this so complicated but
> could we not simply throw an error/warning if you use addModuleStyles
> on a module with scripts set



That's exactly what I'm proposing we do.
https://phabricator.wikimedia.org/T92459


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

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

[Krinkle]

On Wed, May 4, 2016 at 1:43 PM, Brion Vibber  wrote:

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


The restriction added for T92459 only applies to addModuleStyles() calls.
No changes to load.php HTTP response behaviour.

There is one change required before we enable the new restriction: Convert
internal details of how user/site/gadget modules are registered and loaded.
These will be forward and backward compatible.

The new rule doesn't enable conceptually new features. We are currently
avoiding a certain kind of relationship for performance reasons (dynamic
modules depending on style modules) - which we won't need to avoid any
longer. We'll need to wait for cache to roll over in between two steps to
avoid styles from going missing.

Currently:
* Output A:  (loads site styles), mw.loader.load('site')
- (loads site scripts and styles)

Step 1:
* Create 'site.styles'
* Output A behaviour unchanged
* New Output B: , site.styles=ready,
mw.loader.load('site') - (loads site scripts and styles)

Step 2:
* Remove styles from 'site', make 'site' depend on 'site.styles' (only
affects startup module)
* No change in HTML output
* Output B new behaviour: , site.styles=ready,
mw.loader.load('site') - (loads site scripts)


On Wed, May 4, 2016 at 1:43 PM, Brion Vibber  wrote:


> *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.
>
>
Yeah, we'll provide good release notes upfront. And probably 1 or 2 week
iteration in git-master with warning only before enforcing with a run-time
exception.


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

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

[Krinkle]

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

> On Wed, May 4, 2016 at 6:34 AM, Krinkle  wrote:
>
> > [..] We don't currently require modules to say whether they are a
> dynamic module.
>
>
> Maybe we *should* require that.
>
> Then that could allow us to [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 [..]



Agreed. Though I'd like to tackle that separately in
https://phabricator.wikimedia.org/T127328.
See the section about removing "position" and adding a module type property.

>
>
On Wed, May 4, 2016 at 4:23 PM, Brad Jorsch (Anomie) 
 wrote:

> On Wed, May 4, 2016 at 6:34 AM, Krinkle  wrote:
>
> > For gadgets we can try to infer the intent [with] a way to [declare]
> explicitly.

>
>
> A gadget might want both [..]
>


I acknowledge this use case. We are no longer allowing hybrid modules
(which were never intentionally allowed, and don't properly work as
demonstrated by the styles loading twice), but the idea of providing both
is valid.

In such case one merely needs to register them separately and declare a
dependency.
Similar to what we'll do for the user/site modules, and like we'll do for
oojs-ui.

Since the styles portion may not be useful for end-users directly, such
module can be registered as hidden gadget. This concept is relatively new,
but should work fine for now. (Back-ported from Gadgets 2.0.)


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

> [..] But don't we have the corruption anyway? [..] module 'foo'
>
is changed so it also needs 'bar', so page Foo now has to call
> addModuleStyles( [ 'foo', 'bar' ] ). [..]
>


The corruption I hypothesised is avoided because by design, page styles
modules may not have dependencies. If a module 'foo' ignores that design
requirement and changes regardless to require 'bar', then that change is in
error and should be reverted.

There is no one way to make everything easy. In designing RL we saw two
ways to make style modules work, we choose this way. It makes most cases
easy, and some cases like this a bit harder. But unless it makes valid use
cases impossible, it's imho a worthwhile tradeoff.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] historical trivia: who first picked UTC as Wikimedia time, when and why?

[David Gerard]

Question about obscure historical detail: Who picked UTC as Wikimedia
time? When was this, and what was the thought process?

(the answer is almost certainly "Brion or Jimbo, early 2001, it's the
obvious choice", but I'm just curious as to details.)


- d.

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