Re: [Wikitech-l] Getting birthday from the sidebar of a wiki page and showing in the home page

2013-10-03 Thread legoktm
On Thu, Oct 3, 2013 at 8:05 AM, Mark A. Hershberger m...@everybody.orgwrote:


 Unfortunately I don't see a way to get this information any API query.

 You can find someone's birthday, but I don't see a way to look for
 entities that are people (P735 -- personal name) with birthdays (P569).


This feature of Wikidata is still in progress,  for the time being you can
use Magnus's tool[1] to generate a list that a bot could use.

[1] http://208.80.153.172/

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

Re: [Wikitech-l] migrating hooks doc to doxygen?

2013-11-12 Thread legoktm
On Sat, Jun 8, 2013 at 8:26 AM, Brad Jorsch bjor...@wikimedia.org wrote:
 On Sat, Jun 8, 2013 at 11:07 AM, Brian Wolff bawo...@gmail.com wrote:
 Both Manual:Hooks/foo and all the $wgFoo pages can definitely benefit
 from some automation.

 I know the reason I usually don't update the Manual pages is because by the
 time the change gets reviewed and merged, I don't remember anymore that the
 change actually requires Manual page updates. I have the same problem with
 remembering to close bugs; the automated comments posted to the bug on
 merge now often remind me, at least for bugs I'm on the CC list for.

A bit late, but I wrote a script[1] to do this today, since I didn't
want to manually
create a page for the hook I added to core today[2].

It's not totally perfect, [3] doesn't look that nice, and it's not
smart enough to
figure out things like the type of an object based on reading the text.

 If someone were to write a bot that would comment on the changeset after it
 was merged linking to hook and $wgFoo manual pages that probably need
 updating, that would serve as a useful reminder.

If people like this script, we could have a bot automatically create a stub page
on mw.o when the change is merged, and then a human can fix it up.

-- Legoktm

[1] https://github.com/legoktm/mwhooks/blob/master/create_onwiki.py
[2] https://www.mediawiki.org/wiki/Manual:Hooks/GetLogTypesOnUser
[3] https://www.mediawiki.org/wiki/Manual:Hooks/WikiPageDeletionUpdates

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

[Wikitech-l] RFC: Configuration database 2

2013-11-19 Thread legoktm
Hello,
As discussed in the last RFC review meeting, I've put together a
proposal for an on-wiki configuration scheme:
https://www.mediawiki.org/wiki/Requests_for_comment/Configuration_database_2.
Comments and feedback would be appreciated!

I've also added this to the list for tomorrow's RFC review meeting.

Thanks,
-- Kunal Mehta (Legoktm)

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

[Wikitech-l] [Bug 57891] Review and deploy GlobalCssJs extension

2013-12-13 Thread legoktm
On Fri, Dec 13, 2013 at 2:04 PM, Bartosz Dziewoński matma@gmail.com wrote:

 It's sorta kinda happening as we speak while no one is looking ;)

 https://bugzilla.wikimedia.org/show_bug.cgi?id=57891

 --
 Matma Rex

Looks like the cat got out of the bag.

The GlobalCssJs extension allows users to add custom JS or CSS for
themselves on all wikis where they have an account. It's basically the
equivalent of common.js, but on a global scale. It has been a
requested feature since 2008[1].

For those not familiar with the history of global js/css, there
currently is a bot run by a steward[2] which creates common.js pages
importing the user's global.js upon request. This is mainly used by
users in the SWMT[3] to do things like enable global Twinkle[4]. While
this method works, it doesn't take advantage of ResourceLoader.

The extension will load User:$username/global.js and
User:$username/global.css using ResourceLoader. It also includes
MediaWiki:Global.js/css as the global equivalents of
MediaWiki:Common.js/css.

The bulk of the code is still awaiting review in gerrit[5].

[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=13953#c0
[2] https://meta.wikimedia.org/wiki/Synchbot
[3] https://meta.wikimedia.org/wiki/SWMT
[4] https://meta.wikimedia.org/wiki/User:Snowolf/How_to_globally_Twinkle
[5] https://gerrit.wikimedia.org/r/#/c/94837


-- Legoktm

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

Re: [Wikitech-l] OAuth Devlopment Training

2013-12-20 Thread legoktm
On Fri, Dec 20, 2013 at 9:33 PM, Dan Andreescu dandree...@wikimedia.org wrote:
 And if anyone's curious, the session helped me get identify implemented in
 Wikimetrics: https://gerrit.wikimedia.org/r/#/c/102618/.  I had to hack the
 unmaintained Flask-Oauth module quite a bit, so eventually I might move to
 rauth.  But it seems to work and makes me feel fuzzier about using OAuth as
 pseudo authentication.

There is the flask-mwoauth[1] library created by valhallasw that the
gerrit-patch-uploader uses.

[1] https://github.com/valhallasw/flask-mwoauth

--Legoktm

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

Re: [Wikitech-l] Proposed Program Architecture Summit 2014

2014-01-16 Thread legoktm
Hi,
Given that the Configuration cluster had the second most number of
votes in the poll, why was it left of the agenda entirely?
-- Legoktm

On Thu, Jan 16, 2014 at 10:47 AM, Diederik van Liere
dvanli...@wikimedia.org wrote:
 Heya,

 The Program Committee for the Architecture Summit has published a proposed
 program: https://www.mediawiki.org/wiki/Architecture_Summit_2014

 Highlights of the Program:

 1) We have tried to incorporate flexibility into the program by allowing 4
 unconference break-out slots, 1 open plenary session and a daily ‘agenda
 bashing’ session to make adjustments to the program if the need arises.

 2) There are 3 plenary sessions: HTML Templating (
 https://www.mediawiki.org/wiki/Architecture_Summit_2014/HTML_templating),
 Service Oriented Architecture (
 https://www.mediawiki.org/wiki/Architecture_Summit_2014/Service-oriented_architecture)
 and one open slot. Possible candidates for the open session include
 Performance and UI styling but this will be decided during the Summit.  The
 short list will include the higher vote-getters in the straw poll, so if
 there’s one of the clusters you strongly feel should be part of the
 program, now is your time to make that case.

Make that case where? Given that slidedecks are supposed to be
prepared, shouldn't this be decided beforehand rather than waiting?

 3) There are 6 breakout sessions:

 * 2 planned: UI styling (
 https://www.mediawiki.org/wiki/Architecture_Summit_2014/UI_styling) and
 Storage Services (
 https://www.mediawiki.org/wiki/Architecture_Summit_2014/Storage_services)

 * 4 unconference slots

 There will be a round of Lightning Talks at the beginning of the plenary
 session after the breakout session to summarize what happened by answering
 the following questions:

 a) What did you try to achieve?

 b) What did you decide?

 c) What are the next steps?

 4) Architecture Panel and Value discussion. This is a plenary session for
 the architects to share what they value in good architecture, as well as
 talk about how they see the architecture of MediaWiki evolving, and what
 role people other than our historical core group of three have to play in
 the process.  During this session, we hope to at least answer some of the
 questions outlined in the recent discussion of the RFC process[1]

 5) RFC roulette: a one hour closing session for RFC’s that have not been in
 the spotlight during the Summit and where the next step can be decided.
 This is intended to be fast paced and slightly chaotic. If you would like
 to hear what’s next for your RFC please participate with the roulette by
 adding your name to
 https://www.mediawiki.org/wiki/Architecture_Summit_2014/RFC_roulette

 What does the Program Committee expect from summit participants?

 a) If you are a participant, please familiarize yourself with the latest
 version of the RFC’s that you care about.

 b) If you are an author of an RFC that is scheduled in a plenary session,
 please start preparing in collaboration with the other authors from the
 same session on a short slidedeck that summarizes all the different RFC’s.
 One slide that could be really useful is to have a matrix that highlights
 key differences between alternative / competing proposals. Diederik will
 contact the folks who are invited for the plenary session to help
 coordinate and organize.

 c) If you are an author of an RFC that is scheduled in a breakout session,
 please create maximum 3 slides that summarize your RFC and think about what
 you want to get out of your session.  The slides are optional, but the
 requisite level of preparation is not.

 d) If you want to run an unconference slot then start thinking about a
 theme and possible co-organizers. It’s okay to use an existing RFC cluster.

 Two quick final notes:

 The Program has been created using the input from the straw poll (
 https://www.mediawiki.org/wiki/Architecture_Summit_2014/Straw_poll), input
 from the Program Committee and input from the Engineering Community Team.

 To see which RFC’s compose a cluster please have a look at
 https://www.mediawiki.org/wiki/Architecture_Summit_2014/RFC_clusters

 Looking forward to your feedback!



 Best regards,

 The Program Committee


 [1]  Discussion of the RFC process:
 https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Process#
 ___
 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] On-wiki configuration RfCs (was: Proposed Program Architecture Summit 2014)

2014-01-19 Thread legoktm
On Thu, Jan 16, 2014 at 2:52 PM, Rob Lanphier ro...@wikimedia.org wrote:

 Let's put that number at 95%  :-)  I don't want to commit the group to
 anything; it's at the top of the short list, but you never know where
 people will want to take the conversation.

 Legoktm, the thing you could do to push it over the top is to write up
 a summary as you see it of the various positions, and post it to this
 list.  Ideally, you would also publish it as a subpage of the
 Architecture Summit 2014 page, similar to how some of the others are
 (e.g. HTML templating[1])  Even if we don't get to it at the summit,
 it still will be a very useful backgrounder to have.  Is that
 something you'd be willing to chip in with?

Sure, I created
https://www.mediawiki.org/wiki/Architecture_Summit_2014/Configuration,
and solicited feedback from ^demon and Yurik. I've included it below
for ease:

MediaWiki is currently configured via a series of global variables
that must be set in a PHP file by a user with file system access. This
cluster of RfCs intends to allow the wiki to be configured using an
on-wiki mechanism. Some of the motivations behind this can be found in
the first RfC[1].

The first two RfCs, Configuration database[2], and Configuration
database 2[3] discuss storing configuration parameters in a database
table, while Json Config pages in wiki[4] discusses using a JSON
ContentHandler to store configuration options in a wiki page.

Some of these features have already been implemented in extensions:
Configure provides basic on-wiki configuration functionality, and
CentralAuth allows custom global user groups to be created on-wiki.
The EventLogging, UploadWizard, and ZeroRatedMobileAccess extensions
all currently store configuration options in JSON formatted pages.

See also: bug 26992[5], Implement configuration database aka
configuration management aka no shell excuse (tracking)

[1] 
https://www.mediawiki.org/wiki/Requests_for_comment/Configuration_database#Problems_to_solve
[2] https://www.mediawiki.org/wiki/Requests_for_comment/Configuration_database
[3] https://www.mediawiki.org/wiki/Requests_for_comment/Configuration_database_2
[4] 
https://www.mediawiki.org/wiki/Requests_for_comment/Json_Config_pages_in_wiki
[5] https://bugzilla.wikimedia.org/show_bug.cgi?id=26992

-- Legoktm

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

Re: [Wikitech-l] Config class and 1.23

2014-04-18 Thread Legoktm

On 04/18/2014 04:40 AM, Kevin Israel wrote:

Should the Config and GlobalConfig classes and the associated
RequestContext methods be reverted from 1.23 as an incomplete feature?
As far as I can tell, it is not yet used anywhere, so reverting it
should be easy.


The implementation in core right now is incomplete. Once [3] is merged 
though, it should be suitable for people to start using it, and I know 
Reedy had a patch that converted all of the API modules in core to use it.


I would like to have Config make it into 1.23, mainly since it's an LTS, 
which would allow more extensions to take advantage of it without 
breaking backwards-compatability.


I was actually working on [3] last night and just updated the patchset, 
which should address the concerns the reviewers had. But if we're not 
able to get it merged in time for the 1.23 release, then I would 
recommend reverting the current implementation out of the release branch.



[3]: https://gerrit.wikimedia.org/r/#/c/109850/


-- Legoktm

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

Re: [Wikitech-l] bugs in #mediawiki

2014-04-25 Thread Legoktm

On 04/25/2014 09:10 PM, John wrote:

Looks the the wikibugs is having issues, and needs poked


The new wikibugs is now in #wikimedia-dev, and also in a few other channels.

-- Legoktm

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

Re: [Wikitech-l] Reducing botspam on #wikimedia-dev

2014-05-18 Thread Legoktm

On 5/18/14, 7:36 AM, Yuvi Panda wrote:

Hello everyone!

I just merged a change into the new wikibugs that will help reduce
botspam on #wikimedia-dev. wikibugs will no longer report bugs on
#wikimedia-dev that have been reported in other channels, thus
reducing duplication. The previous behavior was that wikibugs will
ping multiple channels - mobile bugs went to both #wikimedia-mobile
and #wikimedia-dev, flow bugs to both #wikimedia-corefeatures and
#wikimedia-dev, etc. Now they only go to the primary channel and
bypass -dev. So mobile bugs will only go to #wikimedia-mobile, and not
to #wikimedia-dev. This also matches the behavior of grrrit-wm.
For Flow/Echo/other -corefeatures projects, we send gerrit patches to 
both -dev and -corefeatures, so I think it would make sense for us to 
still have our bugs going to -dev (or we should change the behavior of 
grrrit-wm).


#mediawiki-feed still gets the full firehose of all changes, if you
are interested in that.

Thanks!


Thanks for doing this :)

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

Re: [Wikitech-l] Bot flags and human-made edits

2014-05-20 Thread Legoktm


On 5/19/14, 6:39 PM, Dan Garry wrote:

On 19 May 2014 19:36, Amir Ladsgroup ladsgr...@gmail.com wrote:


As a bot operator I think API parameter about flagging bot or not is
necessary


Sure, but as I'm not a bot operator, can you explain why and what you use
this for, to help me understand? :-)


If the edits should show up in users watchlists/recentchanges for humans 
to look at. An example would be ClueBot NG on enwp which doesn't flag 
it's edits with the bot flag so humans can review them.


Another case where this recently came up is in MassMessage (bug 65180). 
Some edits like those to user talk pages should be marked as a bot since 
the user will receive a notification regardless, but ones that are made 
to Project (or other) namespaces, should not be flagged as bot so users 
will see them in their watchlists.


-- Legoktm

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

[Wikitech-l] [RFC] Extension registration

2014-05-23 Thread Legoktm

Hi everyone,

I've written an RfC about changing the way extensions store metadata 
about themselves and also how we load them. It's at 
https://www.mediawiki.org/wiki/Requests_for_comment/Extension_registration.


A brief summary:

Extensions register a lot of things, like classes, hooks, special pages, 
configuration options, and plenty more. Currently all of these are 
usually stored in the extension's main entry point 
($IP/extensions/Foo/Foo.php).


This creates two problems. First, it's difficult to tell what an 
extension is going to register without actually enabling the extension. 
Second, registration currently depends on global state ($wgHooks, 
$wgSpecialPages, etc.) which we are trying to move away from.


My proposal is that we store this information in a JSON file (I've 
provided an example on the RfC), and have MediaWiki read them when 
loading extensions. We would no longer use the current method of 
require_once Foo.php;, but instead $wgEnableExtensions[] = 'foo';, and 
MediaWiki would take care of the rest.


Please leave any comments or thoughts you might have on the talk page.

Thanks,
-- Legoktm


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

Re: [Wikitech-l] Config class and 1.23

2014-05-23 Thread Legoktm


On 4/29/14, 1:56 PM, Sumana Harihareswara wrote:

Looks like we are still working on merging the Make abstract Config
class truly implementation-agnostic changeset.[0]

[0] https://gerrit.wikimedia.org/r/#/c/109850/


The patch currently has three +1's (including myself) and one -1; it's 
just waiting for someone to +2 it :)


-- Legoktm


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

Re: [Wikitech-l] MediaWiki 1.23 release postponed by one week

2014-05-27 Thread Legoktm

On 5/27/14, 7:02 AM, Markus Glaser wrote:

Hi everyone,

due to a blocking bug in the installer of the latest release candidate, MW 
1.23.0-rc.2, we decided to release another RC before the final version as soon 
as a patch is available and merged. This also means, the actual release of MW 
1.23.0 will be delayed by one week. New release date is Wednesday, June 4th.


Which bug specifically? I'm guessing it's bug 63677, but there are still 
a few other open ones with a target milestone of 1.23.


I admit I haven't been tracking the release progress very much, but it 
would have been nice if there had been an email to wikitech-l a week or 
so ago saying that there's still a blocker that needs 
help/patches/reviews; I (and probably other people) would have been 
willing to help out so we don't end up in the situation we're in right 
now where the patch is trivial but just needed people to look at it.


-- Legoktm

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

Re: [Wikitech-l] Process change: New contributors getting editbugs on Bugzilla

2014-05-29 Thread Legoktm

On 5/29/14, 11:57 AM, Mark Holmquist wrote:


Solution: We've made every editbugs user able to add editbugs to an account. 
I've documented the process here: 
https://www.mediawiki.org/wiki/Bugzilla#Why_can.27t_I_claim_a_bug_or_mark_it_resolved.3F


Does this only apply to every user who has editbugs right now, or will 
it also apply to those we give editbugs to in the future?



Thanks to Chad for the quick resolution on this, hopefully this will be a 
positive change overall.


Thank you for finally getting this done! :)

-- Legoktm

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

Re: [Wikitech-l] Config class and 1.23

2014-06-04 Thread Legoktm

On 5/23/14, 9:26 PM, Legoktm wrote:


On 4/29/14, 1:56 PM, Sumana Harihareswara wrote:

Looks like we are still working on merging the Make abstract Config
class truly implementation-agnostic changeset.[0]

[0] https://gerrit.wikimedia.org/r/#/c/109850/


The patch currently has three +1's (including myself) and one -1; it's
just waiting for someone to +2 it :)



Super-delayed update: Tyler merged the patch, and it was backported into 
1.23. Thanks to everyone who contributed during the 4 month journey of 
the patchset!


Now, we begin the fun part of migrating our code to use the new classes. 
Reedy has [1] open which switches all of core's API to use it, and I've 
submitted [2] for MassMessage.


I've also written up some basic documentation[3] about how to migrate to 
the new classes.


[1] https://gerrit.wikimedia.org/r/#/c/109271/
[2] https://gerrit.wikimedia.org/r/#/c/137216/
[3] https://www.mediawiki.org/wiki/Manual:Configuration_for_developers

-- Legoktm

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

Re: [Wikitech-l] [RFC] Extension registration

2014-06-04 Thread Legoktm
A few more updates about the RfC after the IRC meeting. In case you 
missed it, the logs are at [1].


== Extension locations ==
We agreed that we should require extensions to all be in the same 
directory, but that directory should be configurable. By default it will 
point to $IP/extensions.


== Setting default configuration values ==
In my initial proposal I had something like:
$wgEnabledExtensions[] = 'Math';
$wgMathSomeOption = 'bar';
$wgEnabledExtensions[] = 'SpamBlacklist';
My plan was when loading the extension.json file, MediaWiki would check 
if the config values are set, and if so, don't overwrite it with the 
defaults. However since we're using $GLOBALS as the configuration 
backend, this opens up a register_globals vulnerability.


What do people think of stopping caring about register_globals (while we 
still support 5.3) and being ok with isset($wgWhatever)? Chad was of the 
opinion that it's your own fault if you turn on register_globals. :P


A few other options were discussed in the meeting:
wfEnableExtension( 'Math' );
$wgMathSomeOption = 'bar';
Where the function sets the default globals, and then the user 
overwrites them. This won't work for when we want to store configuration 
in the database since extensions to be loaded are no longer in an array.


Another one was something like:
$wgEnabledExtensions += array( 'Math', 'SpamBlacklist' );
wfLoadExtensions(); // Loads all extensions and sets defaults
// All config values after function call
$wgMathSomeOption = 'bar';
I'm not a huge fan of this one since IMO MediaWiki should do the 
extension loading on its own, and not require the user to put a function 
call in their configuration.


== Schema ==
I've written a basic JSON schema for extension.json files and put it up 
at [2].


[1] 
https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-05-30
[2] 
https://www.mediawiki.org/wiki/Requests_for_comment/Extension_registration/Schema


-- Legoktm

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

Re: [Wikitech-l] [RFC] Extension registration

2014-06-04 Thread Legoktm

On 6/4/14, 1:42 AM, Adrian Lang wrote:

[…] IMO MediaWiki should do the extension
loading on its own, and not require the user to put a function call in their
configuration.


I'm not too sure about that one. I think having the code for something
installed without actually running it has its use cases. For example,
you find an issue with an extension but have no time to investigate it
right now. Having all extensions automatically loaded if they are
present would force you to uninstall the extension to disable it.



Sorry, I should have been more clear about this. I didn't mean 
autoloading in the sense of if the extension is present, MediaWiki will 
automatically enable it. What I meant was, that if your configuration has:

$wgEnabledExtensions[] = 'Math';

You shouldn't *also* have to write:
wfLoadExtensions();

Just the first alone should be necessary.

-- Legoktm

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

Re: [Wikitech-l] Second round of the MediaWiki Release Management RFP

2014-06-13 Thread Legoktm
On 5/27/14, 11:13 AM, Greg Grossmeier wrote:
 The deadline for proposals is June 13.

I only noticed this now, but [2] says there will be a !vote that ends
on June 15th. Is there a reason why there's only 2 days between the
proposal deadline and the voting closing?

 [2] 
 https://commons.wikimedia.org/wiki/File:MediaWiki_Release_Request_For_Proposals_2014.pdf

-- Legoktm

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

Re: [Wikitech-l] Mantle - coding sharing between Flow and MobileFrontend

2014-07-03 Thread Legoktm
On 7/3/14, 11:23 AM, Ryan Kaldari wrote:
 This whole thread seems a bit silly to me. We put stuff that should be in
 core into extensions all the time (for lots of different reasons). For
 example: WikiEditor, VisualEditor, Echo, MobileFrontend, JsonConfig, etc.

I'd say that most of those are mistakes, and should have been in core to
begin with. WikiEditor should be in core, Echo (once cleaned up and lots
of bugs fixed) should be in core, MobileFrontend should definitely be in
core (though, now we're separating skins from core, so maybe not). I
haven't looked at JsonConfig, but I think at the architecture summit
people were fine with having it in core?

VisualEditor is a different beast, and can't be in core due to its
dependency upon Parsoid. Once Parsoid replaces the PHP parser, I see no
reason it can't be in core too.

-- Legoktm

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

[Wikitech-l] Removing support for register_globals

2014-07-08 Thread Legoktm
Hi,

tl;dr: https://gerrit.wikimedia.org/r/144854 stops supporting
MediaWiki instances with register_globals enabled.

When PHP 5.3 was released, register_globals was officially deprecated,
and that was over 5 years ago[1]. It was then removed in PHP 5.4.

Since MediaWiki still supports 5.3, we've had a check at the top of
WebStart.php and in the installer to recommend disabling
register_globals if it's still enabled. When working with configuration
database-related things as well as general code review of extensions,
I've noticed code that does isset( $wgFoo ) in an unsafe manner. We
could fix those individual issues, but I think it would be easier to
just stop supporting installs that have register_globals enabled. It's 2014!

I've uploaded a patchset[2] that will disable any current installation
that has register_globals enabled. It also modifies the command-line
installer to prevent installation if it is enabled.

[1] http://www.php.net/manual/en/security.globals.php
[2] https://gerrit.wikimedia.org/r/144854

-- Legoktm

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

Re: [Wikitech-l] MediaWiki Release RFP Status Update

2014-07-11 Thread Legoktm
So, early next week has already passed, and a week after that too. :(
Any update on when you'll be making an announcement?

-- Legoktm

On 6/27/14, 4:49 PM, Greg Grossmeier wrote:
 Hello all,
 
 We're in negotiations with one of applicants for the MediaWiki release
 management RFP and will make the official announcement ASAP, likely
 early next week.
 
 Greg

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

Re: [Wikitech-l] Reviewing a couple of TorBlock patches

2014-07-23 Thread Legoktm
On 7/23/14, 4:56 AM, Quim Gil wrote:
 According to our algorithm (*), TorBlock currently has the worse track
 reviewing code contributions -- even after Tim gave a -1 to one of the
 three open patches last week (thanks!). There are two patches from Tyler
 that haven't received any feedback at all since August 2013.
 
 https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/extensions/TorBlock,n,z

I left comments on all the patches. The -1's are mainly due to rebasing
needed.

 Your help reviewing these patches is welcome.
 
 It is not surprising that this extension has no maintaner listed at
 https://www.mediawiki.org/wiki/Developers/Maintainers (someone suggested
 Tim in that table, he disagrees and edited accordingly).
 
 Also, maybe someone is interested in maintaining this extension? Only
 eleven patches submitted in the last 15 months.

Probably not since I don't really know that much about tor, but I'm
willing to review Tyler's patches if he's unable to find other people.

-- Legoktm

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

[Wikitech-l] ExtensionDistributor updates on mediawiki.org

2014-07-30 Thread Legoktm
Hi,

Tomorrow a major update[1] will be deployed for the ExtensionDistributor
extension on mediawiki.org. We will start fetching branch information
directly from Gerrit instead of relying on Github. Additionally,
tarballs will be served from extdist.wmflabs.org[2] instead of using Github.

There will be a few differences, namely that tarballs are only generated
every hour, instead of on the fly like Github did. These tarballs will
include submodules inside tarballs for extensions like VisualEditor (bug
44022[3]).

If you notice any issues or have any ideas for enhancements, please file
a bug in Bugzilla[4].

Additionally, I'd like to thank ^demon and YuviPanda for their help in
putting this service together.

-- Legoktm

[1] https://gerrit.wikimedia.org/r/#/c/149474/
[2] https://extdist.wmflabs.org/dist/
[3] https://bugzilla.wikimedia.org/show_bug.cgi?id=44022
[4]
https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensionscomponent=ExtensionDistributor

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

Re: [Wikitech-l] ExtensionDistributor updates on mediawiki.org

2014-07-31 Thread Legoktm
On 7/31/14, 10:34 AM, Jeroen De Dauw wrote:
 Hey,
 
 \o/
 
 Feature request 1: be able to download specific versions of extensions
 based on the tags their provide.

https://bugzilla.wikimedia.org/show_bug.cgi?id=68939

 
 Feature request 2: include dependencies defined in composer.json.
 

https://bugzilla.wikimedia.org/show_bug.cgi?id=68940

 Feature request 3: be able to specify a bunch of extensions to download and
 have a compat check be done (based on the package definitions), after which
 they are bundled together

Could you elaborate on this a bit? For which extensions would this be
useful?


-- Legoktm

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

Re: [Wikitech-l] [RFC] Extension registration

2014-07-31 Thread Legoktm
Sorry about the super super late reply.

On 6/4/14, 2:12 AM, Daniel Friesen wrote:
 On 2014-06-04, 1:29 AM, Legoktm wrote:
 A few more updates about the RfC after the IRC meeting. In case you
 missed it, the logs are at [1].

 == Extension locations ==
 We agreed that we should require extensions to all be in the same
 directory, but that directory should be configurable. By default it
 will point to $IP/extensions.
 I still do NOT like this idea.
 
 By all means there should be one directory for extensions that are
 managed by a web/cli installer and the method of loading extensions from
 that one directory should be simple even when we're still using a php
 settings file. But when someone is intentionally not using that and
 doing complex config then we shouldn't stop them from saying to load an
 extension from a specific directory.

Ok, I think that's reasonable.

 
 A few other options were discussed in the meeting:
 wfEnableExtension( 'Math' );
 $wgMathSomeOption = 'bar';
 Where the function sets the default globals, and then the user
 overwrites them. This won't work for when we want to store
 configuration in the database since extensions to be loaded are no
 longer in an array.
 I don't understand where you get this assertion, this should have no
 effect on whether we can or can't have config in the DB.
 
 A wfEnableExtension would do the exact same thing as
 $wgEnabledExtensions would do to load an extension, just earlier.

Now looking back, I'm not sure where I came up with that either. What
you said makes sense.

I'll work on updating the RfC with this and a few other things today.

-- Legoktm

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

Re: [Wikitech-l] ExtensionDistributor updates on mediawiki.org

2014-08-01 Thread Legoktm
On 7/31/14, 7:34 PM, MZMcBride wrote:
 I do wonder a little why extdist.wmflabs.org was chosen over (for example)
 https://releases.wikimedia.org/, though this is really a minor point.

Mainly because labs gives us extra flexibility with fetching arbitrary
git submodules and in the future, dependencies via composer. The entire
setup is puppetized however, so it should be feasible to move it into
production if we decide that we want to.

-- Legoktm

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

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

2014-08-07 Thread Legoktm
On 8/7/14, 10:58 AM, David Gerard wrote:
 but if you are a mobile developer using the REST API
 every day, you need some other term to specify api.php.
 
 Is api.php unsuitable for some reason?

I like api.php too, given that we refer to the old one as query.php.

-- Legoktm

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

Re: [Wikitech-l] Fine-tuning the Architecture RfC process

2014-08-08 Thread Legoktm
On 8/8/14, 12:14 PM, Quim Gil wrote:
 From now on, Architecture RfC related tasks are handled in a Phabricator
 project:
 
 http://fab.wmflabs.org/project/board/72/
 
 While the RfCs themselves will continue to be documented at
 https://www.mediawiki.org/wiki/Requests_for_comment , in Phabricator we
 will create tasks to reflect the RfCs that have actions pending and/or are
 ready to be reviewed. This should help everybody understanding quickly what
 is missing in an RfC to go through the process, and who is in charge to
 work on what.

Can we please not use Phabricator until it's an actual production
service? We still don't have IRC notifications, mailing lists,
documentation, etc. Most people don't even look at it because, well,
it's a test instance, not an actual thing people should be using.

I'm also reminded of Mark's comments in [1]: If a URL has wmflabs.org
in it...don't put anything, ANYTHING, important there.

Just use Bugzilla, most RfCs are already using it to track issues anyways.

-- Legoktm

[1] http://lists.wikimedia.org/pipermail/wikitech-l/2013-August/071442.html

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

Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you

2014-08-09 Thread Legoktm
On 8/9/14, 8:41 PM, Isarra Yos wrote:
 On 07/08/14 14:32, Bartosz Dziewoński wrote:
 This has just happened.

 The instructions MediaWiki will display should guide you through. Poke
 me on IRC if the email I send earlier and the instructions don't help :)

 
 Would it be possible to get the common directory out of core/skins/ as
 well? 

That's https://bugzilla.wikimedia.org/show_bug.cgi?id=69277.

-- Legoktm

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

[Wikitech-l] URGENT! Documentation is out of date!

2014-08-10 Thread Legoktm
In honor of bug 1's 10th birthday today, take the time to fix some out
of date documentation or write some missing ones :)

https://bugzilla.wikimedia.org/show_bug.cgi?id=1

-- Legoktm

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

[Wikitech-l] Global gadgets (was: Re: Superprotect user right, Comming to a wiki near you)

2014-08-11 Thread Legoktm
On 8/11/14, 5:11 PM, svetlana wrote:
 Why aren't they implementing a global repository for gadgets, modules,
 templates which is (IMHO) what the community needs first?

 We are.

 ​SUL finalisation (which is broadly a blocker to much of this work) is
 currently underway and should help make a lot of cross-cluster desired
 tools a great deal easier to build. This isn't the only piece of work, but
 it's been enough to discourage work on these areas for many years.

 At Wikimania, a number of staff and volunteer developers re-started work on
 a global repository for gadgets. I was part of initial discussions around a
 global repository for source references with structured data stored on
 Wikibase somehow, and similar considerations for Wikiquote and Wikisource.
 
 Where can I see any of that?

The tracking bug for global gadgets (aka Gadgets 2.0) is
https://bugzilla.wikimedia.org/show_bug.cgi?id=gadgets-2.0. If you
want to take a look at the work in gerrit,
https://gerrit.wikimedia.org/r/#/q/project:mediawiki/extensions/Gadgets+branch:RL2,n,z
shows the patches happening in the RL2 branch. We've also been making
some changes to core in the process.

-- Legoktm

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

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

2014-08-12 Thread Legoktm
On 8/10/14, 6:27 AM, Erik Moeller wrote:
 Hi folks,
 
 Admins are currently given broad leeway to customize the user 
 experience for all users, including addition of site-wide JS, CSS, 
 etc. These are important capabilities of the wiki that have been
 used for many clearly beneficial purposes. In the long run, we will
 want to apply a code review process to these changes as with any
 other deployed code, but for now the system works as it is and we
 have no intent to remove this capability.

Sorry, I strongly disagree that the current system works. Every so
often we discover that a wiki has been loading external resources in
site-wide JS for months. Local sysops might have no idea on what
they're doing, and just copy and paste what someone told them to do.
Edits like [1] make that terribly obvious.

I filed bug 69445[2] as a tracking bug to implement a sane code review
process for these pages. I don't imagine it will happen anytime soon,
but now seems like a good time to start discussion about it.

[1]
https://szl.wikipedia.org/w/index.php?title=MediaWiki%3ACommon.jsdiff=prevoldid=208782
[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=69445

-- Legoktm

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

[Wikitech-l] Configuration related things that happened at Wikimania

2014-08-13 Thread Legoktm
Hello!

This past week at the hackathon we got a lot of things done related to
configuration, thank you to everyone who contributed to discussions,
worked on patchsets, or did code review!

This is just a list of things I can remember, we did much more. Some of
these aren't directly related to configuration, but will make it easier
for people to use the Config classes, especially in extensions.
* Converted most of includes/specials/ to use Config interface instead
of globals - a bunch of patches
* A bunch of other misc. classes were converted to use Config instead of
globals - another bunch of patches
* API modules can now be registered with factory functions to allow for
dependency injection - https://gerrit.wikimedia.org/r/#/c/149183/
* Skins can now be registered with factory functions to allow for
dependency injection - https://gerrit.wikimedia.org/r/#/c/153060/
* Patch for SpecialPages to use a factory function was started -
https://gerrit.wikimedia.org/r/#/c/152755/
* Added a JSONContentHandler to core -
https://gerrit.wikimedia.org/r/#/c/152933/
* Discussed creating a MultiConfig class to handle fallback logic -
https://gerrit.wikimedia.org/r/153541 (WIP)
* Created a Configuration component in Bugzilla
* Created a tracking bug for converting things to use Config classes
instead of globals -
https://bugzilla.wikimedia.org/show_bug.cgi?id=config-obj

If you have time, code review would be appreciated:
https://gerrit.wikimedia.org/r/#/q/topic:conf+status:open,n,z!

Thanks,
-- Legoktm

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

Re: [Wikitech-l] Help in modifying Template:Extension to support user ratings

2014-08-18 Thread Legoktm
On 8/18/14, 8:47 AM, Chad wrote:
 On Mon, Aug 18, 2014 at 4:54 PM, Brad Jorsch (Anomie) bjor...@wikimedia.org
 wrote:

 Has it already been asked anywhere *whether* to make these ratings
 available on mediawiki.org? How useful is it really to know that
 Extension:ConfirmEdit scored 3 on some external website, especially
 without knowing that that 3 comes from a grand total of 1 person?


 Relevant: http://xkcd.com/1098/
 
 -Chad

Also: http://xkcd.com/937/

-- Legoktm

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

Re: [Wikitech-l] Help in modifying Template:Extension to support user ratings

2014-08-20 Thread Legoktm
On 8/20/14, 9:04 AM, Quim Gil wrote:
 In order to move forward, we can discuss at different levels:
 
 * At a general level, which should be the priorities for mediawiki.org's
 gallery of extensions? This will allow us to define more tasks and projects
 for potential developers. https://www.mediawiki.org/wiki/ExtensionGallery

At Wikimania, we had a good conversation and a proposal (that was
basically agreed upon by everyone in the room IIRC!) about creating a
gold standard for extensions, judging them based on their code
quality, compatibility with MediaWiki versions, tests, etc. I don't
remember the etherpad link unfortunately, but I assume someone has the
notes.

IMO, that would be way more useful to me than arbitrary user ratings.

-- Legoktm

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

Re: [Wikitech-l] Disabling JS support in additional browsers

2014-08-23 Thread Legoktm
On 8/23/14, 6:38 PM, svetlana wrote:
 [...]
 
 Are there changes affecting only JavaScript, or also CSS?
 
 CSS is another beast that needs effort to support in browsers properly.

Just JavaScript, as the subject line indicates :-)

-- Legoktm

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

Re: [Wikitech-l] build.wikimedia.org

2014-08-25 Thread Legoktm
On 8/25/14, 5:59 AM, Quim Gil wrote:
 (This is the project formerly known as Wikimedia Data  Developer Hub)
 
 [..]
 
 https://www.mediawiki.org/wiki/build.wikimedia.org

This is now at [[dev.wikimedia.org]]? That sounds like a much better
name than build, which I thought was going to be some CI automated
builds server from your email title :)

-- Legoktm

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

Re: [Wikitech-l] Pre-release announcement for MediaWiki releases 1.22.10 and 1.23.3

2014-08-26 Thread Legoktm
On 8/26/14, 5:10 PM, David Gerard wrote:
 So 1.19 is officially finished?

https://www.mediawiki.org/wiki/MediaWiki_1.19 says it will be
supported until May 2015. I think the reason there is no maintenance
release for it is because nothing has been backported since the last
security release:
https://gerrit.wikimedia.org/r/#/q/project:mediawiki/core+branch:REL1_19+status:merged,n,z.

-- Legoktm

 On 27 August 2014 01:02, Markus Glaser gla...@hallowelt.biz wrote:
 Hello everyone,

 this is a notice that on 27th August between 20:00-22:00 UTC we will release 
 maintenance updates for current and legacy branches of the MediaWiki 
 software. Downloads and patches will be available at that time.

 Best,
 Markus
 Wiki Release Team

 ___
 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] [Wikitech-ambassadors] Roadmap and deployment highlights - week of Sept 15th

2014-09-14 Thread Legoktm
On 9/12/14, 1:55 PM, Greg Grossmeier wrote:
 Hello and welcome to the latest edition of the WMF Engineering Roadmap
 and Deployment update.
 
 The full log of planned deployments next week can be found at:
 https://wikitech.wikimedia.org/wiki/Deployments#Week_of_September_15th
 
 A quick list of notable items...
 
 == Monday ==

On Monday we will also be removing the renameuser right from all
bureaucrats on SUL-linked wikis. See
https://meta.wikimedia.org/w/index.php?title=Wikimedia_Forumoldid=9811444#Change_in_renaming_process
for more details. The corresponding config change is
https://gerrit.wikimedia.org/r/#/c/160158/.

-- Kunal / Legoktm

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

Re: [Wikitech-l] Deployment highlights - week of April 8th

2013-04-06 Thread legoktm
 by local editors to address these
 variations.  Now we will have infoboxes with one version and the actual
 article saying something else - and the information in the infobox will be
 outside of the control of the editors of the article absent going to
 another site.  So now those wars about content will have to go to two sites
 at once, one of which will be international. So that means users who have
 never logged into Wikipedia will have the ability to control the content of
 the project.


So? You just set up the infobox to have a local override if the field is
filled in. Using this data is *optional*. If you want it, use it! If not,
it's there if you ever change your mind.



 Let's not put this in place until the community decides whether or not it
 wants it.


Hasn't the community been asking for interwiki transclusion for a while
now? Personally I just see this as the first step to that.


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



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

Re: [Wikitech-l] Socializing changes

2013-04-06 Thread legoktm
On Sat, Apr 6, 2013 at 10:28 AM, MZMcBride z...@mzmcbride.com wrote:

 Risker wrote:
 Lydia, could you please point me to the discussion on *English Wikipedia*
 where the community indicated an interest in deploying this software?
 Infoboxes and sourcing to another website completely outside the control
 of English Wikipedia is a rather big issue, and I would expect to see a
 Request for Comment with at least 200-300 participants.

 I think the issue we're seeing here is that changes, particularly large
 changes, often aren't socialized well.

 It probably doesn't help to target the English Wikipedia first, of course,
 given that it's often annoyingly exceptional. Wikidata seems like a large
 enough change that I agree that a bit more socialization might be nice.
 There are over 700 wikis on which to possibly deploy Wikidata, in theory.


Wikidata phase 2 is already live on 11 different wikis. (
http://blog.wikimedia.de/2013/03/27/you-can-have-all-the-data/)


 MZMcBride


 -- Legoktm
http://enwp.org/User: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] Proposal for Release Management RfP by Emufarmers, Isarra, Jack, and Legoktm

2013-06-13 Thread legoktm
Hi everyone,
On behalf of Emufarmers, Isarra, and Jack, I'd like to present our proposal
for the release management RfP:
https://www.mediawiki.org/wiki/Release_Management_RFP/EIJL

If you have any concerns or questions we're more than willing to answer
them via email or on the talk page.
Thanks,
-- Legoktm
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] REL1_24 branched in core

2014-09-19 Thread Legoktm
Hi,

I just merged https://gerrit.wikimedia.org/r/#/c/161584/ and branched
core to the commit before it. If someone could take care of branching
extensions that would be wonderful, otherwise I'll figure out how to do
that over the weekend.

Bugs tagged for 1.24 release:
https://bugzilla.wikimedia.org/buglist.cgi?action=wraplist_id=345619product=MediaWikiresolution=---target_milestone=1.24.0%20release,
some have open patches awaiting review!

-- Legoktm

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

Re: [Wikitech-l] Backing out REL1_24

2014-09-21 Thread Legoktm
Hi,

On 9/21/14, 1:42 PM, Mark A. Hershberger wrote:
 Dear Wikitech-l 
 
 REL1_24 was branched and announced ahead of schedule[0].
 
 Our schedule[1] clearly states that we will announce a branch one week
 before we make one in order to allow developers to put any necessary work
 into the branch and keep backports to a minimum.

Given that your schedule was only posted earlier today
(https://www.mediawiki.org/w/index.php?title=WikiReleaseTeam%2FRelease_timelinediff=1177036oldid=1135771),
I'm not sure how you expected anyone else to know about it. Normally we
switch over to the next alpha branch after the wmf22 branch is created.

 The current release is planned for 2014-11-26[2].  According to our
 schedule, the actual REL1_24 branch should be made on 2014-10-22.

This doesn't make much sense to me. Next week 1.25wmf1 is going to be
branched, meaning that master should be on 1.25alpha already. Waiting
until late October to branch means that won't happen. The bump to 1.24
(https://gerrit.wikimedia.org/r/#/c/125735/), it was done right after
1.23wmf22 was branched, so the same basic process was followed here give
or take a day.

-- Legoktm

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

Re: [Wikitech-l] Backing out REL1_24

2014-09-26 Thread Legoktm
On 9/22/14 1:10 PM, Mark A. Hershberger wrote:
 
 In deference to the concerns raised by James Forrester, Markus and I
 have decided not to back out the REL1_24 branch.

Will you be creating the REL1_24 branches for extensions and skins, or
would you like me to do that?

-- Legoktm

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

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

2014-10-01 Thread Legoktm
On 10/1/14 9:09 AM, John wrote:
 The abuse filter has no way of identifying TOR exit nodes, thus it cannot
 be used for this. Some developer will need to interface with the TOR
 blocking  code and use the same TOR identification methods to ID and label
 both logged in and logged out edits made via TOR.

The TorBlock extension already adds a tor_exit_node variable[1] to the
AbuseFilter, which is a simple boolean value whether the edit is being
made through tor or not.

[1]
https://github.com/wikimedia/mediawiki-extensions-TorBlock/blob/master/TorBlock.class.php#L129

-- Legoktm

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

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

2014-10-01 Thread Legoktm
On 10/1/14 8:02 AM, John wrote:
 Prior to TOR being enabled we need to be able to flag both logged in and
 logged out edits made via TOR.

There's a $wgTorTagChanges option which does exactly that, except it's
currently disabled in CommonSettings.php.

-- Legoktm

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

[Wikitech-l] Requiring PHP = 5.3.3 for MediaWiki core

2014-10-23 Thread Legoktm
Hi,

As part of the librarization project[1], we are planning on taking the
CSSJanus library that is currently in includes/lib/ and bringing it in
with composer. However, it requires PHP =5.3.3 in its composer.json[2].
Krinkle has stated[3] that is due to the fact that it has only been
tested on 5.3.3 and higher, and it's also what travis-ci provides.

After doing some research[4], it appears that we would be dropping
support for Ubuntu 10.04LTS, which has security support until April
2015. MediaWiki 1.25.0 is expected to be released in May 2015.

Does anyone have any objections to dropping 5.3.2 support? I've uploaded
[5] that actually increments the required version number.

Thanks,
-- Legoktm


[1] https://www.mediawiki.org/wiki/Library_infrastructure_for_MediaWiki
[2] https://github.com/cssjanus/php-cssjanus/blob/master/composer.json
[3] https://github.com/cssjanus/php-cssjanus/pull/5#issuecomment-60069126
[4] https://phabricator.wikimedia.org/T839#14160
[5] https://gerrit.wikimedia.org/r/168535


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

Re: [Wikitech-l] Requiring PHP = 5.3.3 for MediaWiki core

2014-10-23 Thread Legoktm
On 10/23/14 7:55 PM, MZMcBride wrote:
 Are there statistics about what versions of PHP exist in the wild among
 MediaWiki users or users of other large PHP applications (Drupal,
 WordPress, etc.)?

WordPress has some graphs at [1]. They have a minimum requirement of 5.2.4.

For Drupal I found [2], but it doesn't say which PHP version is being
used. Drupal 7 requires 5.2.5 (but recommends 5.3), and Drupal 8
requires 5.4.

-- Legoktm

[1] https://wordpress.org/about/stats/
[2] https://www.drupal.org/project/usage/drupal

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

Re: [Wikitech-l] BREAKING CHANGE: API help and pretty-printed output formatting changes

2014-10-26 Thread Legoktm
On 10/26/14 2:44 PM, Petr Bena wrote:
 Hi,
 
 at some point I miss that 1 huge page where I could find everything in
 3 seconds just by using ctrl+f, there should be a way to display it,
 or there should be at least some api for it :P 1 page documentations
 are sometimes better than docs split into zillions of html documents

If you scroll down a bit, there's a link that says All help in one
page and sends you to
https://www.mediawiki.org/w/api.php?action=helprecursivesubmodules=1.

-- Legoktm

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

Re: [Wikitech-l] Breaking change: \Psr\Log\LoggerInterface will be required by mediawiki/core

2014-10-29 Thread Legoktm
On 10/19/14 3:13 PM, Bryan Davis wrote:
 The structured logging implementation that I began work on in February
 has been making progress through code review recently following the
 completion of Jenkins and Zuul tooling changes which allow the test
 infrastructure to cope with the introduction of the mediawiki/vendor
 repository. The next patch in the series [0] will require that all
 consumers of MediaWiki from the git repository either use Composer
 directly or clone the mediawiki/vendor repository to provide the PSR-3
 [1] interfaces and abstract classes [2].

Now merged \o/

 For the WMF production cluster, the mediawiki/vendor repository [3] is
 being included as a submodule on the wmf/1.25wmfX deployment branches.
 This repository is also used on the *.beta.wmflabs.org and with the
 Jenkins tests. The MediaWiki-Vagrant project includes Puppet
 configuration that automates the installation of \Psr\Log with
 Composer as defined in the mediawiki/core/composer.json configuration
 file. Developers and other users of MediaWiki via git clone can pick
 one installation option or the other as they prefer.

tl;dr:

$ composer install

OR

$ git clone https://gerrit.wikimedia.org/r/p/mediawiki/vendor.git

-- Legoktm

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

Re: [Wikitech-l] rvtoken deprecated

2014-10-30 Thread Legoktm
On 10/30/14 2:11 AM, Petr Bena wrote:
 Hello,
 
 I am receiving lot of these warnings:
 
 WARNING: API query (revisions): The rvtoken parameter has been deprecated.
 
 According to current documentation for mediawiki at
 https://www.mediawiki.org/wiki/API:Rollback which I follow, in order
 to get a rvtoken I should use this query:
 
 https://en.wikipedia.org/w/api.php?action=queryprop=revisionsrvtoken=rollbacktitles=Main%20Pageformat=xml
 
 however that very query returns this warning. Is this a bug in
 documentation? 

Yes, the documentation is out of date. See bug 1.

 Why do you first deprecate things and then, ages later,
 update the docs? Shouldn't it be the other way? Mediawiki has worst
 backward compatibility support I have ever seen and this is one of the
 reasons for it.

The docs on mediawiki.org are manually maintained. We're currently
working towards automated docs that will stay up to date with the code,
[1] says exactly which token type you need and from where.

AFAIS, the deprecated method still works fine. How is
backwards-compatability support not here?

Also, are you subscribed to the mediawiki-api-announce mailing list[2]?
It's useful if you want to be aware of what changes are
planned/happening for the API. For example, the tokens change was
announced[3] back in August.

-- Legoktm

[1] https://www.mediawiki.org/w/api.php?modules=rollback
[2] https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
[3]
https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2014-August/67.html

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

[Wikitech-l] CSSJanus now included in core through composer

2014-11-05 Thread Legoktm
Hi,

CSSJanus is now[1] included in MediaWiki core through composer, and
maintained as an external library on Github[2].

Running composer update will download and autoload the library, or if
you're using the mediawiki/vendor repository a simple git pull will work.

-- Legoktm

[1] https://gerrit.wikimedia.org/r/170107
[2] https://github.com/cssjanus/php-cssjanus

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

Re: [Wikitech-l] MediaWiki:Common.js and MediaWiki:Common.css blocked on Special:Login and Special:Preferences

2014-11-06 Thread Legoktm
On 11/6/14 6:58 AM, Mark A. Hershberger wrote:
 
 TL;DR: Should we merge https://gerrit.wikimedia.org/r/#/c/165979/ and
 release it with MediaWiki 1.24?
 
 A lot of sites have used MediaWiki:Common.js and MediaWiki:Common.css to
 customize the appearance of their site.
 
 In a recent security release[1], support for JS and CSS with on-wiki
 origins was removed from being displayed on the Special:Login and
 Special:Preferences page.

To be clear, only CSS was removed. JS was already not allowed on
Special:Login/Preferences.

 Because of how the on-wiki MediaWiki:Common.* pages are used and the
 access restrictions on them, I think it is reasonable to allow JS and
 CSS from them while continuing to disallow individual's JS and CSS on
 the Special:Preferences and Special:Login page.
 
 Alexia filed a bug[2] and Kunal (Legoktm) has provided a patch[3] to allow
 site-wide styling back on those pages.

Right, the patch only re-adds site-wide CSS, not JS.

-- Legoktm

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

Re: [Wikitech-l] MediaWiki:Common.js and MediaWiki:Common.css blocked on Special:Login and Special:Preferences

2014-11-07 Thread Legoktm
On 11/6/14 4:45 PM, Chris Steipp wrote:
 For me, I like knowing that when I login on a random wiki in our
 cluster, a site admin can't have (maliciously or unintentionally) put
 javascript on the login page to sniff my password. I'd prefer Kunal's
 patch had a feature flag so we could disable this on WMF wikis, but
 sites with robust auditing of their common.css can enable it.

I've amended https://gerrit.wikimedia.org/r/#/c/165979/3 to be
controlled by a config setting.

-- Legoktm

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

[Wikitech-l] composer validate now running for all extensions and skins

2014-11-17 Thread Legoktm
Hi!

With some help from bd808 and hashar, all extensions and skins now[1]
have a php-composer-validate job, which will run composer
validate[2] if your extension/skin's composer.json file is edited.

Some extensions are still not passing validation, so I've uploaded[3]
some changes to make them all validate. Reviews appreciated :)

-- Legoktm

[1] https://gerrit.wikimedia.org/r/#/c/173457/
[2] https://getcomposer.org/doc/03-cli.md#validate
[3]
https://gerrit.wikimedia.org/r/#/q/status:open+topic:composer-validate,n,z

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

Re: [Wikitech-l] Final RC for 1.24

2014-11-24 Thread Legoktm
On 11/24/14 7:13 PM, Mark A. Hershberger wrote:
 == Changes since 1.24.0-rc.2 ==
 * The composer.json file has been renamed to composer.json.sample after
   Jamie Thingelstad reported that his composer.json was overwritten by
   the tarball.

Is there an associated bug report? We decided to revert a similar move
in core and this goes against the consensus in code review and the
wikitech discussions that were held months ago (back in May!), so I
strongly recommend reverting this.

First off, this change[1] was done outside of git meaning there was no
opportunity for code review and no possibility of a revert.

Adding a composer.json to MediaWiki has been intentionally done (see
Ori's extremely long rationale on [2]) so MediaWiki can properly depend
on external libraries like phpunit, and a bunch more starting with the
1.25 development cycle.

This has been previously discussed on this list (see [3] and [4])
explaining why we chose to have a composer.json in core. Maybe we need
better release notes documenting this switch since 1.23.

I'm frustrated at why this is coming in at the last minute and done in a
seemingly secret manner especially after there have been so many
discussions about this that the release team themselves were involved in.

-- Legoktm

[1] https://gerrit.wikimedia.org/r/#/c/175453/
[2] https://gerrit.wikimedia.org/r/#/c/132788/
[3]
https://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg76217.html
[4]
https://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg76250.html

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

[Wikitech-l] Skin tarballs now downloadable from mediawiki.org

2014-11-24 Thread Legoktm
Hi!

There is now a Special:SkinDistributor[1] on mediawiki.org that will
allow you to download tarballs of skins that are hosted on gerrit. Since
skins have moved out of the core repository and handled like extensions
as of 1.24, it's now possible to provide an easier way to download them.

In addition, I discovered that the tarball generator (for both
extensions and skins) was including .git subdirectories in the tarballs
it was creating, causing extremely large tarballs depending on the
history. It no longer does that[2], shrinking tarballs by over 100MB in
some cases!

Thanks to Chad and Yuvi for helping with code review and the deployment!

-- Legoktm

[1] https://www.mediawiki.org/wiki/Special:SkinDistributor
[2] https://gerrit.wikimedia.org/r/#/c/174777/


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

Re: [Wikitech-l] Phabricator migration part II: Replacing gitblit with Diffusion

2014-11-29 Thread Legoktm
On the talk page I suggested dropping the G prefix for top-level
repos, and just giving them an unprefixed callsign. I think that would
fix the ugliness of some of the frequently used names.

 On Sat, 29 Nov 2014 17:51:11 +0100, Chad innocentkil...@gmail.com wrote:

  The only exception I'd make is MediaWiki. Under this
 scheme the callsign is MWMW. MediaWiki should be
 just plain MW.

If we rename mediawiki/core to just mediawiki it becomes a top-level
repo and can just be MW.

 On 29 November 2014 at 09:13, Bartosz Dziewoński matma@gmail.com
 wrote:
 Feels slippery. Next thing you know, someone will want VE and SMW. :)

If the VisualEditor/VisualEditor repo becomes VisualEditor I don't
see anything against naming it VE.

On 11/29/14 9:26 AM, James Forrester wrote:
 ​When we have VE-WordPress and VE-Drupal and VE-​Joomla and whatever, we'll
 put them as… GVEW, GVED, GVEJ *etc.* and just hope we never have a first
 character clash on integrations?

I think we would set up VE as a prefix rather than dumping them under
general, so: VEWP, VEDP, VEJM (or whatever).

-- Legoktm

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

Re: [Wikitech-l] Investigating building an apps content service using RESTBase and Node.js

2015-02-03 Thread Legoktm


On 02/03/2015 05:46 PM, Dan Garry wrote:
 *tl;dr: Mobile Apps will, in partnership with the Services, investigate
 building a content service for the Mobile Apps.*
 
 The Mobile Apps Team currently has quite a few pain points with the way we
 fetch article content currently:
 
- We have to make a lot of API requests to load an article: article
HTML, lead image, read more recommendations, and more

Is there a bug for this and the other issues? I'm subscribed to [1], but
I don't see anything like the issues you've mentioned on it.

What are read more recommendations?

- We send the user HTML that we then discard, needlessly increasing data
usage
- We do transforms to the HTML in JavaScript on the client side, which
causes code duplication across the apps and degrades user-perceived
performance
- Trivial changes to the API (e.g. renaming a parameter) can break the
app which is problematic since apps can't be hotfixed easily

Is there an actual instance where an API change has broken an app or is
this merely a hypothetical concern? Speaking as an API developer, we
occasionally have to make breaking changes, and if we broke something
too fast, it would be nice to have feedback if that was the case so we
can improve in the future.

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

-- Legoktm

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

[Wikitech-l] Global user pages deployed to test wikis

2015-02-05 Thread Legoktm
Hello!

Earlier today the GlobalUserPage extension was deployed to
test.wikipedia.org, test2.wikipedia.org, and test.wikidata.org.
GlobalUserPage transcludes the contents of your userpage on other
public Wikimedia wikis if a local user page does not exist.

For example, my userpage on test.wikidata.org[1] is displaying the
content from test.wikipedia.org[2]. During the test phase,
test.wikipedia.org is the central wiki. When we deploy the extension to
all wikis, Meta will become the central wiki (and existing global user
pages on test.wikipedia.org will not be migrated).

Documentation about the various features can be found on
mediawiki.org[3]. Please test the extension and if you find any bugs or
issues, they can be reported in Phabricator[4]. You can also subscribe
to [5] to track the full deployment of GlobalUserPage.

[1] https://test.wikidata.org/wiki/User:Legoktm
[2] https://test.wikipedia.org/wiki/User:Legoktm
[3] https://www.mediawiki.org/wiki/Help:Extension:GlobalUserPage
[4]
https://phabricator.wikimedia.org/maniphest/task/create/?projects=PHID-PROJ-j536clyie42uptgjkft7
[5] https://phabricator.wikimedia.org/T72576

Thanks,
-- Legoktm

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

Re: [Wikitech-l] Naming conventions for data centers

2015-02-05 Thread Legoktm
On 02/05/2015 04:51 PM, Pine W wrote:
 What is the naming convention for these data centers?

https://wikitech.wikimedia.org/wiki/Infrastructure_naming_conventions#Datacenter_Sites

-- Legoktm

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

Re: [Wikitech-l] Fun with code coverage

2015-01-15 Thread Legoktm
On 01/14/2015 04:57 PM, James Douglas wrote:
 I'd love to hear your thoughts and learn about your related experiences.
 What are your favorite code coverage tools and services?

PHPUnit has a useful code coverage tool and there are reports running
for core[1] and some extensions[2]. In my experience it's extremely CPU
intensive and slow, so it's not something that is convenient to run
before every commit.

[1] https://integration.wikimedia.org/cover/mediawiki-core/master/php/
[2] https://tools.wmflabs.org/coverage/

-- Legoktm

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

Re: [Wikitech-l] Working around composer? (Fatal error: Class 'Cdb\Reader' not found)

2015-01-16 Thread Legoktm
On 01/13/2015 09:08 AM, Bryan Davis wrote:
 On Tue, Jan 13, 2015 at 7:40 AM, Tyler Romeo tylerro...@gmail.com wrote:
 I know we just added some new maintenance scripts for checking things with 
 composer. I’m sure it wouldn’t be that bad having update.php check first and 
 tell the user to run “composer install” before doing update.php.
 
 
 Kunal made the new checkComposerLockUpToDate.php maintenance script
 to validate $IP/vendor against the $IP/composer.json file. An end user
 could either add this to their typical workflow before running
 update.php or we could try to find a reasonable way to integrate the
 check it performs into the update script. Checking for external
 dependencies isn't the same thing at all as updating a database schema
 so I'd lean towards suggesting that the new script be used separately.

I tried getting update.php to run checkComposerLockUpToDate.php but it
was messy and didn't really work well, so I uploaded a patch[1] that
adjusts the intro text to recommend that you run
checkComposerLockUpToDate.php before running update.php.

[1] https://gerrit.wikimedia.org/r/#/c/185592/

-- Legoktm

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

[Wikitech-l] +2 for TTO in mediawiki/

2015-01-16 Thread Legoktm
Hi!

I have nominated TTO for +2 in mediawiki/ repositories:
https://www.mediawiki.org/wiki/Gerrit/Project_ownership#TTO_for_.2B2_in_mediawiki.2F.
Please comment :)

Additionally, there are some other requests on that page that could use
some comments.

Thanks,
-- Legoktm

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

Re: [Wikitech-l] wfRunHooks deprecation

2015-01-22 Thread Legoktm


On 01/21/2015 09:39 AM, Jeroen De Dauw wrote:
 Hey,
 
 Does the new syntax offer any advantage over the old one?

It's a little bit faster by cutting down one function call which adds up
when a lot of hooks are called.

-- Legoktm

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

Re: [Wikitech-l] Congratulations to MediaWiki Farmers User Group for being approved as a Wikimedia User Group

2015-01-20 Thread Legoktm
On 01/17/2015 03:54 PM, Gregory Varnum wrote:
 Greetings,
 
 Please join the Affiliations Committee in congratulating the MediaWiki
 Farmers User Group on their official approval as a Wikimedia User Group:
 https://meta.wikimedia.org/wiki/Affiliations_Committee/Resolutions/MediaWiki_Farmers_User_Group_-_Liaison_approval,_January_2015

Thank you for all your help in the process!

 The MediaWiki Farmers User Group is A user group of third-party developers
 who work on wiki farms. Our mission is to improve and standardize the way
 MediaWiki wiki farms are setup and run.
 
 Anyone interested in more information about the group can visit:
 https://www.mediawiki.org/wiki/Project:MediaWiki_Farmers_user_group

We will be having our first meeting[1] at the developer summit, and will
post meeting minutes on-wiki for those who aren't able to attend.
We'll also have an IRC meeting sometime after the summit, specifics
still to be determined.

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

-- Legoktm

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

Re: [Wikitech-l] Adopting Composer's composer.json for extensions

2015-02-16 Thread Legoktm

On 02/16/2015 09:34 AM, Mark A. Hershberger wrote:


I've opened a task on Phabricator[1] to attempt to merge the information
in extension.json with Composer's
already-used-by-several-extensions-and-skins composer.json.


Can we please centralize this discussion? We're discussing this on-wiki, 
and now it's spread to Phabricator and wikitech-l.



Kunal has rightly pointed out that composer doesn't fit some use-cases
for MediaWiki.  I see that as an opportunity to be good citizens in the
larger developer community by working to integrate MediaWiki into the
growing ecosystem available on packagist.org.

For example, if composer had been available, we might not have had to
develop our own HTTP client.


I don't buy this argument. If there had been code available for us to 
use and there was an advantage to using it instead of writing our own, 
we probably would have just copied it into core like we have done with 
other PHP code in includes/libs/. But this has already been discussed 
before[1].



If composer had been available, Brion could have released the work under
includes/normal as its own package.  As he says in the README there:

 This directory contains some Unicode normalization routines. These
 routines are meant to be reusable in other projects, so I'm not
 tying them to the MediaWiki utility functions.


There's nothing stopping us from doing that now. I've moved the code to 
includes/libs/normal, so it shouldn't be too difficult.[2]


[1] 
https://www.mediawiki.org/wiki/Requests_for_comment/Third-party_components

[2] https://phabricator.wikimedia.org/T88485

-- Legoktm

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

Re: [Wikitech-l] Working around composer? (Fatal error: Class 'Cdb\Reader' not found)

2015-01-24 Thread Legoktm
On 01/16/2015 05:52 PM, Legoktm wrote:
 I tried getting update.php to run checkComposerLockUpToDate.php but it
 was messy and didn't really work well, so I uploaded a patch[1] that
 adjusts the intro text to recommend that you run
 checkComposerLockUpToDate.php before running update.php.
 
 [1] https://gerrit.wikimedia.org/r/#/c/185592/

Turns out that running maintenance scripts inside each other is actually
pretty simple (Maintenance::runChild()) so I changed my patch to have
update.php run checkComposerLockUpToDate.php before starting the upgrade
process, and it has been merged.

-- Legoktm

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

[Wikitech-l] Sane versioning for core (was: Re: Fwd: No more Architecture Committee?)

2015-01-25 Thread Legoktm
On 01/15/2015 08:26 PM, Chad wrote:
 I've been saying for over a year now we should just drop the 1. from
 the 1.x.y release versions. So the next release would be 25.0, 26.0,
 etc etc.
 

+1, let's do this. It would allow us to follow semver and still retain
our current version number history instead of waiting for a magical 2.0.

-- Legoktm

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

Re: [Wikitech-l] Changing contentmodel of pages

2015-01-22 Thread Legoktm
Hi,

On 01/09/2015 04:25 PM, Erik Bernhardson wrote:
 However, changing the content model of an existing page is a disruptive
 change. We added the right `editcontentmodel` without which attempts to
 change content model through the API or EditPage.php fail. Currently no
 group (user or bot) has this right. So we think it's OK and safe to enable
 $wgContentHandlerUseDB on WMF wikis.
 https://gerrit.wikimedia.org/r/#/c/170129/ is the patch.

I think this is fine to turn on as well.

 There are issues with granting the editcontentmodel right, see T85847.

I disagree that we need a editcontentmodel user right. I think all
users should be allowed to change the content model of a page (provided
they have the right to edit it, etc.). Changing the content model of a
page is currently disruptive because the only way to do it (and undo it)
is via the API[1], and normal tools like undo don't work[2]. For now I'd
suggest we grant it to syops and then later on grant it to '*' by default.

 Daniel Kinzler proposed that we should not grant the editcontentmodel right
 because any change to content model is a special case that requires smart
 handling via dedicated PHP code. Which is what Flow is doing for both the
 Co-op bot and the future Special:Flowify.

That might make sense for changing the content model of an existing
page, but I don't think it applies for when we want to create a new page
with a content model different from the default. For example, in the
MassMessage extension we let people create pages with the
MassMessageListContent type wherever they want. It's not set as a
default anywhere meaning that you currently need the editcontentmodel
right to just create a list. :/

[1] https://phabricator.wikimedia.org/T72592
[2] https://phabricator.wikimedia.org/T73163

-- Legoktm

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

[Wikitech-l] Extension registration next steps

2015-01-08 Thread Legoktm
Hi!

Tim merged my patch[1] which implements the extension registration RfC[2].
For extensions (and skins!) to use this they need to be converted to
have extension.json (or skin.json) files. A maintenance script,
convertExtensionToRegistration.php, has been written to do this, but
there may be some edge cases that need some manual tweaking.

How should we go about migrating extensions? I've come up with a few
different ideas:

1. Package the extension registration code into an extension which can
be used by people who want to run newer copies of extensions on old
MediaWiki versions. We would then convert extensions to the
extension.json format and remove the PHP entry points.
2. Similar to #1, but package the extension registration code in each
individual extension, like was done with the i18n migration. I don't
really like this idea because a change to the code requires updating
every single extension.
3. Convert all extensions to extension.json, but continue to maintain
PHP entry points with duplicated information if the extension wants to
maintain old compatibility.

I'm personally leading towards option #1. Thoughts?

Once we have a migration plan decided, I'll start working on updating
documentation and other fun stuff.

[1] https://gerrit.wikimedia.org/r/#/c/166705/
[2]
https://www.mediawiki.org/wiki/Requests_for_comment/Extension_registration

Thanks,
-- Legoktm


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

Re: [Wikitech-l] Boil the ocean, be silly, throw the baby out with bathwater, demolish silos, have fun

2015-02-13 Thread Legoktm
On 02/13/2015 02:14 PM, Max Semenik wrote:
 Sorry for all the trolling, but why instead of discussing how we need a
 responsive skin for MediaWiki and waiting for Winter to come don't we just
 do it:
 * Move Minerva out of MobileFrontend

https://phabricator.wikimedia.org/T71366

-- Legoktm

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

[Wikitech-l] Global user pages deployed to all wikis

2015-02-18 Thread Legoktm

Hello!

Global user pages have now been deployed to all public wikis for users 
with CentralAuth accounts. Documentation on the feature is available at 
mediawiki.org[1], and if you notice any bugs please file them in 
Phabricator[2].


Thanks to all the people who helped with the creation and deployment 
(incomplete, and in no particular order): Jack Phoenix  ShoutWiki, 
Isarra, MZMcBride, Nemo, Quiddity, Aaron S, Matt F, James F, and 
everyone who helped with testing it while it was in beta.


[1] https://www.mediawiki.org/wiki/Help:Extension:GlobalUserPage
[2] 
https://phabricator.wikimedia.org/maniphest/task/create/?projects=PHID-PROJ-j536clyie42uptgjkft7



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

[Wikitech-l] [RfC] AuthManager

2015-02-27 Thread Legoktm
Hi!

Anomie, bd808, CSteipp, and myself have been working on updating Tyler's
previous AuthStack RfC:
https://www.mediawiki.org/wiki/Requests_for_comment/AuthManager.

Our goal is to build an authentication system that is flexible enough to
support the variety of usecases that MW currently supports and those it
should support in the future, without requiring tons of hooks or ugly hacks.

Please leave comments and feedback on the talk page :)

Thanks!
-- Legoktm

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

Re: [Wikitech-l] RFC meeting this week

2015-03-04 Thread Legoktm
Hi,

On 03/04/2015 10:55 AM, Scott MacLeod wrote:
 Tim:
 
 Can I please ask a general question about AuthManager and ContentHandler,
 since I'm a little unfamiliar with them, and in terms of Wikipedia's 288
 languages? How do these work inter-lingually? And in what ways are -
 https://www.mediawiki.org/wiki/Requests_for_comment/AuthManager - and -
 https://phabricator.wikimedia.org/T89733 - anticipating adding additional
 languages? Thanks.

AuthManager is mainly an internal backend refactor that has nothing to
do with language support.

-- Legoktm

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

Re: [Wikitech-l] ignoring composer.lock

2015-02-23 Thread Legoktm

On 02/23/2015 08:34 AM, Amir E. Aharoni wrote:

Hi,

Should composer.lock be added to .gitignore?


IMO yes. I had removed it from some extensions in the past IIRC.


It may be different for different extensions. In ContentTranslation we
currently only have:
require: {
 php: =5.3.0,
 composer/installers: =1.0.1
},

I don't know much about Composer, but it looks like nothing more than the
bare minimum. Should composer.lock be version-controlled in such a
situation?


If you are using composer to install extensions, I would say yes, it 
should be ignored. In that case the extension is basically a library, 
and composer will just ignore the lock file when installing, so it ends 
up being misleading[1].


If you are using composer to manage development dependencies like phpcs 
or phpunit, then maybe, though I personally would prefer to ignore it.


[1] https://getcomposer.org/doc/02-libraries.md#lock-file

-- Legoktm

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

Re: [Wikitech-l] Changing contentmodel of pages

2015-01-24 Thread Legoktm
On 01/24/2015 07:52 AM, Chris Steipp wrote:
 From a security perspective, I like limiting the content models per
 namespace to a relatively small whitelist. I think it will give more
 flexibility to anyone coming up with new content type definitions if we
 don't have to worry about what happen if someone changes main page to this
 format or how do i write a lossless conversion script from a flow page
 and back, just in case an admin converts a flow page to my new type and
 back.

This can already by done by overriding ContentHandler::canBeUsedOn() in
individual content handlers.

-- Legoktm

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

[Wikitech-l] [RfC] Improving extension dependency management and versioning

2015-01-25 Thread Legoktm
Hi!

I've written up an RfC[1] discussing the pain points for managing
extensions and suggestions on how to improve it.

Comments and feedback appreciated!

[1]
https://www.mediawiki.org/wiki/Requests_for_comment/Improving_extension_management

-- Legoktm

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

Re: [Wikitech-l] Sane versioning for core

2015-01-25 Thread Legoktm
On 01/25/2015 06:04 PM, Zack Weinberg wrote:
 On Sun, Jan 25, 2015 at 1:27 PM, Legoktm legoktm.wikipe...@gmail.com wrote:
 On 01/15/2015 08:26 PM, Chad wrote:
 I've been saying for over a year now we should just drop the 1. from
 the 1.x.y release versions. So the next release would be 25.0, 26.0,
 etc etc.
 
 -1 from me, for what little that's worth...
 
 It would allow us to follow semver and still retain
 our current version number history instead of waiting for a magical 2.0.
 
 This logic is the opposite of semver.  Semver says you only bump the
 major version number when you make a breaking change.  Since breaking
 changes are Bad Things, therefore bumping the major version number is
 also a Bad Thing.  It is something that you should strive to *avoid*
 having to do.

Except that every 1.x release *does* contain breaking changes. If we
followed semver we would be bumping the major version, but we don't.

-- Legoktm

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

[Wikitech-l] Has your extension been updated to support UserMerge?

2015-04-30 Thread Legoktm
Hi,

We're planning on deploying a global user merge tool to Wikimedia sites
shortly. As the name suggests, it merges multiple users into one.

This means that if your extension is storing user ids or user names, it
will need to listen to one of the UserMerge hooks
(UserMergeAccountFields, MergeAccountFromTo,
UserMergeAccountDeleteTables, or DeleteAccount) to make sure it isn't
referring to non-existent users. Reedy  I previously did an audit last
November of all deployed extensions, however new ones have been deployed
since then. Please check your extension(s) and if they need updating,
file bugs that block T49918[1] and T69758[2].

[1] https://phabricator.wikimedia.org/T49918
[2] https://phabricator.wikimedia.org/T69758

-- Legoktm

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

[Wikitech-l] Conpherence enabled? (was [Wikitech-ambassadors] Tech newsletter (2015, week 19))

2015-05-05 Thread Legoktm
On 05/04/2015 08:07 AM, Guillaume Paumier wrote:
   * You can now chat with other users
 https://www.mediawiki.org/wiki/Conpherence in Phabricator. [1]
 https://phabricator.wikimedia.org/T91392

Uh, why? Where was this actually discussed with more than 4 people? We
already have IRC and mailing lists, so why do we need yet another
communication system? Are we going to be enabling Phriction next?

Please turn it off.

-- Legoktm

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

Re: [Wikitech-l] RFC meeting this week

2015-05-14 Thread Legoktm
On 05/13/2015 04:11 PM, Matthew Flaschen wrote:

Thanks for sending out this summary Matt.

 1. A way for the extension to specify which version(s) of MediaWiki core
 it worked with.
 
 This was the focus of the majority of meeting.  Basically, this would
 let an extension specify that a given commit (and thus, a given branch)
 worked with particular versions of core, using syntax like:
 
 supports: 1.231.26
 
 Any syntax that Composer supports will work on the right.
 
 There was a lot of support with this, with some desire for better
 communication, socialization, and documentation, and some debate over
 the key name.  However, this was not unanimous.  Outcome of this was
 just submit a patch for it and we can continue the discussion in gerrit.

Mostly working patch is https://gerrit.wikimedia.org/r/#/c/210856/.
I've implemented it using supports for now, but I'm open to other
names. Some that were suggested in meeting were:
* 'supports' (my initial idea)
* 'supports-core'
* depends: {mediawiki-core:...}

 2. Tardist.  Details at
 https://www.mediawiki.org/wiki/Extension:ExtensionDistributor/tardist .
  There wasn't much discussion of this, but some support based on having
 read it.

It would be nice if we could have another meeting to discuss this. Or
maybe it should be on hold until we figure out part 1 first?

 There was also some big-picture debate on whether we should be
 implementing a packaging/dependency system and various concerns:
 
 1. Can we use Composer unmodified, whereas the current proposal/already
 implemented decisions is to use Composer for libraries, and build our
 extension system on top of it?

We've already decided to use composer for library management, and it
really doesn't make sense to revisit that decision. If people want to,
it should be a separate matter.

In my RfC I discussed and explained why extension are not libraries, and
why using composer directly didn't make sense. I'm not sure if people
didn't read that section or what.

 2. Should we instead use (or auto-generate) something like Debian
 packages, even if we don't actually try to get it into Debian proper.
 This means having our own Debian repo.  People pointed out that to even
 start getting serious about this we have to at least package latest
 MediaWiki and provide it in a public repo.  We haven't done this so far,
 and the latest MW in even Debian unstable is 1.19.20+dfsg-2.3 (latest
 release is 1.24, 1.25 coming out Real Soon Now).

I'm excited that other people are interested in working on this, but it
seems a bit weird to block implementing wfUseMW in extension.json over
some magical Debian extension system. If people want to create and
implement that, please, write your own RfC!

 3. In general, has enough research been done on the existing packaging
 and dependency ecosystem to see if we can leverage an existing system?

This was probably the most frustrating part of the entire meeting. If
people want to research debs/rpm/docker/etc. that's great, but we
already had consensus in the last meeting to build our own system on top
of composer classes, so I felt like we wasted a lot of time just
re-hashing that.

-- Legoktm

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

Re: [Wikitech-l] old-bugzilla.wikimedia.org to be switched off in favor of static-bugzilla

2015-06-08 Thread Legoktm
Hi,

On 06/08/2015 08:13 AM, Andre Klapper wrote:
 Now after everybody had more than six months to switch to Phabricator,
 old-bugzilla.wikimedia.org is planned to get switched off on June 22nd
 [3] (as keeping Bugzilla running requires maintenance like applying
 security updates).

Do we have usage statistics on how many people are still using
old-bugzilla? I still use it frequently for searching for example.

Will old-bugzilla redirect to static-bugzilla?

-- Legoktm

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

[Wikitech-l] MediaWiki-Codesniffer 0.2.0 released

2015-06-02 Thread Legoktm
Hello!

MediaWiki-Codesniffer 0.2.0 is now available for use in your MediaWiki
extensions and other projects. Here are the changes since the last
release (0.1.0):

* Fixed sniff that checks globals have a wg prefix (Divya)
* New sniff to detect unused global variables (Divya)
* New sniff to detect text before first opening php tag (Sumit Asthana)
* New sniff to detect alternative syntax such as endif (Vivek Ghaisas)
* New sniff to detect unprefixed global functions (Vivek Ghaisas)
* New sniff to detect goto usage (Harshit Harchani)
* Update ignore with some emacs files. (Mark A. Hershberger)
* Use upstream codesniffer 2.3.0 (Kunal Mehta)
* Make mediawiki/tools/codesniffer pass phpcs (Vivek Ghaisas)
* New sniff to check for spacey use of parentheses (Kunal Mehta)
* Modify generic pass test with a case of not-spacey parentheses (Vivek
Ghaisas)
* Make failing tests fail only for specific respective reasons (Vivek
Ghaisas)
* Change certain errors to warnings (Vivek Ghaisas)
* Update ExtraCharacters Sniff to allow shebang (Harshit Harchani)

To upgrade, just update your composer.json to say 0.2.0 and see if your
code still passes :)
In this release we are now tracking an explicit upstream version
(2.3.0), so you may need to update that dependency as well.

Special thanks to Vivek and James F for helping out with the release today!

If you want to set up PHPCS for your project, see the documentation at
https://www.mediawiki.org/wiki/Continuous_integration/Entry_points#PHP
to configure your repository, and file a bug under
#Continuous-Integration-Config to have jenkins configured to run it on
patches.

-- Legoktm

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

Re: [Wikitech-l] API BREAKING CHANGE: Default continuation mode for action=query will change at the end of this month

2015-06-04 Thread Legoktm
On 06/04/2015 09:45 AM, Brian Gerstle wrote:
 While it is (a little bit) nicer for new developers, they'll just burned
 (along with all the other current API users) when you change the defaults.
 What I'm trying to say is, changing the default seems like more work for
 more people with very little benefit. This is why
 https://developer.github.com/v3/ people https://www.reddit.com/dev/api
 version https://stripe.com/docs/api#charge_object APIs
 https://developer.linkedin.com/docs/rest-api.

I'd recommend reading https://phabricator.wikimedia.org/T41592, which
contains a pretty good rationale of why we currently don't version the API.

-- Legoktm

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

[Wikitech-l] MediaWiki-Codesniffer 0.3.0 released

2015-06-19 Thread Legoktm
Hello!

MediaWiki-Codesniffer 0.3.0 is now available for use in your MediaWiki
extensions and other projects. Here are the notable changes since the
last release (0.2.0):

* Don't require wf prefix on functions that are namespaced (Kunal Mehta)
* Simplify PHPUnit boostrap, require usage of composer for running tests
(Kunal Mehta)
* SpaceyParenthesis: Check for space before opening parenthesis (Vivek
Ghaisas)
* SpaceyParenthesesSniff: Search for extra/unnecessary space (Vivek Ghaisas)
* CharacterBeforePHPOpeningTagSniff: Support T_HASHBANG for HHVM
=3.5,3.7 (Kunal Mehta)

I have submitted patches which bump the depdencies for extensions
https://gerrit.wikimedia.org/r/#/q/status:open+topic:bump-dev-deps,n,z, 
however
some are failing due to the new sniffs. Please amend the patches to make
them pass and I can review them :)

-- Legoktm

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

Re: [Wikitech-l] wfSuppressWarnings deprecation

2015-06-21 Thread Legoktm
Hi,

On 06/21/2015 01:52 PM, Jeroen De Dauw wrote:
 Hey all,
 
 This thread is much in line with the wfRunHooks deprecation one from
 January. Rather than turning global functions into static functions, this
 time it's about namespacing global functions.
 
 All extensions calling wfSuppressWarnings now are supposed to change this
 to MediaWiki\suppressWarnings, for no obvious gain. 

The gain is that wfSuppressWarnings()/wfRestoreWarnings() is now a
separate library[1] that can be used by any PHP project outside of
MediaWiki. For example, I have a patch[2] that replaces usage of @ with
at-ease in OOUI. We are also planning[3] on creating a separate library
for the XMP parsing code in MediaWiki which would use at-ease.

 Important to keep in
 mind here is that this is not a simple search and replace, since that'd
 make extensions incompatible with anything before MediaWiki 1.26 alpha.
 Either we need to ignore the deprecations (which is not something you want
 people to learn as good practice), or we need to add some kind of wrapper
 in each extension.

Or just don't change anything? It is not going to trigger deprecation
warnings anytime soon, and for now it will just incur the overhead of
one extra function call. It is recommended that callers move to the
namespaced functions, but if you plan on supporting older versions of
MediaWiki core, don't.

 There also is the question of consistency. Nearly all global functions are
 still namespaced using the wf prefix. Will they all be changed? Or will
 just a few functions be migrated?

The wf prefix doesn't really make sense in a separate library, so we
used a namespace instead. I'm not sure if anyone has plans to
library-ize other global functions.


[1] http://packagist.org/packages/mediawiki/at-ease
[2] https://gerrit.wikimedia.org/r/#/c/217311/
[3] https://phabricator.wikimedia.org/T100922

-- Legoktm

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

Re: [Wikitech-l] Overriding Jenkins versus make-work patches

2015-06-17 Thread Legoktm
On 06/17/2015 09:53 AM, Brad Jorsch (Anomie) wrote:
1. Merge the core change over Jenkins's objections, then the Flow change
can be merged as normal. But overriding Jenkins sucks.

Force-merging in a jenkins/zuul managed repository should be avoided as
much as possible, since it will cause zuul to deadlock and freeze[1].

2. Split the core patch into two parts: part 1 does everything except
add the wfDeprecated() call, while part 2 adds just the wfDeprecated() call
and will be merged immediately after. The make-work here just to make
Jenkins happy sucks and slightly clutters the commit history.

I would prefer this one.


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

-- Legoktm

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

Re: [Wikitech-l] API returns empty strings for boolean fields?

2015-05-28 Thread Legoktm
On 05/28/2015 02:58 PM, Brian Gerstle wrote:
 Is this the desired behavior?

Yes-ish. It's a leftover from when XML was the primary API format. If
you pass formatversion=2 in the request, you'll get proper booleans (as
well as other improvements).

I re-closed https://phabricator.wikimedia.org/T15299 to indicate that.

-- Legoktm

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

Re: [Wikitech-l] Simplifying the WMF deployment cadence

2015-05-28 Thread Legoktm
On 05/27/2015 01:19 PM, Greg Grossmeier wrote:
 Hi all,
 
 New cadence:
 Tuesday: New branch cut, deployed to test wikis
 Wednesday: deployed to non-wikipedias
 Thursday: deployed to Wikipedias

This means that if we/users spot a bug once the train hits Wikipedias,
or the bug is in an extension like PageTriage which is only used on the
English Wikipedia, we have to: rush to make the 4pm SWAT window, deploy
on Friday, or wait until Monday; which from what I remember were similar
reasons from when we moved the train from Thursday to Wednesday.

-- Legoktm


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

Re: [Wikitech-l] Wikigrok code no longer being worked on

2015-06-01 Thread Legoktm
Hi,

On 06/01/2015 11:57 AM, Jon Katz wrote:
 *TLDR:* Wikigrok proved that readers are interested in and capable of
 making casual, mobile contributions to Wikipedia. We are putting
 continued development of the 'Wikigrok' casual contribution feature on
 hold until we have a plan for optimally harnessing this interest/capability.
 

Given that the extension is still deployed, what is the maintenance plan
for this extension? We already have a large amount of unmaintained code
deployed, so why isn't it being fully undeployed until people are ready
to commit resources and work on it again?

-- Legoktm

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

Re: [Wikitech-l] I forked GeSHi

2015-05-27 Thread Legoktm
On 05/26/2015 10:51 AM, Max Semenik wrote:
- Kill the system where every language definition specifies its own
styles in favor of a unified CSS file. That would make things more
consistent and allow us to significantly reduce the size of our startup
module that wouldn't need to contain all those per-language modules. And
would allow restyling the highlighted text easily and consistently.

This would be fantastic. Related bugs are
https://phabricator.wikimedia.org/T85794 and
https://phabricator.wikimedia.org/T85796.

-- Legoktm

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

Re: [Wikitech-l] Yandex?

2015-07-02 Thread Legoktm
On 07/01/2015 06:50 PM, Ricordisamoa wrote:
 Il 02/07/2015 03:28, Legoktm ha scritto:
 I noticed: Yandex coming up soon! under ContentTranslation. Are there
 more details about what this means?
 
 https://phabricator.wikimedia.org/T89844 I think

Thanks for the pointer. After some more digging, I found
https://www.mediawiki.org/wiki/Thread:Talk:Content_translation/Specification/Yandex_backend.

So it appears that ContentTranslation will be contacting a third-party,
closed source service? Are users going to be informed that this is the
case? What data is being sent?

I am also interested in the answer to Nemo's question about whether this
is the first piece of proprietary software ever entering use in the
Wikimedia projects land?

-- Legoktm

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

[Wikitech-l] Yandex? (was: 2015-07-01 Scrum of Scrums notes)

2015-07-01 Thread Legoktm
On 07/01/2015 11:29 AM, Grace Gellerman wrote:
 https://www.mediawiki.org/wiki/Scrum_of_scrums/2015-07-01

I noticed: Yandex coming up soon! under ContentTranslation. Are there
more details about what this means?

-- Legoktm

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

[Wikitech-l] Extension registration conversion and documentation sprint tomorrow!

2015-05-23 Thread Legoktm
Hello!

Tomorrow (Sunday May 24th) at the Lyon Hackathon we will have a
conversion and documentation sprint on extension registration at 17:00
in the Fourvière room.

https://tools.wmflabs.org/extreg-wos/ has a list of extensions that
have been converted and which still need to be converted! Stop by if you
want to work on converting an extension, learn about the new system, and
find out what's next! I'll also be working on improving the
documentation for sysamdins and developers at that time.

Phab task: https://phabricator.wikimedia.org/T90022

-- Legoktm

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

Re: [Wikitech-l] [WikimediaMobile] Freedom of Panorama banner campaign breaking mobile

2015-06-30 Thread Legoktm
On 06/30/2015 03:05 PM, Jon Robson wrote:
 Thanks for the quick reply! :)
 Yes site notices should be disabled on mobile, but site notices on
 mobile are currently treated different to central notice banners
 (rightly or wrongly) so I can only assume that this is served via
 CentralNotice?

No, it was a site notice:
https://en.wikipedia.org/w/index.php?title=MediaWiki:Sitenoticeoldid=669390461

-- Legoktm

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

Re: [Wikitech-l] [WikimediaMobile] Freedom of Panorama banner campaign breaking mobile

2015-06-30 Thread Legoktm
Filed an Unbreak Now! bug under MobileFrontend for this:
https://phabricator.wikimedia.org/T104401

-- Legoktm

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

Re: [Wikitech-l] Where to store OAuth application information?

2015-08-11 Thread Legoktm
Hi,

On 08/10/2015 06:23 PM, Gergo Tisza wrote:
 tl;dr should OAuth [1] (the system by which external tools can register to
 be Wikimedia applications and users can grant them the right to act in
 their name) rely on community-maintained description pages or profile forms
 filled by application authors?

Wiki pages please :)

 
 ---
 
 Some of the benefits and drawbacks of using wiki pages:
 * they require very little development;
 * it's a workflow we have a lot of experience with, and have high-quality
 tools to support it (templates, editing tools, automated updates etc.);
 * the information schema can be extended without the need to update
 software / change DB schemas;
 * easier to open up editing to anyone since there are mature change
 tracking / anti-abuse tools in MediaWiki (but even so, open editing would
 be somewhat scary - some fields might have legal strings attached or become
 attack vectors);

I assume these wiki pages would be some kind of structured
ContentHandler pages? We could restrict editing those fields to the
application owners then?

 * limited access control (MediaWiki namespace pages could be used, as they
 are e.g. for gadgets, to limit editing of certain information to admins,
 but something like owner can edit own application + OAuth admins can edit
 all aplications is not possible);

If it goes in a separate namespace, you can

 * hard to access from the software in a structured way - one could rely on
 naming conventions (e.g. the icon is always at File:OAuth-application
 name-icon.png) or use Wikidata somehow, but both of those sound awkward;

If the data is stored in a structured format, it should be easy to access.

 * design/usability/interface options are limited.

In what way? ContentHandler lets you override and customize pretty much
everything...

-- Legoktm

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

  1   2   3   >