Re: [Wikitech-l] Communication about proposed and planned UI changes

[Tyler Romeo]

On Thu, Dec 15, 2016 at 6:51 PM, Pine W <wiki.p...@gmail.com> wrote:

> My proposal would be that proposed UI changes which affect large
> proportions of the user base should be announced 3 months in advance.
> This would provide plenty of opportunity for discussion,
> synchronization, and testing of proposed changes.
>

A much finer definition is needed here. "Proposed UI changes which affect
large proportions of the user base", to my mind, includes basically any UI
change that affects any public user page, e.g., public Special Pages,
article pages, etc. It does not include any specification about the
significance of the change. (I understand this is intentional based on your
replies in the previous thread.)

I am still of the opinion that small UI changes, regardless of how many
users will be affected by the change, should not require a three-month
holding pattern while they are discussed. The amount of developer time and
productivity lost far outweighs the other consequences. Something like
minor shade changes to existing colors, slight movements or alignments of
specific containers, minor padding or margin adjustments, etc., are not
significant, even if the change is on an article page, which would affect
every millions of users. Something like a major color shade change, or a
major refactoring of the design of a popular page, is of course another
story.

My motivation for this is simple: I don't think software UI changes should
ever be based on community consensus, nor do I think Wikipedia users (or
rather, the subset of users that take interest in a Tech News announcement
or the like) are a suitable group of individuals for making decisions
regarding software development. Hell, not even the entire software
development team of MediaWiki (volunteer or WMF) should be making such a
decision. There's a reason why we have a UI standards group, composed of
experts who know at least a thing or two about UI design. Does that mean
these changes should occur opaquely without any communication? No, but the
opposite extreme of forcing a three-month comment period is possibly even
worse.

I do understand that there is a significant business requirement when it
comes to announcing significant changes, i.e., those beyond the shred of a
definition of what I consider a minor change. Be it community backlash and
a resulting decline in community engagement by users who consider the
volunteer software development team to be their mortal enemy, or
instructional videos that will become outdated and need funding to recreate
(which I don't view as a blocker for UI changes, but merely a consideration
that should be acknowledged before making cost decisions of UI changes),
there are some valid reasons why community notice should be given for a
change. But it certainly should not be for *every* change. There should be
a case-by-case decision of whether the given change would have a valid
requirement for prior notice.

*-- *
Regards,

*Tyler Romeo*
0x405d34a7c86b42df
https://parent5446.nyc
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Changes in colors of user interface

[Tyler Romeo]

May I just say if the time ever comes where MediaWiki developers have to
submit an RfC, coordinate with local wikis of numerous different languages,
and wait weeks for community feedback and consensus for minor UI color
changes, then all development would have been brought to a halt. It is that
kind of bikeshedding and red-tape that often makes enterprise software
development so cumbersome and loathed.

Honestly, I don't even think this change needs to be announced. If wikis
are overriding their own colors using common.css, then it is their due
diligence to make sure their custom unsupported code keeps up to date with
the base MediaWiki software.

*-- *
Regards,

*Tyler Romeo*
0x405d34a7c86b42df
https://parent5446.nyc

On Fri, Dec 9, 2016 at 9:32 PM, Steven Walling <steven.wall...@gmail.com>
wrote:

> Pine, please chill for once.
> On Fri, Dec 9, 2016 at 5:40 PM Legoktm <legoktm.wikipe...@gmail.com>
> wrote:
>
> > Hi,
> >
> > On 12/09/2016 05:25 PM, Pine W wrote:
> > > While I appreciate the attempt to be funny, I am not amused in this
> case.
> > > Surprise UI changes could, for example, result in thousands of dollars'
> > > worth of instructional videos becoming instantly out of sync with the
> > > real-world user experience. Also, users who may have spent considerable
> > > time perfecting their templates may be surprised to find that they need
> > to
> > > make changes to keep the templates in sync with other changes to the
> UI.
> > > The problem isn't so much that the UI was changed, as that it was
> changed
> > > without notice and consultation. This isn't funny.
> >
> > Well, I was specifically responding to Strainu's comment that "No change
> > is to small to be disliked by one or more people!" which seemed to be in
> > jest too.
> >
> > But I think you're significantly over-exaggerating the costs of this UI
> > change, and changes in general. MediaWiki's UI changes literally every
> > day when localization messages are updated, reworded, or added. Special
> > pages are re-organized to be made more intuitive, toolbars re-arranged,
> > etc. If you're making instructional videos, colors *barely* changing
> > seem like the least of your problems in terms of becoming out of date.
> > The VisualEditor project has a script that automatically generates
> > localized screenshots of the user interface so the user manual stays up
> > to date, I don't know if any solution has been worked out for videos yet.
> >
> > -- Legoktm
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Update on WMF account compromises

[Tyler Romeo]

On Thu, Nov 17, 2016 at 12:28 PM, Pine W <wiki.p...@gmail.com> wrote:

> 1. If you don't trust that strength testing site (which is fine), choose
> another. I did a couple of quick checks on that site; while it's entirely
> possible that I missed something, it appeared to me that the site was not
> sending passwords over the Internet, whether in the clear or encrypted. The
> use of HTTP or HTTPS is irrelevant if the data isn't getting sent out in
> the first place.
>

Or use a password manager that has a local built-in password strength tool,
that way you don't risk being MiTMed by an HTTP site.

In general, as mentioned, you should simply not enter your password on any
website that is not the site the password belongs to. For my full-time job,
employees have a Chrome extension where accidentally type your password on
any website (even if it's not in a text box) you're required to reset it.

*-- *
Regards,

*Tyler Romeo*
0x405d34a7c86b42df
https://parent5446.nyc
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] RFC: Add Content-Security-Policy header to MediaWiki

[Tyler Romeo]

First, as I expected, this proposal is to use CSP with the "unsafe-eval"
option enabled for both style-src and script-src. This means the JavaScript
eval() function can be used freely, and inline CSS via the style attribute
can still be used. Combined with the "default-src *" policy, which I
mention later in this email, this means an attacker can just use XHR to
download an external script and eval() it, thus defeating the entire point
of CSP: to prevent XSS attacks.

I understand the reason behind this is because we store scripts in
localStorage as cache and eval() them upon page load (which is perhaps the
worst abuse of browser technology I have ever seen). Not allowing both
inline scripts and styles and eval()ed code is one half of the two-sided
CSP coin, and eliminating it keeps open a pretty large attack vector. I
don't believe it's appropriate to sacrifice security for a quick kludge
that is used to improve the performance hole opened by the large
fragmentation of our JavaScript codebase.

Second, the proposal is to use the nonce-$RANDOM attribute for inline
scripts, but to cache the nonce for non-logged-in users. Does this mean
that the same nonce will be delivered to multiple pages and/or users?
Because that is a violation of the CSP spec, which says "If a server
delivers a nonce-source expression as part of a police, the server MUST
generate a unique value each time it transmits a policy." [0] Thus we
cannot use nonces in this way. Are these scripts whose contents we know
beforehand? Because then we can just use the hash-source policy.

(Not to mention that nonce-source and hash-source policies are part of CSP
2, which is not supported in the latest IE, Safari, or Opera Mini. What is
the plan to support these browsers? Fall back to unsafe-inline? Possibly
use a solution similar to what Dropbox used for their CSP deployment [1].)

Finally, as stage 1 hints at and as I mentioned above, there are a lot more
than just style-src and script-src, such as font-src, media-src, frame-src,
manifest-src, etc. Why are these not addressed, and instead just left to
the default policy of "default-src *"? Do we allow iframes on Wikipedia
pointing at arbitrary domains? At the very least, a scheme-source policy
can be used to enforce HTTPS.

[0] https://w3c.github.io/webappsec-csp/
[1]
https://blogs.dropbox.com/tech/2015/09/unsafe-inline-and-nonce-deployment/


*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science

On Mon, May 23, 2016 at 1:18 AM, Pine W <wiki.p...@gmail.com> wrote:

> With the disclaimer that I'm not a security engineer and that I understand
> only parts of this proposal, in general this strikes me as a good idea. It
> seems to me that trying to develop a comprehensive list of what tools /
> scripts this proposal would likely break, how important those breaks are,
> and who could fix them and when, would help with developing a roadmap
> toward implementing this proposal with appropriate mitigation and
> communication.
>
> It seems to me that this is the kind of project for which product community
> liasons are well suited to help with developing and implementing a rollout
> plan. Is there any chance of getting a CL to help with this project?
>
> Thanks for the initiative,
>
> Pine
>
> Pine
> On May 22, 2016 18:18, "Brian Wolff" <bawo...@gmail.com> wrote:
>
> > So the RFC process page says I should email wikitech-l to propose an RFC,
> > thus:
> >
> > Content-Security-Policy (CSP) header is a header that disables certain
> > javascript features that are commonly used to exploit XSS attacks, in
> > order to mitigate the risks of XSS. I think we could massively benefit
> > from using this technology - XSS attacks probably being the most
> > common security issue in MediaWiki. The downside is that it would
> > break compatibility with older user scripts.
> >
> > Please see the full text of my proposal at
> >
> https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy
> >
> > The associated phabricator ticket is:
> > https://phabricator.wikimedia.org/T135963
> >
> > I'd appreciate any comments anyone might have.
> >
> > Thanks,
> > Brian
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

[Tyler Romeo]

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

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

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

From: Joaquin Oltra Hernandez <jhernan...@wikimedia.org>
Reply: Wikimedia developers <wikitech-l@lists.wikimedia.org>
Date: February 12, 2016 at 14:31:54
To: Wikimedia developers <wikitech-l@lists.wikimedia.org>
Subject:  Re: [Wikitech-l] Mass migration to new syntax - PRO or CON?  

PRO from me too.

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

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

On Fri, Feb 12, 2016 at 8:28 PM, Alex Monk <kren...@gmail.com> wrote:

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

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

[Wikitech-l] Fw: Shutting down persona.org in November 2016

[Tyler Romeo]

So...

I stopped development on the Persona extension a while ago when Mozilla dropped 
official support for it, but with persona.org shutting down, I am considering 
deprecating the extension entirely, especially considering the work that would 
be required porting it to AuthManager.

But I figured I'd give a sort of last call. Is there anybody here that knows if 
the extension is being used (despite being marked as experimental) and thinks I 
should still maintain some sort of support for it?

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

From: Ryan Kelly <rfke...@mozilla.com>
Reply: dev-ident...@lists.mozilla.org <dev-ident...@lists.mozilla.org>
Date: January 11, 2016 at 20:09:31
To: dev-ident...@lists.mozilla.org <dev-ident...@lists.mozilla.org>, 
persona-noti...@mozilla.org <persona-noti...@mozilla.org>
Subject:  Shutting down persona.org in November 2016  


Hi Everyone,


When the Mozilla Identity team transitioned Persona to community
ownership, we committed resources to operational and security support
throughout 2014 [1], and renewed that commitment for 2015 [2]. Due to
low, declining usage, we are reallocating the project’s dedicated,
ongoing resources and will shut down the persona.org services that we run.

Persona.org and related domains will be taken offline on November 30th,
2016.

If you run a website that relies on Persona, you will need to implement
an alternative login solution for your users. We have assembled a wiki
page with additional information and guidelines for migration [3], but
here are the important things you need to know:

Between now and November 30th, 2016, Mozilla will continue to support
the Persona service at a maintenance level:

* Security issues will be resolved in a timely manner and the services
will be kept online, but we do not expect to develop or deploy any
new features.

* Support will continue to be available on the dev-identity mailing
list [4] and in the #services-dev IRC channel [5].

* All websites that rely on persona.org will need to migrate to
another means of authentication during this period.

Beginning on November 30th, 2016, the Persona service hosted by Mozilla
will be decommissioned:

* All services hosted on the persona.org domain will be shut down.

* Mozilla will retain control of the persona.org domain and will
not transfer it to a third party.

* Since the privacy of user data is of utmost importance to Mozilla,
we will destroy all user data stored on the persona.org servers,
and will not transfer it to third parties.

We intentionally designed Persona to expose email addresses rather than
opaque identifiers, which should ease the transition to other systems
that provide verified email addresses. You can find guidelines on
alternative login solutions on the wiki [3] and we will continue to
update them over the coming year. We strongly encourage affected teams
to openly discuss and blog about their migrations on the dev-identity
mailing list so that others can learn from their experience.

Thank you for your support and involvement with Persona. If you have any
questions, please post them to the dev-identity mailing list.


Ryan


[1]
http://identity.mozilla.com/post/78873831485/transitioning-persona-to-community-ownership
[2] https://groups.google.com/forum/#!topic/mozilla.dev.identity/rPIm7GxOeNU
[3]
https://wiki.mozilla.org/Identity/Persona_Shutdown_Guidelines_for_Reliers
[4] https://lists.mozilla.org/listinfo/dev-identity
[5] http://irc.mozilla.org/#services-dev
___
Persona-notices mailing list
persona-noti...@mozilla.org
https://mail.mozilla.org/listinfo/persona-notices


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

Re: [Wikitech-l] [RFC/Summit] `npm install mediawiki-express`

[Tyler Romeo]

I would very, *very* much prefer to not have MediaWiki core extensions written 
in JavaScript. Even beyond my criticisms of JavaScript as a language, I feel 
like that just unnecessarily introduces complexity. The purpose of this wrapper 
is to combine separate micro-services that would otherwise be run in separate 
VMs / servers / etc. so that it can easily be run in a hosting setup.

Otherwise, I'm interested in what implications this will have, especially for 
making MediaWiki easier to install and use, which would be awesome.

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

From: C. Scott Ananian <canan...@wikimedia.org>
Reply: Wikimedia developers <wikitech-l@lists.wikimedia.org>
Date: November 6, 2015 at 14:14:13
To: Wikimedia developers <wikitech-l@lists.wikimedia.org>
Subject:  Re: [Wikitech-l] [RFC/Summit] `npm install mediawiki-express`  

Let's not let this discussion sidetrack into "shared hosting vs VMs (vs
docker?)" --- there's another phabricator ticket and summit topic for that (
https://phabricator.wikimedia.org/T87774 and
https://phabricator.wikimedia.org/T113210.

I'd prefer to have discussion in *this* particular task/thread concentrate
on:

* Hey, we can have JavaScript and PHP in the same packaging system. What
cool things might that enable?

* Hey, we can have JavaScript and PHP running together in the same server.
Perhaps some persistence-related issues with PHP can be made easier?

* Hey, we can actually write *extensions for mediawiki-core* in JavaScript
(or CoffeeScript, or...) now. Or run PHP code inside Parsoid. How could
we use that? (Could it grow developer communities?)

* How are parser extensions (like, say, WikiHiero, but there are lots of
them) going to be managed in the long term? There are three separate
codebases to hook right now. An extension like  might eventually
need to hook the image thumbnail service, too. Do we have a plan?

And the pro/anti-npm and pro/anti-docker and pro/anti-VM discussion can go
into one of those other tasks. Thanks.

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

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

Re: [Wikitech-l] [RFC/Summit] `npm install mediawiki-express`

[Tyler Romeo]

That's a pretty good point. Despite my comments, I'll definitely keep an open 
mind, and am interested in what people might propose.

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

From: C. Scott Ananian <canan...@wikimedia.org>
Reply: C. Scott Ananian <canan...@wikimedia.org>
Date: November 6, 2015 at 15:01:59
To: Tyler Romeo <tylerro...@gmail.com>
CC: Wikimedia developers <wikitech-l@lists.wikimedia.org>
Subject:  Re: [Wikitech-l] [RFC/Summit] `npm install mediawiki-express`  

Tyler: I hear you.  I'm not sure it's a good idea, either -- especially not for 
core extensions used in production.

But it does perhaps allow some expansion of our developer community on the 
fringes, and makes writing extensions possible for a larger set of people?  And 
perhaps there are some cool things written in JavaScript which the extended 
community could more easily hook up to MediaWiki using `php-embed`.

I'm not sure that there are.  I'm just opening up the discussion to see if 
anyone pipes up with, "oh, yeah, I've always wanted to do XYZ!".

Greg: I agree re: premature stifling of discussion.  I'm just saying that 
"high-level" conversation is already happening elsewhere, and it's more 
productive there.  I started *this* particular thread trying to elicit 
discussion more narrowly focused on the thing I've just built.
  --scott

On Fri, Nov 6, 2015 at 2:30 PM, Tyler Romeo <tylerro...@gmail.com> wrote:
I would very, *very* much prefer to not have MediaWiki core extensions written 
in JavaScript. Even beyond my criticisms of JavaScript as a language, I feel 
like that just unnecessarily introduces complexity. The purpose of this wrapper 
is to combine separate micro-services that would otherwise be run in separate 
VMs / servers / etc. so that it can easily be run in a hosting setup.

Otherwise, I'm interested in what implications this will have, especially for 
making MediaWiki easier to install and use, which would be awesome.

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

From: C. Scott Ananian <canan...@wikimedia.org>
Reply: Wikimedia developers <wikitech-l@lists.wikimedia.org>
Date: November 6, 2015 at 14:14:13
To: Wikimedia developers <wikitech-l@lists.wikimedia.org>
Subject:  Re: [Wikitech-l] [RFC/Summit] `npm install mediawiki-express`

Let's not let this discussion sidetrack into "shared hosting vs VMs (vs
docker?)" --- there's another phabricator ticket and summit topic for that (
https://phabricator.wikimedia.org/T87774 and
https://phabricator.wikimedia.org/T113210.

I'd prefer to have discussion in *this* particular task/thread concentrate
on:

* Hey, we can have JavaScript and PHP in the same packaging system. What
cool things might that enable?

* Hey, we can have JavaScript and PHP running together in the same server.
Perhaps some persistence-related issues with PHP can be made easier?

* Hey, we can actually write *extensions for mediawiki-core* in JavaScript
(or CoffeeScript, or...) now. Or run PHP code inside Parsoid. How could
we use that? (Could it grow developer communities?)

* How are parser extensions (like, say, WikiHiero, but there are lots of
them) going to be managed in the long term? There are three separate
codebases to hook right now. An extension like  might eventually
need to hook the image thumbnail service, too. Do we have a plan?

And the pro/anti-npm and pro/anti-docker and pro/anti-VM discussion can go
into one of those other tasks. Thanks.

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



--
(http://cscott.net)

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

Re: [Wikitech-l] [RFC/Summit] `npm install mediawiki-express`

[Tyler Romeo]

Using VMs does not take any "technical enlightenment". There are 
containerization tools that are relatively simple to use for non-scale 
environments, and learning them would take just as much time as learning how to 
use npm.

(Note, I'm not arguing against this solution, which I think is pretty cool. 
Just wanted to speak out against the concept that npm is somehow far easier to 
use than any other solution.)

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

From: Yongmin Hong <li...@revi.pe.kr>
Reply: Wikimedia developers <wikitech-l@lists.wikimedia.org>
Date: November 5, 2015 at 23:36:07
To: Wikimedia developers <wikitech-l@lists.wikimedia.org>
Subject:  Re: [Wikitech-l] [RFC/Summit] `npm install mediawiki-express`  

2015. 11. 6. 오전 8:26에 "Ryan Lane" <rlan...@gmail.com>님이 작성:
>
> Is this simply to support hosted providers? npm is one of the worst
package
> managers around. This really seems like a case where thin docker images
and
> docker-compose really shines. It's easy to handle from the packer side,
> it's incredibly simple from the user side, and it doesn't require
> reinventing the world to distribute things.
>
> If this is the kind of stuff we're doing to support hosted providers, it
> seems it's really time to stop supporting hosted providers. It's $5/month
> to have a proper VM on digital ocean. There's even cheaper solutions
> around. Hosted providers at this point aren't cheaper. At best they're
> slightly easier to use, but MediaWiki is seriously handicapping itself to
> support this use-case.
>
>

Please remember, not everyone is technically-enlighted to use VMs.
--
revi
https://revi.me
-- Sent from Android --
2015. 11. 6. 오전 8:26에 "Ryan Lane" <rlan...@gmail.com>님이 작성:

Is this simply to support hosted providers? npm is one of the worst package
managers around. This really seems like a case where thin docker images and
docker-compose really shines. It's easy to handle from the packer side,
it's incredibly simple from the user side, and it doesn't require
reinventing the world to distribute things.

If this is the kind of stuff we're doing to support hosted providers, it
seems it's really time to stop supporting hosted providers. It's $5/month
to have a proper VM on digital ocean. There's even cheaper solutions
around. Hosted providers at this point aren't cheaper. At best they're
slightly easier to use, but MediaWiki is seriously handicapping itself to
support this use-case.

On Thu, Nov 5, 2015 at 1:47 PM, C. Scott Ananian <canan...@wikimedia.org>
wrote:

> Architecturally it may be desirable to factor our codebase into multiple
> independent services with clear APIs, but small wikis would clearly like a
> "single server" installation with all of the services running under one
> roof, as it were. Some options previously proposed have involved VM
> containers that bundle PHP, Node, MediaWiki and all required services into
> a preconfigured full system image. (T87774
> <https://phabricator.wikimedia.org/T87774>)
>
> This summit topic/RFC proposes an alternative: tightly integrating
PHP/HHVM
> with a persistent server process running under node.js. The central
service
> bundles together multiple independent services, written in either PHP or
> JavaScript, and coordinates their configurations. Running a
> wiki-with-services can be done on a shared node.js host like Heroku.
>
> This is not intended as a production configuration for large wikis -- in
> those cases having separate server farms for PHP, PHP services, and
> JavaScript services is best: that independence is indeed the reason why
> refactoring into services is desirable. But integrating the services into
a
> single process allows for hassle-free configuration and maintenance of
> small wikis.
>
> A proof-of-concept has been built. The node package php-embed
> <https://www.npmjs.com/package/php-embed> embeds PHP 5.6.14 into a node.js
> (>= 2.4.0) process, with bidirectional property and method access between
> PHP and node. The package mediawiki-express
> <https://www.npmjs.com/package/mediawiki-express> uses this to embed
> MediaWiki into an express.js <http://expressjs.com/> HTTP server. (Other
> HTTP server frameworks could equally well be used.) A hook in the `
> LocalSettings.php` allows you to configure the mediawiki instance in
> JavaScript.
>
> A bit of further hacking would allow you to fully configure the MediaWiki
> instance (in either PHP or JavaScript) and to dispatch to Parsoid (running
> in the same process).
>
> *SUMMIT GOALS / FOR DISCUSSION*
>
>
> - Determine whether this technology (or something similar) might be an
> acceptable alternative for small sites which are currently using shared
> hosting. See T113210 <https://phabricat

Re: [Wikitech-l] Short license blocks

[Tyler Romeo]

IANAL, but the GPL explicitly prescribes adding the header to every source
file to "most effectively state the exclusion of warranty".

If the legal guys can give the OK that we don't necessarily need that, then
we can definitely remove the notices and replace them with something
smaller.


*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science

On Tue, Oct 27, 2015 at 5:44 AM, Gergo Tisza <gti...@wikimedia.org> wrote:

> In a recent blog post ( http://esr.ibiblio.org/?p=6867 ) ESR writes:
>
> High on my list of Things That Annoy Me When I Hack is sourcefiles that
> > contain huge blobs of license text at the top. That is valuable territory
> > which should be occupied by a header comment explaining the code, not a
> > boatload of boilerplate that I’ve seen hundreds of times before.
>
>
> ...and then goes on to explain using SPDX identifiers to refer to licenses,
> which would look something like this:
>
> /* Copyright 2015 by XYZ
>  * SPDX-License-Identifier: GPL-2.0+
>  */
>
> Any objections to making that the new standard / replacing existing blocks
> with this? It would make the PHP files a little more readable.
> ___
> 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] Short license blocks

[Tyler Romeo]

Are you saying adopting the short license blocks? Or the MIT license?
Because I'm not sure how the licenses of extensions would affect the
license headers in core.
On Oct 27, 2015 12:43, "Ryan Kaldari"  wrote:

> 
> I totally support switching to license identifiers instead of headers,
> provided that we also switch our licensing from GPL to MIT or BSD ;)
> 
>
> On a serious note, we do have a fair number of extensions that are MIT
> Licensed and could go ahead and adopt this (
> https://www.mediawiki.org/wiki/Category:MIT_licensed_extensions).
>
>
> On Tue, Oct 27, 2015 at 3:44 AM, Gergo Tisza  wrote:
>
> > In a recent blog post ( http://esr.ibiblio.org/?p=6867 ) ESR writes:
> >
> > High on my list of Things That Annoy Me When I Hack is sourcefiles that
> > > contain huge blobs of license text at the top. That is valuable
> territory
> > > which should be occupied by a header comment explaining the code, not a
> > > boatload of boilerplate that I’ve seen hundreds of times before.
> >
> >
> > ...and then goes on to explain using SPDX identifiers to refer to
> licenses,
> > which would look something like this:
> >
> > /* Copyright 2015 by XYZ
> >  * SPDX-License-Identifier: GPL-2.0+
> >  */
> >
> > Any objections to making that the new standard / replacing existing
> blocks
> > with this? It would make the PHP files a little more readable.
> > ___
> > 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] Short license blocks

[Tyler Romeo]

The Apache license, which is also permissive, has a similar recommended
file header.

I'd say we just standardize on having the warranty disclaimer and license
notice in every file. It's an easy approach to make sure somebody reading
the file can easily tell the license without having to maintain
comprehensive authorship information in every file.
On Oct 27, 2015 14:17, "Ryan Kaldari" <rkald...@wikimedia.org> wrote:

> I was saying that we could go ahead and make this the standard for non-GPL
> MediaWiki code (basically, the few MIT licensed extensions). I'm not sure
> if the advantage of doing that would outweigh the disadvantage of having a
> non-standard standard though.
>
> On Tue, Oct 27, 2015 at 11:06 AM, Tyler Romeo <tylerro...@gmail.com>
> wrote:
>
> > Are you saying adopting the short license blocks? Or the MIT license?
> > Because I'm not sure how the licenses of extensions would affect the
> > license headers in core.
> > On Oct 27, 2015 12:43, "Ryan Kaldari" <rkald...@wikimedia.org> wrote:
> >
> > > 
> > > I totally support switching to license identifiers instead of headers,
> > > provided that we also switch our licensing from GPL to MIT or BSD ;)
> > > 
> > >
> > > On a serious note, we do have a fair number of extensions that are MIT
> > > Licensed and could go ahead and adopt this (
> > > https://www.mediawiki.org/wiki/Category:MIT_licensed_extensions).
> > >
> > >
> > > On Tue, Oct 27, 2015 at 3:44 AM, Gergo Tisza <gti...@wikimedia.org>
> > wrote:
> > >
> > > > In a recent blog post ( http://esr.ibiblio.org/?p=6867 ) ESR writes:
> > > >
> > > > High on my list of Things That Annoy Me When I Hack is sourcefiles
> that
> > > > > contain huge blobs of license text at the top. That is valuable
> > > territory
> > > > > which should be occupied by a header comment explaining the code,
> > not a
> > > > > boatload of boilerplate that I’ve seen hundreds of times before.
> > > >
> > > >
> > > > ...and then goes on to explain using SPDX identifiers to refer to
> > > licenses,
> > > > which would look something like this:
> > > >
> > > > /* Copyright 2015 by XYZ
> > > >  * SPDX-License-Identifier: GPL-2.0+
> > > >  */
> > > >
> > > > Any objections to making that the new standard / replacing existing
> > > blocks
> > > > with this? It would make the PHP files a little more readable.
> > > > ___
> > > > Wikitech-l mailing list
> > > > Wikitech-l@lists.wikimedia.org
> > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > > ___
> > > Wikitech-l mailing list
> > > Wikitech-l@lists.wikimedia.org
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> ___
> Wikitech-l 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] Short license blocks

[Tyler Romeo]

> Who are "the legal guys"? Do they assume liability for fu-
> ture claims with regard to that matter so that authors are
> effectively indemnified? 

That's a very good point. Sometimes I forget that MediaWiki
does not use CLA (which is another discussion).

In that case I go back on what I said, and maintain that I'd
like the license header to be kept.

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


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

Re: [Wikitech-l] Short license blocks

[Tyler Romeo]

On Tue, Oct 27, 2015 at 9:19 PM, Platonides <platoni...@gmail.com> wrote:

> Regarding "keeping the big header is important", I don't think anyone
> barely into CS  on this century can not know what the GPL is (and not
> figure out in 5 minutes).
>
> An excerpt like this would be perfectly fine imho:
> «This MediaWiki file is licensed under the terms of GPL 2 or later, as
> published in http://www.gnu.org/licenses/gpl2 See the COPYING file for
> details.»
>

It has nothing to do with whether or not they know the GPL. As the FLC link
explains, it is about clearly conveying that the code is indeed copyrighted
under a certain license, such that somebody who violates the license cannot
claim innocence or otherwise try and push some of the blame onto us.

That said, I really don't think bikeshedding over reducing a license header
from 4 lines of text to 2 lines really makes a difference. I'd much rather
use the format advised by GNU itself, considering they did write the
license.

(As for the whole warranty disclaimer, which takes up its own 4 lines, I do
not know enough to argue for or against whether it is necessary, since
software liability is a separate legal device from copyright.)

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

Re: [Wikitech-l] JetBrains IDE licenses for MW developers - php, js/node, python, C/C++, puppet, ruby, ...

[Tyler Romeo]

On Thu, Oct 22, 2015 at 12:14 AM, Ricordisamoa <ricordisa...@openmailbox.org
> wrote:

> How come the FOSS community hasn't managed to develop a suitable
> alternative yet?!?


If I had the time, I would definitely put together some sort of
.dir-locals.el for MediaWiki, that way we could make better use of Emacs,
since it has a bunch of IDE-like functionality, even if it's not IDEA-level
powerful.

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

Re: [Wikitech-l] AWS usage

[Tyler Romeo]

On Wed, Oct 7, 2015 at 11:27 AM, Greg Grossmeier <g...@wikimedia.org> wrote:

> As in, they would not be experiencing any outage because they are not
> using Travis. The very topic of this thread.
>

Nowhere in this thread is the uptime of Travis or AWS mentioned as far as I
see, so it's understandable to be confused as to why we're "lucky" to not
be using Travis.

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

Re: [Wikitech-l] GitLab CI (was RFC: Optional Travis Integration for Jenkins)

[Tyler Romeo]

I hate to say it, but this is exactly why we should be preferring copyleft
licenses. GitLab began as completely FOSS, but only later on split into the
CE and EE, which they were able to do because they used MIT.


*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science

On Wed, Oct 7, 2015 at 11:26 AM, Greg Grossmeier <g...@wikimedia.org> wrote:

> Thanks Brian for your thoughts.
>
> Only commenting on one small part:
>
> 
> > *Pros*
> >
> >- FLOSS
>
> ...ish. Not really. "Open Core".
>
> See: https://en.wikipedia.org/wiki/GitLab#History
>
> A view on why Open Core isn't healthy for FLOSS communities:
> http://ebb.org/bkuhn/blog/2009/10/16/open-core-shareware.html
>
>
> Greg
>
> --
> | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
> | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |
>
> ___
> 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] GitLab licensing (was Re: GitLab CI)

[Tyler Romeo]

That's a really good point, and something I did not think about.

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

From: Greg Grossmeier <g...@wikimedia.org>
Reply: Wikimedia developers <wikitech-l@lists.wikimedia.org>
Date: October 7, 2015 at 13:19:55
To: wikitech-l@lists.wikimedia.org <wikitech-l@lists.wikimedia.org>
Subject:  [Wikitech-l] GitLab licensing (was Re: GitLab CI)  


> On Wed, Oct 7, 2015 at 12:34 PM, Brian Gerstle <bgers...@wikimedia.org>
> wrote:
>  
> > Thanks for the correction & link, Greg, will check that out. Is this
> > different than GitHub's approach? Is it better or worse?
> >
>  
> GitHub is entirely proprietary. So technically yes, GitLab's approach is a
> little better, since at least some core part of the software remains open.

With my non-work hat on[0], it's not really a matter of "better" or
"worse". GitHub doesn't mince words; they are proprietary.

Gitlab, however, has tremendously annoyed the FLOSS community[1] by
doing a "bait and switch" type move. Promoting their openness but
also keeping more than just the "secret sauce" locked up.

See the things which they keep proprietary:
https://about.gitlab.com/features/#compare
Basic things like "git hooks". :/

Not a great example working relationship with FLOSS partners.


Greg

[0] Sending with my personal email address but via my wmf gmail account
because I'm not subscribed to wikitech-l with my personal email.

[1] At least those who I talk with, including those in prominent FLOSS
community positions, who were hoping for gitlab to be great.

--  
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

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

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

Re: [Wikitech-l] GitLab CI (was RFC: Optional Travis Integration for Jenkins)

[Tyler Romeo]

On Wed, Oct 7, 2015 at 12:34 PM, Brian Gerstle <bgers...@wikimedia.org>
wrote:

> Thanks for the correction & link, Greg, will check that out.  Is this
> different than GitHub's approach?  Is it better or worse?
>

GitHub is entirely proprietary. So technically yes, GitLab's approach is a
little better, since at least some core part of the software remains open.

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

Re: [Wikitech-l] Getting mediawiki core to pass codesniffer standard

[Tyler Romeo]

On Fri, Sep 25, 2015 at 2:08 PM, Legoktm <legoktm.wikipe...@gmail.com>
wrote:

> I've tried out a different approach in
> <https://gerrit.wikimedia.org/r/#/c/241085/>, by disabling all the
> failing rules. This will let us make the rules that do pass voting (e.g.
> no closing ?> tags), and we can selectively enable failing rules instead
> of trying to make giant patches and hope no one introduces regressions
> while it's still non-voting.
>

Very much agree with this post. I have worked on phpcs compliance on other
projects at my company, and we have found it vastly easier to stage-in over
time, that way at the very least additional errors are not accidentally
introduced.

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

Re: [Wikitech-l] Announcing the launch of Maps

[Tyler Romeo]

I feel like there's an argument to be made that the images are a derived
work from the data itself, so it may be best to just stick with OSM's
license rather than run into any possible issues. (Also, of course, I am
biased and prefer copyleft licenses since they support free information.)


*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science

On Thu, Sep 17, 2015 at 3:49 PM, Ryan Kaldari <rkald...@wikimedia.org>
wrote:

> And in case that isn't decided, I would suggest CC0 so that we don't have
> to link to a big explanation from each tile rendering :)
>
> On Thu, Sep 17, 2015 at 12:40 PM, Ryan Kaldari <rkald...@wikimedia.org>
> wrote:
>
> > What is the license for the map tiles, i.e. the cartography rather than
> > the data? Open Street Maps uses CC-BY-SA, although they don't really make
> > it clear who is supposed to be attributed. It looks like our tiles are
> > different though.
> >
> > On Thu, Sep 17, 2015 at 12:26 PM, Tomasz Finc <tf...@wikimedia.org>
> wrote:
> >
> >> The Discovery Department has launched an experimental tile and static
> maps
> >> service available at https://maps.wikimedia.org.
> >>
> >> Using this service you can browse and embed map tiles into your own
> tools
> >> using OpenStreetMap data. Currently, we handle traffic from *.wmflabs
> .org
> >> and *.wikivoyage .org (referrer header must be either missing or set to
> >> these values) but we would like to open it up to Wikipedia traffic if we
> >> see enough use. Our hope is that this service fits the needs of the
> >> numerous maps developers and tool authors who have asked for a WMF
> hosted
> >> tile service with an initial focus on WikiVoyage.
> >>
> >> We'd love for you to try our new service, experiment writing tools using
> >> our tiles, and giving us feedback <
> >> https://www.mediawiki.org/wiki/Talk:Maps> .
> >> If you've built a tool using OpenStreetMap-based imagery then using our
> >> service is a simple drop-in replacement.
> >>
> >> Getting started is as easy as
> >> https://www.mediawiki.org/wiki/Maps#Getting_Started
> >>
> >> How can you help?
> >>
> >> * Adapt your labs tool to use this service - for example, use Leaflet js
> >> library and point it to https://maps.wikimedia.org
> >> * File bugs in Phabricator
> >> <https://phabricator.wikimedia.org/tag/discovery-maps-sprint/>
> >> * Provide us feedback to help guide future features
> >> <https://www.mediawiki.org/wiki/Talk:Maps>
> >> * Improve our map style <https://github.com/kartotherian/osm-bright.tm2
> >
> >> * Improve our data extraction
> >> <https://github.com/kartotherian/osm-bright.tm2source>
> >>
> >> Based on usage and your feedback, the Discovery team
> >> <https://www.mediawiki.org/wiki/Discovery> will decide how to proceed.
> >>
> >> We could add more data sources (both vector and raster), work on
> >> additional
> >> services such as static maps or geosearch, work on supporting all
> >> languages, switch to client-side WebGL rendering, etc. Please help us
> >> decide what is most important.
> >>
> >> https://www.mediawiki.org/wiki/Maps has more about the project and
> >> related
> >> Maps work.
> >>
> >> == In Depth ==
> >>
> >> Tiles are served from https://maps.wikimedia.org, but can only be
> >> accessed
> >> from any subdomains of *.wmflabs .org and *.wikivoyage.org.
> Kartotherian
> >> can produce tiles as images (png), and as raw vector data (PBF Mapbox
> >> format or json):
> >>
> >> .../{source}/{zoom}/{x}/{y}[@{scale}x].{format}
> >>
> >> Additionally, Kartotherian can produce snapshot (static) images of any
> >> location, scaling, and zoom level with
> >>
> >> .../{source},{zoom},{lat},{lon},{width}x{height}[@{scale}x].{format}.
> >>
> >> For example, to get an image centered at 42,-3.14, at zoom level 4, size
> >> 800x600, use
> >> https://maps.wikimedia.org/img/osm-intl,4,42,-3.14,800x600.png
> >> (copy/paste the link, or else it might not work due to referrer
> >> restriction).
> >>
> >> Do note that the static feature is highly experimental right now.
> >>
> >> We would like to thank WMF Ops (especially Alex Kosiaris, Brandon Black,
> >> and Jaime Crespo), services team, OSM community and engineers, and the
> >> Mapnik and Mapbox teams. The project would not have completed so fast
> >> without you.
> >>
> >> Thank You
> >>
> >> --tomasz
> >> ___
> >> 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] The "other" developers at the Wikimedia Developer Summit

[Tyler Romeo]

On Tue, Sep 15, 2015 at 12:43 PM, Dan Garry <dga...@wikimedia.org> wrote:

> However, you're right that one would not expect such people to propose
> architecture changes in MediaWiki; that's not really their domain. However,
> to me that does not seem necessary in order to attend the developer summit.
> Their perspectives as people involved in the development of MediaWiki and
> Wikimedia projects would be welcome.
>

I think this is the key point. Remember that this is the "developer summit"
and
not an "architecture summit", and as such anything MediaWiki-related is up
for
grabs. And if the topic of templates comes up, specifically what we need to
fix
in templates or what new features we should focus on next, who better to
have
there for that than the users of templates themselves.

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

Re: [Wikitech-l] [Engineering] Code of conduct

[Tyler Romeo]

On Sun, Aug 23, 2015 at 2:24 PM, Oliver Keyes oke...@wikimedia.org wrote:

 bad things
 are happening, why don't we do X is to literally google why isn't
 [the obviously simple thing I thought of] a good idea?, and see what
 smart people have already written


Ironically, I tried to be devil's advocate by searching why isn't a code
of conduct a good idea, and pretty much every result was an article on how
code of conducts *are *a good idea.

That aside, I think most of the people in this thread are already
well-aware that admins is a very generic term, and that even so, most
definitions of the word admins would probably not be a good enforcing
body for a code of conduct.

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

Re: [Wikitech-l] [Engineering] Code of conduct

[Tyler Romeo]

On Sat, Aug 22, 2015 at 2:40 PM, Brian Wolff bawo...@gmail.com wrote:

 For example, MediaWiki is intentionally GPLv2, not GPLv3.


MediaWiki is not intentionally GPLv2. It merely is v2 now and the community
cannot come to a consensus on whether to change it, thus it remains in its
current stagnant state.

And this is exactly what rupert is talking about: policies and other
important documents and decisions like this very rarely are brought into
the modern age, either because the WMF does not have resources to update
them or because the community cannot come to a decision on what updates to
make or not make.

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

Re: [Wikitech-l] [Engineering] Code of conduct

[Tyler Romeo]

On Sun, Aug 9, 2015 at 2:43 AM, Moriel Schottlender mor...@gmail.com
wrote:

 An I missing something?


When an employee of the WMF starts a new topic on the mailing list with the
words we are and binding, it comes off with the wrong connotation,
especially considering the we was clarified to mean the Wikimedia
technical community.

It sounds more like you've already decided to do this rather than we
thought this might be a good idea and want everybody else's input. You
should naturally expect people to speak out against something when you make
it sound like their opinion has already been decided upon.

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

Re: [Wikitech-l] Min php version

[Tyler Romeo]

One thing I forgot to mention: while you're considering Debian and Ubuntu 
support, make sure to also take into account MediaWiki support.

Even if we upgrade our minimum PHP version now, older versions of MediaWiki 
with the 5.3 requirement will still be supported and receive security updates. 
So the only difference will be that people running Debian oldstable will be 
locked into our older version and not be able to upgrade to bleeding edge 
MediaWiki, which they probably won't do anyway considering they haven't even 
upgraded their Debian. :P

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

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

Re: [Wikitech-l] Min php version

[Tyler Romeo]

Just as a counter-argument (and, to be clear, I do support raising our minimum 
version), just because PHP has EOL'ed a version does not mean that some 
distributions (esp. Debian, Ubuntu) are not providing additional support and 
security updates.

If I remember from the last time we had this discussion, it will still be a 
couple more months before PHP 5.3 is no longer supported by most major distros, 
and it will be a while before 5.4 is no longer supported.

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

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

Re: [Wikitech-l] [ Writing a MediaWiki extension for deployment ]

[Tyler Romeo]

For the record, Extension:TwoFactorAuthentication is deprecated and in the 
process of being merged into Extension:OATHAuth.

Also, I'd recommend, rather than making a brand new extension, just add Latch 
support into OATHAuth! :) I'm completely open to supporting new 2FA methods, 
and giving wiki administrators options in what they want to use.

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

On July 6, 2015 at 09:29:50, Pine W (wiki.p...@gmail.com) wrote:

I for one would be interested in moving that extension out of beta and
having an option in site configuration to require some or all users to have
two factor authentication enabled.

Pine
On Jul 6, 2015 9:20 AM, Alex Monk kren...@gmail.com wrote:

 We use https://www.mediawiki.org/wiki/Extension:OATHAuth on
 wikitech.wikimedia.org
 https://www.mediawiki.org/wiki/Extension:TwoFactorAuthentication also
 exists

 On 6 July 2015 at 17:14, Paula paula...@gmail.com wrote:

  Hello,
  I'm writing an extension for MediaWiki so users can use a second factor
  authentication in their MediaWiki accounts.
 
  I would like to know if there is any project on this topic, or if there
 is
  already someone working on something like this.
 
  I'm planning on working in a MediaWiki extension that uses Latch (
  https://latch.elevenpaths.com/www/service.html ) as a second factor.
 
  This is my first time collaborating on a project this size so any advice
  will be very welcome.
 
 
 
  ​Thank you for your time.
 
  Cheers,
  Paula.
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

Re: [Wikitech-l] Please Review These Patches

[Tyler Romeo]

Will do some time this week. My semester has been a little crazy so I had to 
put it on the side.

-- 
Tyler Romeo
0x405D34A7C86B42DF

On April 21, 2015 at 07:44:07, John Erling Blad (jeb...@gmail.com) wrote:

Can you do a followup on replies on the patches?
Is there an open issue on OATH on enwiki?

On Wed, Jan 28, 2015 at 3:11 AM, Tyler Romeo tylerro...@gmail.com wrote:
 I don’t usually email the list for this kind of stuff, but if you have some 
 spare time to test an extension, please check out this patch chain. I’d like 
 to get it merged before May (when they become a year old).

 In order of dependency:
 https://gerrit.wikimedia.org/r/132783
 https://gerrit.wikimedia.org/r/132784
 https://gerrit.wikimedia.org/r/134050
 https://gerrit.wikimedia.org/r/134789
 https://gerrit.wikimedia.org/r/135597

 As a description, these five patches severely refactor Extension:OATHAuth, in 
 hopes that I can try and get it deployed on wiki so that enwiki users can use 
 two factor authentication.

 Thanks,
 --
 Tyler Romeo
 0x405D34A7C86B42DF

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

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

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

Re: [Wikitech-l] Tor proxy with blinded tokens

[Tyler Romeo]

Unless the status quo has changed recently, or there was some cryptographic 
achievement that provides a solution not already provided, I doubt this thread 
is going to make any progress beyond reiteration of the same back-and-forth 
that happens every time this thread pops up.

(Also, I don’t think relying on SMS verification is going to provide much faith 
for users competing against governments to hide their identity.)

-- 
Tyler Romeo
0x405D34A7C86B42DF

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

Re: [Wikitech-l] [RfC] AuthManager

[Tyler Romeo]

The primary vision I had with this RFC was to separate the idea of a
MediaWiki user and an external authentication provider.

In other words, an individual is logging in as a local user, and that
user may be associated with one or more external users. Each external
user is linked via a provider that can authenticate the external user's
credentials and give the users' groups from the authorization provider.

The reason behind this separation is to allow a bit more abstraction
between the local authentication layer and the actual verification of
credentials.

Regards,
-- 
Tyler Romeo

On 2/27/15 08:57, Legoktm wrote:
 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




signature.asc
Description: OpenPGP digital signature
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Extension:Newsletter seeks co-mentor or hackathon buddy

[Tyler Romeo]

This sounds like a pretty cool idea to work on. I'll leave some comments on
the Phabricator task.

*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science

On Thu, Feb 26, 2015 at 6:15 AM, Quim Gil q...@wikimedia.org wrote:

 The day Extension:Newsletter is deployed, everybody will ask themselves why
 didn't we have this feature before.

 While this happens, I keep trying to find a GSoC / Outreach co-mentor, and
 now a hackathon buddy in Lyon just in case this alternative model works
 better. Someone willing to write a prototype of this MediaWiki extension.

 I have a clear idea of what we need and I can help sketching the UI,
 writing strings, testing, discussing improvements, promoting the features,
 perhaps even recruiting more people. If you are interested, please check

 Possible Project for a Newsletter MediaWiki extension
 https://phabricator.wikimedia.org/T76199

 Public / private questions and feedback are very welcome!

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

Re: [Wikitech-l] E-mail login to wiki - needs feedback

[Tyler Romeo]

I would rather avoid this approach, because it involves running multiple
(sometimes as many as 5) password hashing operations. The idea of our
current key stretching with bcrypt is that the strength parameter should
be just large enough to not affect UX. But if we're running the hash
many times, now we have to reduce the bcrypt strength, and as a result
reduce our defenses against other attacks.

If we just always check one email address, not only do we fulfill most
users' use cases (a single account with their email), but we avoid
adopting any complicated cryptosystem and keep our password hashing as
simple as possible.

-- 
Tyler Romeo

On 2/19/15 08:36, Daniel Friesen wrote:
 I described an alternate idea on how to avoid timing attacks without
 limiting it to one account per address.
 https://www.mediawiki.org/wiki/Thread:Talk:Requests_for_comment/Login_via_e-mail_address/Timing_attacks_on_emails_with_multiple_accounts

 ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]

 On 2015-02-19 5:27 AM, Tyler Romeo wrote:
 I've said this previously, but I believe the only controversial part of
 this change is ensuring the security and privacy of email addresses.

 All this involves is constructing a process where every login,
 regardless of the identifier and regardless of the database state,
 always performs one and exactly one database query and one and exactly
 one password hashing.

 On 2/19/15 07:54, Tony Thomas wrote:
 Hello,

 Before someone starts with a proposal for the proposed-tech-project 'Allow
 user login with e-mail address'[1], is there still community consensus for
 the same ? I personally think its a must-have for MediaWiki, as e-mail
 address is easy to remember than a complex username. Currently multiple
 users can sign-up with the same e-mail id - which would possibly be a
 blocker, and can be fixed. Thanks to MzMcbride, we have an RFC[2] too on
 the same.

 [1] https://phabricator.wikimedia.org/T30085
 [2]
 https://www.mediawiki.org/wiki/Requests_for_comment/Login_via_e-mail_address

 Thanks,
 Tony Thomas http://tttwrites.wordpress.com/
 FOSS@Amrita http://foss.amrita.ac.in

 *where there is a wifi, there is a way*
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l


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




signature.asc
Description: OpenPGP digital signature
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] E-mail login to wiki - needs feedback

[Tyler Romeo]

I've said this previously, but I believe the only controversial part of
this change is ensuring the security and privacy of email addresses.

All this involves is constructing a process where every login,
regardless of the identifier and regardless of the database state,
always performs one and exactly one database query and one and exactly
one password hashing.

On 2/19/15 07:54, Tony Thomas wrote:
 Hello,

 Before someone starts with a proposal for the proposed-tech-project 'Allow
 user login with e-mail address'[1], is there still community consensus for
 the same ? I personally think its a must-have for MediaWiki, as e-mail
 address is easy to remember than a complex username. Currently multiple
 users can sign-up with the same e-mail id - which would possibly be a
 blocker, and can be fixed. Thanks to MzMcbride, we have an RFC[2] too on
 the same.

 [1] https://phabricator.wikimedia.org/T30085
 [2]
 https://www.mediawiki.org/wiki/Requests_for_comment/Login_via_e-mail_address

 Thanks,
 Tony Thomas http://tttwrites.wordpress.com/
 FOSS@Amrita http://foss.amrita.ac.in

 *where there is a wifi, there is a way*
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




signature.asc
Description: OpenPGP digital signature
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] GPL upgrading to version 3

[Tyler Romeo]

On February 11, 2015 at 11:49:15, Bryan Davis (bd...@wikimedia.org) wrote:
On Tue, Feb 10, 2015 at 8:48 PM, Tyler Romeo tylerro...@gmail.com wrote:
 What is more important: allowing as many people to use our libraries as 
 possible, or protecting against our libraries from being used in proprietary 
 software.

For me, allowing as many people to use our libraries as possible.
For the sake of the discussion, why?

For me, the advantages outweigh the disadvantages. The advantage of getting 
more companies to use our libraries is that (maybe) they will contribute back, 
similar to what Apple does with LLVM. However, on the other side of the same 
coin, we are allowing the possibility that companies will *not* contribute 
back, and instead keep their improvements to themselves (to be clear, I am not 
implying malicious intent).

-- 
Tyler Romeo
0x405D34A7C86B42DF



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

Re: [Wikitech-l] GPL upgrading to version 3

[Tyler Romeo]

On February 11, 2015 at 12:53:54, C. Scott Ananian (canan...@wikimedia.org) 
wrote:
On Tue, Feb 10, 2015 at 10:48 PM, Tyler Romeo tylerro...@gmail.com wrote:

 I’m still not entirely convinced that the GPLv2 allows more licenses than
 the v3.


GPL v2+ is a superset of GPL v3. I don't know why you find that so hard to
understand.

Well, if you read your own email...

 [...] I do not think it is possible to add Apache code into MediaWiki core
 and still allow licensing MediaWiki under both the v2 and the v3.


Yes, that is the case. Accepting Apache code into core should be treated
the same as accepting GPL v3-only code into core. Both significantly
restrict the licensing of the combined work.
--scott

Like I’ve been saying, GPLv2 and GPLv3 are separate licenses, and thus cannot 
be combined. You are using one or the other. GPLv2+ is not a superset. And, as 
a result, since MediaWiki is licensed under the v2+ rather than v3, we cannot 
accept Apache-licensed code into core.

I’m not sure how you see this as being more restrictive, considering it 
actually reduces the number of licenses that are compatible with core, and thus 
reduces the number of libraries we can add into core. As of right now, we 
cannot bring Apache-licensed third party libraries into core. However, if we 
upgrade to v3, we can.

(And, as an addendum, since most GPLv2 works are licensed like MediaWiki is, 
“GPLv2 or any later version”, upgrading MediaWiki to v3 will not stop us from 
using most GPLv2 libraries anyway.)

-- 
Tyler Romeo
0x405D34A7C86B42DF




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

Re: [Wikitech-l] GPL upgrading to version 3

[Tyler Romeo]

On February 11, 2015 at 15:32:00, Ryan Lane (rlan...@gmail.com) wrote:
Companies don't need to give back with GPL either, even if they make mods.
They only need to do so if they distribute. There's lots of Apache2
projects that have a very large amount of contribution, so maybe this would
happen, but I doubt it. Not having to maintain your own fork is a really
strong motivator for most companies.
This is true.

I guess it’s just a result of the sort of mixture of two arguments: whether to 
upgrade to v3, and whether to change to AGPL. In the latter, argument, even 
then companies are not required to give back, but one could argue that they are 
almost forced to since they must offer source code to all end-users anyway.

-- 
Tyler Romeo
0x405D34A7C86B42DF



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

Re: [Wikitech-l] GPL upgrading to version 3

[Tyler Romeo]

I’m still not entirely convinced that the GPLv2 allows more licenses than the 
v3. Yeah, maybe in the case of extensions it’s OK, but I do not think it is 
possible to add Apache code into MediaWiki core and still allow licensing 
MediaWiki under both the v2 and the v3.

Maybe if legal can provide an explanation, but at this point so many people are 
dying to use a permissive license that I doubt anything is ever going to change.


Also, I understand everybody seems to be worried about using the AGPL in 
libraries because then the libraries cannot be used by outside companies in 
proprietary software. But at that point it’s really just a difference in 
opinion. What is more important: allowing as many people to use our libraries 
as possible, or protecting against our libraries from being used in proprietary 
software.

-- 
Tyler Romeo
0x405D34A7C86B42DF

On February 10, 2015 at 18:23:32, David Gerard (dger...@gmail.com) wrote:

On 10 February 2015 at 23:19, Bryan Tong Minh bryan.tongm...@gmail.com wrote:

 In fact I would prefer to go to a less restrictive license, but that is
 probably not worth the fight.


And is also infeasible. For a web service. GPL is effectively weak
copyleft already; I think that's quite weak enough. (As I noted, there
is no actual evidence that permissive licenses secure more
contributions than copyleft, and some evidence the other way; despite
fans of permissive licenses repeating the claims ad nauseam over the
last fifteen years, they're notably short on examples.)


- d.

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

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

Re: [Wikitech-l] GPL upgrading to version 3

[Tyler Romeo]

This entire conversation is a bit disappointing, mainly because I am a 
supporter of the free software movement, and like to believe that users should 
have a right to see the source code of software they use. Obviously not 
everybody feels this way and not everybody is going to support the free 
software movement, but I can assure you I personally have no plans on 
contributing to any WMF project that is Apache licensed, but at the very least 
MediaWiki core is still GPLv2, even if it makes things a bit more difficult.

Also, I have no idea how the MPL works, but I can assure you that licensing 
under the “GPLv2 or any later version” cannot possibly imply it is available 
under both the v2 and v3. The different GPL versions have conflicting terms. 
You cannot possibly use the terms of the v2 and v3 simultaneously. It is 
legally impossible. What is means is that you can use the software under the 
terms of the v2 *or* the v3. And, as I mentioned, since Apache is only 
compatible with v3, as long as using the software under the v2 is an option, 
you cannot combine code that is under Apache.

-- 
Tyler Romeo
0x405D34A7C86B42DF

On February 9, 2015 at 04:06:54, David Gerard (dger...@gmail.com) wrote:

On 9 February 2015 at 08:28, Max Semenik maxsem.w...@gmail.com wrote:

 OpenOffice's woes are unrelated to its license, it was already dead by
 forking when Oracle transferred it to Apache, facilitating a change from
 GPL+proprietary CLA to the Apache license.



Indeed, but they touted the mythical attractiveness of a permissive
license over the bondage of copyleft. And it didn't work that way at
all in practice.

Again: data, rather than anecdote or surmise? As far as I can tell,
the claim that permissive attracts more contributions than copyleft is
entirely a myth.


- d.

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

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

Re: [Wikitech-l] GPL upgrading to version 3

[Tyler Romeo]

On February 9, 2015 at 15:17:22, Ryan Lane (rlan...@gmail.com) wrote:
You're implying that Apache2 licensed software is somehow not part of the
free software movement and that's absurd. Apache2 is technically a freer
license than GPLv(anything). Like GPL3, it also provides patent protection.
In practice it doesn't matter if software is forked and closed if the
canonical source isn't. The org that forks must maintain their fork and all
of their modifications without help. It's onerous and generally
unmaintainable for most orgs, especially if their core business isn't based
on the software, or if the canonical source is fast moving.
Please don’t spread misinformation to those who don’t know any better. The goal 
of the free software movement is to ensure the freedoms of end users to see the 
source code of the software they use. Any license that allows distributors to 
deny users this right is not actually protecting the goal of the movement. To 
be clear, software can be free without specifically supporting the free 
software movement.

The GPLv3 was specifically developed to make distributor enforcement of the 
GPLv3 easier. Rather than requiring third-parties to give out source code on a 
physical medium, which, as you mentioned, is onerous for many organizations, 
the newer license is more lax.

It's your choice to not participate in any project for any reason, but try
to understand that some people (such as myself) much prefer to work on
software that's truly free, rather than virally free.
I hope you don’t seriously think GPL software is not “truly free”.

-- 
Tyler Romeo
0x405D34A7C86B42DF



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

Re: [Wikitech-l] GPL upgrading to version 3

[Tyler Romeo]

On February 8, 2015 at 03:47:26, Max Semenik (maxsem.w...@gmail.com) wrote:

Honestly, I'm no big fan of strongly copyleft licenses, especially AGPL. In
addition to scaring off corporate users (yes, even soulless for-profit
drones deserve the right to use FLOSS), it creates a lot of uncertainty
even for open source users. I would personally prefer something much
permissive like MIT style.
The GPL does not stop companies from using open source software. It only stops 
them from modifying open source software and then making it proprietary. 
There’s no way we’re going to switch to a license like MIT that does not 
actually support the free software movement. (Also, we actually can’t switch to 
the MIT license without express permissions from every developer who ever 
contributed to core anyway.)

-- 
Tyler Romeo
0x405D34A7C86B42DF




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

Re: [Wikitech-l] GPL upgrading to version 3

[Tyler Romeo]

On Sun, Feb 8, 2015 at 7:59 PM, Rob Lanphier ro...@wikimedia.org wrote:

 Our code is GPLv2 or later, which is the functional equivalent of
 being multi-licensed under GPLv2 and GPLv3 (and all later versions of
 the GPL)  Therefore, the set of licenses that GPLv2 or later is
 compatible with is a strict superset of the licenses that GPLv3 or
 later is compatible with.


This is not true. The GPLv2 and GPLv3 are incompatible licenses, and if you
read the actual license disclaimer, you will see it is not the functional
equivalent of having our code licensed under both.

Rather, what the disclaimer says is that our code is GPLv2 only, *but*,
anybody who modifies or distributes it is free to, at their discretion,
change the license to any later version of the GPL. You legally cannot have
both the GPLv2 and GPLv3 because they are conflicting in their terms.


 Two responses:
 1.  Because that makes our code incompatible with any GPLv2-only code out
 there.
 2.  Why is it a good idea?

 In general, our licensing choices should be driven by goals, and it's
 unclear what goals are met by moving to GPLv3.  It's also unclear what
 goals any version of the GPL is actually serving in this particular
 context (due to the nature of PHP server side code) but relicensing
 MediaWiki at this late stage (beyond v2-later version) is not really
 a practical option, so I don't feel the need to belabor this
 particular point.


I've already described the numerous changes and fixes that have been made
in the GPLv3, specifically easier enforcement due to changed policies on
infringement, better international wording, etc. If you'd like to dispute
any of the good ideas I've listed, then go ahead, but I think the
improvements v3 makes are more than enough of a goal.

As for your point on it being useless because of the server-side nature of
PHP, I semi-agree, which is why I proposed the AGPL, but nonetheless the
advantages of the v3 will still help distributors who download MediaWiki
from our site. The server-side nature of PHP has nothing to do with it.


 That decision isn't final, and in fact, as Gabriel noted on that bug,
 he's working with the other contributors to relicense it under the
 Apache 2.0 license, per a conversation that a bunch of us had at WMF.

 In general, we should think about what goal we're trying to address by
 using GPLv2+ or GPLv3+ or any other license for that matter.  My
 personal experience has been that any contribution that has been
 compelled by license rather than given of enlightened self interest is
 done grudgingly and in a rather useless fashion.  There are certainly
 copyleft success stories (e.g.
 http://en.wikipedia.org/wiki/OpenWrt), but for MediaWiki, it's
 unclear under what possible scenario we'd want to compel GPL
 compliance from anyone that wasn't already motivated to work with us
 as an upstream.

 In general, I believe we should move more of our licensing toward
 Apache 2.0.  It seems to provide a nice tradeoff between simplicity
 and providing some basic legal protections for the projects.


That is quite depressing to hear. MediaWiki is supposed to be an open
source software movement, so I would think one of the goals of our
community would be to preserve that and keep MediaWiki open source, but if
the WMF has some future goals to make its software proprietary, then I can
understand why we might want to aim toward something that allows that, such
as the permissive Apache 2.0.

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

Re: [Wikitech-l] GPL upgrading to version 3

[Tyler Romeo]

The GPLv3 is not more restrictive.

As I mentioned, if anything it’s more permissive, since it is compatible with 
more licenses, and because it allows distributors to add some certain 
additional clauses to the license at their discretion. If a developer wants to 
release their personal code under the Apache 2.0 license, they can do so and 
still contribute to MediaWiki. Or if a distributor wants to offer their own 
warranty on MediaWiki, they can.

Maybe it was a little presumptuous of me to bring up AGPL, because I’ll admit I 
even have bad feelings about it, especially considering the whole security 
patch issue.

However, if somebody would like to offer up an actual reason for why upgrading 
from v2 to v3 is a bad idea, I’m all ears.

(Also, some relevant links, it seems RESTBase is currently under AGPL, so we 
may eventually be enveloped by it anyway: 
https://phabricator.wikimedia.org/T78212.)
-- 
Tyler Romeo
0x405D34A7C86B42DF

On February 8, 2015 at 10:40:03, Thomas Mulhall (thomasmulhall...@yahoo.com) 
wrote:

GPLv3 is not a simple upgrade, it is merely a switch to a more
restrictive license.  It is quite unlikely to happen.

Each time the subject has been raised, we ended up with a license flame
war and no strong arguments to switch.

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

Re: [Wikitech-l] GPL upgrading to version 3

[Tyler Romeo]

On Sun, Feb 8, 2015 at 9:04 PM, Rob Lanphier ro...@wikimedia.org wrote:


 This is virtually identical to how the old MPL multi-licensing
 boilerplate is worded:
 https://www.mozilla.org/MPL/boilerplate-1.1/

 ...which is widely considered sufficient for GPL compatibility.


Not sure exactly what you mean. The MPL is compatible with both GPL 2.0 and
3.0. What I'm saying is that GPLv2 to GPLv3 is a one-way direction. Once
code is licensed under v3, you cannot go back to v2. The Apache license is
only compatible with v3, and code under v2 cannot be combined with Apache
code, so the only way to add in Apache code to a GPL project is if the
entire project is v3.


 My main point about not thinking too hard about GPLv3 specifically is
 because I'm generally a little skeptical about GPL's general
 applicability to our use case.


[...]

 Please assume good faith.

 There is absolutely no intention by the WMF to make our software
 proprietary.  The only reason we'd entertain a switch to a more
 permissive license is as a means of collaborating with entities
 (companies, individuals, and organizations) who might steer clear of
 GPL software but otherwise be good open source collaborators out of
 enlightened self interest.


I will assume good faith for the WMF. I was just making a quick jab; I know
the WMF is not going to make MediaWiki proprietary.

However, I will not assume good faith for every other software company out
there that may take MediaWiki, modify it or improve it in some way, and
then begin selling it as proprietary software. It's nice to think the world
is an ideal place where everybody shares their source code, but
unfortunately we are not living in the ideal, and in fact that is the
entire reason the GPL was written in the first place: in response to
companies acting in bad faith.

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

Re: [Wikitech-l] GPL upgrading to version 3

[Tyler Romeo]

I’ve been meaning to make this thread for a while. I also believe we should 
switch over to GPL 3.


== Reasons to switch ==

First, to address the reason of why, there are a couple of reasons.

Reference: 
https://www.softwarefreedom.org/resources/2014/SFLC-Guide_to_GPL_Compliance_2d_ed.html

=== Language changes ===

Much of the language of the license has been rewritten or changed. Specifically 
so that:

a) it is more international and not using US-specific wording (e.g., 
“conveying”); and
b) certain things have been clarified due to changes in the Internet and 
technology over time. 

As an example, GPLv2 requires that when distributing software that the source 
code be provided *on a physical medium*. The GPLv3 relaxes this and allows an 
offer of providing source code via network transmission, as we are doing right 
now.

=== License compatibility ===

The GPLv3 was adjusted so that it is compatible with more free software 
licenses. The Apache 2.0 license and the XFree86 license are only compatible 
with the GPLv3, not v2.

=== Termination upon infringement ===

This is actually a pretty important one. The GPLv2 has a clause that upon a 
licensee violating the GPL, their entire license is immediately terminated, and 
may only be reissued by the licensor. This is obviously a troublesome legal 
situation in FOSS projects because now a licensee has to seek permission to use 
the software from the possibly hundreds of contributors, each of whom is an 
individual and independent licensor for the software.

In GPLv3, this is fixed by allowing infringers to resume distribution of the 
software if they cease all violations. In other words, while the copyright 
holder can still, if they so desire, explicitly terminate the license after a 
violation, in most cases the licensee can make remedies and automatically 
continue distribution.

=== Addition FOSS protections ===

As other people have previously stated, the GPLv3 adds additional restrictions 
to protect against trademark law, patent law, and sub-licensing. I won’t go too 
much into it, because I don’t know the details, but it basically is an attempt 
to prevent the aforementioned from imposing additional restrictions on 
redistributors.



== What MediaWiki should do ==

=== Changing our license ===

Just to specifically address the process that would be involved, all our 
current code can be licensed under the GPLv2 or any later version. Thus it 
would be trivial to just “redistribute” all of the code under the GPLv3. Yes, 
all the original code would still be licensed under the GPLv2 as well, since 
that was what it was contributed under, but any copy obtained from the 
Wikimedia Foundation would be under v3 since that is what the WMF would be 
distributing.

In addition, by doing so we’d require all further changes to be contributed 
under the GPLv3 or a compatible license, which, as aforementioned, is actually 
more licenses than could be done under the v2.

=== Which license? ===

I’m going to be honest, I think it is non-controversial to change over to 
GPLv3. It isn’t really more restrictive than v2 (patent law and DRM don’t 
really apply to us). If anything, it is actually an easier-to-implement 
license, since now the WMF has less responsibilities in terms of source code 
offering, etc.

**However**, I’d like to take this opportunity and jump a step further. What 
would everybody think of switching to the AGPLv3 instead? The advantage that 
this provides, for those who don’t know, is a single additional restriction: 
when the software is used over the network, source code must still be provided. 
In other words, the requirements all remain the same (providing a copy of the 
source code, ensuring all modifications are also GPLed, etc.). The only 
difference is that the requirements take effect over the Internet rather than 
only when the software is distributed in object code form.

The situation this protects against specifically is if a vendor does the 
following:

1) Download MediaWiki
2) Make a change to the software that they want to keep secret
3) Run the new MediaWiki on their servers, but never give out the source code

Technically, this is compliant with the license, because a distributor only has 
to provide corresponding source code if a user is given object code, which in 
the case of a web application, they are not. The AGPL protects against this by 
requiring provision of source code to the end-user web clients. Of course, the 
source code can be “provided” in the form of a simple link to another website 
on which to download the code.

-- 
Tyler Romeo
0x405D34A7C86B42DF

On February 7, 2015 at 16:08:16, Bartosz Dziewoński (matma@gmail.com) wrote:

MediaWiki is already available under GPL 2 *or any later version*. Why  
would we want to disallow distribution under GPL 2?

(Not that it's even possible. We could only state that new changes to  
MediaWiki code are only available on GPL 3+, we can't re-license existing  
code

Re: [Wikitech-l] GPL upgrading to version 3

[Tyler Romeo]

One thing to point out is that:

1) Even right now, under the GPL, if extensions do qualify as “derivative 
works” or w/e, they do have to be GPL licensed.
2) Source code only has to be provided to users of the program. So presuming 
this is some private wiki with a secret extension, source code does not have to 
be provided or published to the general public.

-- 
Tyler Romeo
0x405D34A7C86B42DF

On February 7, 2015 at 18:49:29, David Gerard (dger...@gmail.com) wrote:

On 7 February 2015 at 23:39, wctaiwan wctaiwan+li...@gmail.com wrote:

 IANAL, but if there is some flexibility here, I would argue that extensions
 should *not* be considered derivatives. Legally, because extensions do not
 contain MediaWiki code (beyond using the programming API provided by core
 classes);


Ah, good! Yeah, programming to a provided and documented API should be
fine. (With WordPress, themes and plugins are very much programs
running in the same process, etc.)


 in practice, because we have many extensions licensed under
 licenses that are incompatible with GPL,[1] and I don't think we should
 require people to choose a GPL-compatible licence should they want to write
 MediaWiki extensions.
 [1] http://www.mediawiki.org/wiki/Category:MIT_licensed_extensions



- d.

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

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

Re: [Wikitech-l] GPL upgrading to version 3

[Tyler Romeo]

Assuming they are using unmodified MediaWiki, yes a link to mediawiki.org
would probably suffice. I am going to look more into it, but what we have
right now (link in the footer and extension information on Special:Version)
should fulfill compliance automatically for third parties.

-- 
Tyler Romeo
On Feb 7, 2015 6:00 PM, David Gerard dger...@gmail.com wrote:

 On 7 February 2015 at 22:20, Tyler Romeo tylerro...@gmail.com wrote:

  **However**, I’d like to take this opportunity and jump a step further.
 What would everybody think of switching to the AGPLv3 instead? The
 advantage that this provides, for those who don’t know, is a single
 additional restriction: when the software is used over the network, source
 code must still be provided. In other words, the requirements all remain
 the same (providing a copy of the source code, ensuring all modifications
 are also GPLed, etc.). The only difference is that the requirements take
 effect over the Internet rather than only when the software is distributed
 in object code form.


 This would primarily affect third-party MediaWiki sites. Would a link
 to http://mediawiki.org/download be sufficient for AGPL compliance?
 (In the DFSG threat model of protecting a well-meaning reuser from a
 vindictive author.) Or, per the letter of the license, would we be
 required to keep a tarball on-site of what we're using?

 Also, how does GPLv3 or AGPL affect the license of extensions?


 - d.

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

Re: [Wikitech-l] [Engineering] DevSummit appreciation

[Tyler Romeo]

I have to say: I think the presentations this year were better than ever, and 
we definitely got a lot of important discussion done concerning the future of 
SOA and MediaWiki.

-- 
Tyler Romeo
0x405D34A7C86B42DF

On January 28, 2015 at 09:16:00, Brion Vibber (bvib...@wikimedia.org) wrote:

Agreed - we had a great space and good support, the WiFi worked, power
strips everywhere, and there was always coffee. I can ask for little
more... ;)

Thanks also to our fellow attendees -- I had a lot of great conversations
and got a lot of data points to help set my work directions for the coming
months.

Everybody there was awesome even when we had contentious issues -- I want
to thank everybody for having a positive attitude and working together.

-- brion
On Jan 27, 2015 10:44 PM, Erik Moeller e...@wikimedia.org wrote:

 Just a quick note that I really appreciated everyone's help making the
 summit come together. As always, we'll be doing lots of second-guessing of
 everything we did and didn't do, and how we want to use future time
 together. Before we go into that, I'd like to thank the event team and
 _everyone_ who worked to and beyond the point of exhaustion to organize the
 event, support attendees, plan sessions, facilitate conversations,
 negotiate sometimes difficult terrain.

 Thank you. :)

 Erik

 --
 Erik Möller
 VP of Product  Strategy, Wikimedia Foundation

 ___
 Engineering mailing list
 engineer...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/engineering


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

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

[Wikitech-l] Please Review These Patches

[Tyler Romeo]

I don’t usually email the list for this kind of stuff, but if you have some 
spare time to test an extension, please check out this patch chain. I’d like to 
get it merged before May (when they become a year old).

In order of dependency:
https://gerrit.wikimedia.org/r/132783
https://gerrit.wikimedia.org/r/132784
https://gerrit.wikimedia.org/r/134050
https://gerrit.wikimedia.org/r/134789
https://gerrit.wikimedia.org/r/135597

As a description, these five patches severely refactor Extension:OATHAuth, in 
hopes that I can try and get it deployed on wiki so that enwiki users can use 
two factor authentication.

Thanks,
-- 
Tyler Romeo
0x405D34A7C86B42DF


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

Re: [Wikitech-l] Fwd: No more Architecture Committee?

[Tyler Romeo]

Ah, I see. Yeah then it was just a misunderstanding. I completely agree with 
you on that point. I would be fine with an entirely-WMF ArchCom as long as 
being in the WMF was not one of the criteria they were selected because of.

-- 
Tyler Romeo
0x405D34A7C86B42DF

On January 22, 2015 at 17:51:59, Brian Wolff (bawo...@gmail.com) wrote:

I apologize, i didnt mean to imply non wmf employees are any less bright
than wmf employees.

What i more meant to say (which i didnt express very well) is that the arch
comitte (essentially bdfl by comittee in my understanding. Not just about
architecture but also vision for mediawiki) should be composed of leaders
of the community who have been in the mediawiki community a long time, and
have fairly universal respect due to demonstrating wisdom over the long
term.

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

Re: [Wikitech-l] Fwd: No more Architecture Committee?

[Tyler Romeo]

I think that’s kind of insulting to those of us who don’t work at the WMF. Just 
because they hire the “best and the brightest” does not mean there are not 
people out there who are just as intelligent, if not more, but do not or cannot 
work for the WMF for whatever reason. Restricting Archcom to WMF employees is 
just about the stupidest thing you could do for an open source software 
project. It defeats the entire purpose of MediaWiki being open-source.

-- 
Tyler Romeo
0x405D34A7C86B42DF

On January 22, 2015 at 06:31:29, Brian Wolff (bawo...@gmail.com) wrote:

I dont know if this is practical. As Chad noted earlier, WMF hires the best
and the brightest. Even if the entire arch comitte was hit by a bus, the
people who i think would logically be next in line are still employed by
wmf. Even if those people got hit by a bus, i still think their logical
replacements would largely be wmf employees.

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

Re: [Wikitech-l] new extension

[Tyler Romeo]

On Wed, Dec 17, 2014 at 11:57 AM, Ricordisamoa ricordisa...@openmailbox.org
 wrote:

  * Given that the W3C Validator can also parse HTML files, would it be
useful to validate wiki pages as well? Even if sometimes the
validation errors appear to be caused by MediaWiki itself, they can
also depend on malformed templates.


Meh not sure how useful this would be. Maybe as a developer tool, but not
something you would want running on your site. The SVG validation tool
makes sense because you're validating user input.


  * Does storing the validation status of old revisions of images
(and/or articles) make sense?


I don't think there's any harm in it. Better to have extraneous information
then to wait until users complain about not having it down the line.


  * Do you think the extension should use the extmetadata property of
ApiQueryImageInfo instead of a its own module?
  * Is it advisable to store validation data permanently in the database?


I have no idea about this, but it does seem that the metadata is propagated
to the oldimage table when a new one is uploaded, so it would fulfill your
above question about storing old revisions' validation status.

Exactly what information is being stored? Is it just a flag that says valid
or not valid? Is it a list of errors and warnings? If so what format is it
all in?

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

Re: [Wikitech-l] Getting the full URL of an image

[Tyler Romeo]

Somebody can correct me, but:

$title = Title::makeTitle( NS_FILE, $filename );
$file = wfLocalFile( $title );
$file-getUrl();
// $file-getFullUrl();
// ...


*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science

On Mon, Jan 19, 2015 at 1:45 PM, Jeroen De Dauw jeroended...@gmail.com
wrote:

 Hey,

 On my local wiki I have a page with the name File:Blue marker.png. The
 following code returns false:

 $title = Title::makeTitle( NS_FILE, $file );
 $title-exists();

 That used to return true in the past. Not sure what is broken - my wiki or
 MediaWiki itself.

 What I want to do is go from string page name, such as File:Blue
 marker.png, to full URL, such as 
 http://localhost/phase3/images/6/6f/Blue_marker.png;. What is the
 recommended way of doing this now (that works on MW 1.19 and later)?

 Cheers

 --
 Jeroen De Dauw - http://www.bn2vs.com
 Software craftsmanship advocate
 Evil software architect at Wikimedia Germany
 ~=[,,_,,]:3
 ___
 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] Fwd: No more Architecture Committee?

[Tyler Romeo]

 and planning, rather 
than
just throwing five people into a room and telling them to get to work.

-- 
Tyler Romeo
0x405D34A7C86B42DF


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

Re: [Wikitech-l] Fwd: No more Architecture Committee?

[Tyler Romeo]

On January 16, 2015 at 11:59:14, Chad (innocentkil...@gmail.com) wrote:
It's hard to have a community when we keep hiring everyone out of it.
We should use this as an advertising point. “Come contribute to MediaWiki, 
there’s a pretty high percentage we’ll hire you.” :P

-- 
Tyler Romeo
0x405D34A7C86B42DF


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

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

[Tyler Romeo]

The relevant link: https://www.mediawiki.org/wiki/Manual:$wgUpgradeKey
-- 
Tyler Romeo
0x405D34A7C86B42DF

On January 13, 2015 at 13:36:10, Chad (innocentkil...@gmail.com) wrote:

The installer can be run on an existing install and
updates will be run.

-Chad

On Tue Jan 13 2015 at 10:30:00 AM Ryan Kaldari rkald...@wikimedia.org
wrote:

 This may be a dumb question, but has anyone worked on creating a web
 interface for running update and maintenance scripts (and viewing
 associated logs)? That would probably make the whole process less painful
 and confusing for 3rd party users, especially if the interface offered some
 guidance on what each script did and when it was last run.

 Kaldari

 On Tue, Jan 13, 2015 at 9:08 AM, Bryan Davis bd...@wikimedia.org 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.
 
 
   On January 13, 2015 at 08:07:34, Marcin Cieslak (sa...@saper.info)
  wrote:
  
   I am kind of late to the party but I have upgraded one of
   my throaway development wikis with the usual
   git remote update  git merge  php maintenance/update.php process
   and after the above succeeded I was nevertheless greeted by:
  
   Fatal error: Class 'Cdb\Reader' not found
  
   exception coming out of includes/cache/LocalisationCache.php on line
 1263
  
   It seems that I just forgot to update the vendor directory
   (I am somehow reluctant to run composer due to allow_url_fopen=1)
   requirement
  
   Would that be reasonable to add some basic external libraries
   checks to update.php to remind users to update those core
   components prior to accessing the wiki?
  
   Btw. I think UPGRADE doc does not (yet) mention the new process.
 
  I think that Kunal's thinking on this (Composer and UPGRADE) was that
  when the 1.25 tarballs are released they will likely bundle the
  required libraries directly and thus use of Composer will not be
  needed by the end user. There is a sentence in the Git subsection of
  https://www.mediawiki.org/wiki/Manual:Upgrading mentioning the
  external library dependency:
   If you are upgrading to MediaWiki 1.25 or later, you will also need to
  install some external libraries. See the documentation on that for more
  details.
 
  Maybe that needs a bit more emphasis on the wiki page?
 
  Bryan
  --
  Bryan Davis Wikimedia Foundation bd...@wikimedia.org
  [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA
  irc: bd808 v:415.839.6885 x6855
 
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

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

[Tyler Romeo]

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.

-- 
Tyler Romeo
0x405D34A7C86B42DF

On January 13, 2015 at 08:07:34, Marcin Cieslak (sa...@saper.info) wrote:

I am kind of late to the party but I have upgraded one of
my throaway development wikis with the usual  
git remote update  git merge  php maintenance/update.php process
and after the above succeeded I was nevertheless greeted by:

Fatal error: Class 'Cdb\Reader' not found  

exception coming out of includes/cache/LocalisationCache.php on line 1263

It seems that I just forgot to update the vendor directory
(I am somehow reluctant to run composer due to allow_url_fopen=1)
requirement

Would that be reasonable to add some basic external libraries
checks to update.php to remind users to update those core
components prior to accessing the wiki?

Btw. I think UPGRADE doc does not (yet) mention the new process.

//Marcin


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

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

Re: [Wikitech-l] Fwd: Unsolicited digital currency donations

[Tyler Romeo]

Link for those interested:
http://prime4commit.com/projects/208

I really dislike these kinds of sites. It’d be one thing if it was just 
donations, but developers can claim their tips and basically get paid for each 
commit, and it rubs me the wrong way gameifying our volunteer community like 
that. Then again, it’s just my opinion.

-- 
Tyler Romeo
0x405D34A7C86B42DF

On January 9, 2015 at 03:10:35, Federico Leva (Nemo) (nemow...@gmail.com) wrote:

Website garnering registrations by donating few cents of dollar for  
each merged commit. They started a while ago but looks like it's  
expanding. Just FYI in case you've not received one yet.

Nemo

 Messaggio inoltrato 
Oggetto: You received a tip for your commit
Data: Fri, 09 Jan 2015 07:36:52 +


Hello, Federico Leva!

You were tipped 0.11 XPM for your commit on Project wikimedia/mediawiki.
Please, log in and tell us your primecoin address to get it.

Your current balance is 0.11 XPM. If you don't enter a primecoin address
your tips will be returned to the project in 30 days.

Sign In

Thanks for contributing to Open Source!


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

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

[Wikitech-l] MediaWiki Technical Debt

[Tyler Romeo]

Found this today: https://twitter.com/symfony_en/status/525222757567827968

It's probably a useless statistic, but I still found it amusing. Good to
know we still have less technical debt than WordPress. ;)

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

Re: [Wikitech-l] MediaWiki Technical Debt

[Tyler Romeo]

Much agreed on this. I tried out SensioLabsInsight once or twice, and overall 
it has never given me anything useful that PhpStorm’s built-in inspections did 
not already catch.

-- 
Tyler Romeo
0x405D34A7C86B42DF

On October 23, 2014 at 11:17:22, Jeroen De Dauw (jeroended...@gmail.com) wrote:

It's based on SensioLabsInsight, which I personally quite dislike.
ScrutinizerCI is hands down better at spotting issues (way to many false
positives on SensioLabsInsight).
___
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)

[Tyler Romeo]

On Sun, Oct 12, 2014 at 3:24 AM, Arlo Breault abrea...@wikimedia.org
wrote:

 Proposal:


Unless there is further discussion to be had on a new *technical* solution
to Tor users, this is the wrong mailing list to be making these proposals.
At the very least take it to the main wikimedia list, or on-wiki, where
this is a lot more relevant.

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

Re: [Wikitech-l] RFC meeting this week

[Tyler Romeo]

If at all possible, if you could discuss Extension registration second, I would 
really appreciate it. I have something until 21:30 UTC so I will only be able 
to be online in the second half of the meeting.

-- 
Tyler Romeo
0x405D34A7C86B42DF

On October 6, 2014 at 22:08:47, Tim Starling (tstarl...@wikimedia.org) wrote:

The next RFC meeting will discuss the following RFCs:

* Extension registration
https://www.mediawiki.org/wiki/Requests_for_comment/Extension_registration

* Change LESS compilation library
https://www.mediawiki.org/wiki/Requests_for_comment/Change_LESS_compilation_library

The meeting will be on the IRC channel #wikimedia-office on
irc.freenode.org at the following time:

* UTC: Wednesday 21:00
* US PDT: Wednesday 14:00
* Europe CEST: Wednesday 23:00
* Australia AEST: Thursday 07:00

-- Tim Starling


___
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] Tor exit node rejects port 443 of WM, but it is disabled for editing

[Tyler Romeo]

Well you can also edit from port 80 (unless we deployed site-wide SSL without 
me knowing).

Has a bug been filed for this? This sounds like an Extension:TorBlock issue 
(and is also probably my fault in some manner assuming this is a regression, 
which it may or may not be).

-- 
Tyler Romeo
0x405D34A7C86B42DF

On October 2, 2014 at 7:33:54, Rudolf Dovičín (rudolf.dovi...@gmail.com) wrote:

HTTPS, i.e. port 443, is the ONLY way to edit WikiMedia projects,
so I thing such servers (those reject port 443 of WikiMedia servers)
should by excluded from Public proxy blacklist of WikiMedia.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor exit node rejects port 443 of WM, but it is disabled for editing

[Tyler Romeo]

No, they are not usually allowed, but technically there should not be a problem 
with it, since if the exit policy does not allow traffic over port 80 or port 
443, Tor users cannot edit Wikipedia anyway. (The result is that only the 
operator can edit from that IP address.)

Also, the exit policy is verifiable via the node directory.

-- 
Tyler Romeo
0x405D34A7C86B42DF

On October 2, 2014 at 8:09:08, Derric Atzrott (datzr...@alizeepathology.com) 
wrote:

Are Tor exit relays that block access to Wikimedia in their rejection
policies usually allowed to edit Wikimedia projects?
___
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)

[Tyler Romeo]

I still believe that Nymble is the way to go here. It is the only solution
that
successfully allows negotiation of a secure collateral that can still be
blacklisted after abuse has occurred.

Although, as mentioned, it is all about the collateral. Making the user
provide
something that requires work to obtain.


*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science

On Tue, Sep 30, 2014 at 3:40 PM, Risker risker...@gmail.com wrote:

 Okay, so I have to ask.  What is this obsession with enabling TOR editing?

 Stewards are having to routinely disable significant IP ranges because of
 spamming/vandalism/obvious paid editing/etc through anonymizing proxies,
 open proxies, and VPNs - so I'm not really seeing a positive advantage in
 enabling an editing vector that would be as useful to block as the old AOL
 IPs.[1]  If the advocates of enabling TOR were all willing to come play
 whack-a-mole - and keep doing it, day in and day out, for years - there
 might be something to be said for it.  But it would be a terrible waste of
 a lot of talent, and I'm pretty sure none of you are all that interested in
 devoting your volunteer time that way.

 We know what the technical solution would be here: to turn the
 on/off switch to on.  Enabling TOR from a technical perspective is
 simple. Don't forget, while you're at it, to address the unregistered
 editing attribution conundrum that has always been the significant
 secondary issue.

 I'd encourage all of you to focus on technical ways to prevent
 abusive/inappropriate editing from all types of anonymizing edit platforms,
 including VPNs, sites like Anonymouse, etc.  TOR is but
 one editing vector that is similarly problematic, and it would boggle the
 minds of most users to discover that developers are more interested in
 enabling another of these vectors rather than thinking about how to prevent
 problems from the ones that are currently not systemically shut down.

 Risker/Anne


 [1] Historical note - back in the day, AOL used to reassign IPs with every
 new link accessed through the internet (i.e., new IP every time someone
 went to a new Wikipedia page).  It was impossible to block AOL vandals.
 This resulted in most of the known AOL IP ranges being blocked, since there
 was no other way to address the problem.



 On 30 September 2014 14:52, Brian Wolff bawo...@gmail.com wrote:

  On 9/30/14, Derric Atzrott datzr...@alizeepathology.com wrote:
   Alright, this is a long email, and it acts to basically summarise all
 of
  the
   discussions that have already happened on this topic.  I'll be posting
 a
   copy
   of it to Mediawiki.org as well so that it will be easier to find out
  about
   what has already been proposed in the future.
  
   There is a policy side to this, Meta has the No open proxies policy,
  which
   would need to be changed, but I doubt that such policies will be
 changed
   unless those of us on this list can come up with a good way to allow
 Tor
   users
   to edit.  If we can come up with a way that solves most of the problems
  the
   community has, then I think there is a good chance that this policy can
  be
   changed.
 
 
  I'd like to add an idea I've been thinking about to make TOR more
  acceptable.
 
  A big part of the problem is that there are hundreds (thousands?) of
  exit nodes, so if someone is being bad, they just have to wait 5
  minutes to get a new one, making it very hard to block them.
 
  So what we could do, is map all tor connections to appear (To MW) as
  if they are coming from a few private IP addresses. This way its easy
  to block temporarily (in case of a whole slew of vandalism comes in),
  the political decision on whether to block or not becomes a local
  problem (The best kind of solution to a problem is the type that makes
  it somebody else's problem ;) I would personally hope that admins
  would only give short term block to such an address during waves of
  vandalism, but ultimately it would be up to them.
 
  To be explicit, the potential idea is as follows:
   *User access via tor
  *MediaWiki sees its a tor request
  *Try to do limited browser fingerprinting, to perhaps mitigate the
  affect of an unclued user not using tor browser being bad ruining it
  for everyone. Say take a hash of the user-agent and various accept
  headers, and turn it into a number between 1 and 16.
  *Make MW think the IP is 172.16.0.number from previous step
 
  Then all the tor edits are all together, and easy to notice if
  somebody is abusing them, and easy for a local admin to block all at
  once if need be.
 
  This would also make most of the rate limiting apply against all
  people accessing via tor instead of doing rate limiting per exit node,
  which is probably a good thing, and would prevent repetitive abuse,
  people registering 10 billion accounts, etc. If we did this, we may
  also want to make pretty much every action trigger a captcha for those
  addresses (perhaps even

Re: [Wikitech-l] the three phases of patch review

[Tyler Romeo]

Great article.

As further reading for anybody who is interested, there is a book called “Best 
Kept Secrets of Peer Code Review”. It addresses the various methods of code 
review and how to best tune it for your project. (It’s available online 
somewhere.)

-- 
Tyler Romeo
0x405D34A7C86B42DF

On September 24, 2014 at 18:03:03, Sumana Harihareswara (suma...@wikimedia.org) 
wrote:

I just read
http://sarah.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/ and it
made a lot of sense to me as a way to speed up the first response a new
patch gets.

Instead of putting off reviewing first-time contributions and thoroughly
reviewing everything in the contribution at once, I propose a three-phase
review process for maintainers:

1. Is the idea behind the contribution sound?
2. Is the contribution architected correctly?
3. Is the contribution polished?

The post author, a Linux kernel developer, goes into more detail in the
post; it's worth reading even if you decide this approach isn't your style.

(Reminder: https://www.mediawiki.org/wiki/Gerrit/Code_review/Getting_reviews
and https://www.mediawiki.org/wiki/Gerrit/Code_review are worth
re-skimming.)

Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] I'm leaving the Wikimedia Foundation

[Tyler Romeo]

:'( Going to miss you Sumana! (Hopefully we can meet up in the city one
day.)

*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science

On Fri, Sep 12, 2014 at 2:08 PM, Jeroen De Dauw jeroended...@gmail.com
wrote:

 Hey Sumana,

 Thanks for writing that up and the bits of helpful advice you gave me over
 the years.

 And like Micru, I have to agree with this part:

 And I'd like to [...] exclude destructive communication from my life (yes,
  there's some amount of burnout on toxic people and entitlement).
 

 This is such a tragic waste on many levels. It's very hard to make real
 progress towards an organizations goals and have fun in doing so, if the
 environment contains to much of this. Even if every single person involved
 is putting effort towards those goals. You are definitely not the first
 person to leave the WMF (in part) because of this.

 Cheers

 --
 Jeroen De Dauw - http://www.bn2vs.com
 Software craftsmanship advocate
 Evil software architect at Wikimedia Germany
 ~=[,,_,,]:3
 ___
 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] RfC Discussions Today/Next week

[Tyler Romeo]

Well unfortunately I will not be able to attend either of these meetings 
(mainly since one of them was today). If somebody could make sure to mention 
third-party libraries on my behalf at the September 10th meeting, I would 
greatly appreciate it. (It would really be a facepalm if MediaWiki implemented 
its own ORM….again.)
-- 
Tyler Romeo
0x405D34A7C86B42DF

From: Rachel Farrand rfarr...@wikimedia.org
Reply: Wikimedia developers wikitech-l@lists.wikimedia.org
Date: September 3, 2014 at 14:08:22
To: Wikimedia developers wikitech-l@lists.wikimedia.org, Development and 
Operations engineers (WMF only) engineer...@lists.wikimedia.org
Subject:  [Wikitech-l] RfC Discussions Today/Next week  

Hello,
If you are interested in joining today's RfC discussion,
the Architecture Committee will be discussing the following RfCs:

* SOA Authentication (Chris Steipp)
https://www.mediawiki.org/wiki/Requests_for_comment/SOA_Authentication
* Server-side Javascript error logging (Gergő Tisza)
https://www.mediawiki.org/wiki/Requests_for_comment/Server-side_Javascript_error_logging

Wednesday, 03 September 2014, in #wikimedia-office on Freenode IRC,
21:00-22:00 UTC
*http://www.timeanddate.com/worldclock/fixedtime.html?msg=RFC+Meetingiso=20140903T14p1=224ah=1
http://www.timeanddate.com/worldclock/fixedtime.html?msg=RFC+Meetingiso=20140903T14p1=224ah=1*


*Proposed agenda for Sep 10: *
* Data Mapper (Andrew Green)
https://www.mediawiki.org/wiki/Requests_for_comment/Data_mapper
* Dependency injection (Andrew Green)
https://www.mediawiki.org/wiki/Requests_for_comment/Dependency_injection

Wednesday, 10 September 2014, in #wikimedia-office on Freenode IRC,
21:00-22:00 UTC
*http://www.timeanddate.com/worldclock/fixedtime.html?msg=RFC+Meeting+Sep+10iso=20140910T21p1=1440ah=1
http://www.timeanddate.com/worldclock/fixedtime.html?msg=RFC+Meeting+Sep+10iso=20140910T21p1=1440ah=1*

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

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

Re: [Wikitech-l] The future of skins

[Tyler Romeo]

On Tue, Aug 26, 2014 at 8:21 PM, Trevor Parscal tpars...@wikimedia.org
wrote:

 Thanks for summarizing the meeting Jon.

 So, let's get Twig/Swig into core then, eh? :)


Please yes. Twig is really powerful, pretty fast, and is supported by a
major company.

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

Re: [Wikitech-l] Using magic functions (e.g. __get) to deprecate class members

[Tyler Romeo]

My opinion on this matter is that if you were using a variable prefixed with 
“m”, which is clearly one of our conventions for declaring variables private, 
you are asking for trouble. Just recently when the password hashing API patch 
was merged, it caused problems with CentralAuth since it tried accessing 
mPassword directly.

In cases like this, I don’t think there’s any need for a deprecation period, 
because you are playing with fire in the first place.

Obviously, for other variables that don’t start with “m” and are not documented 
as @private or @protected, then we need the grace period.
-- 
Tyler Romeo
0x405D34A7C86B42DF

From: Stephan Gambke s7ep...@gmail.com
Reply: Wikimedia developers wikitech-l@lists.wikimedia.org
Date: August 22, 2014 at 18:33:24
To: Wikimedia developers wikitech-l@lists.wikimedia.org
Subject:  [Wikitech-l] Using magic functions (e.g. __get) to deprecate class 
members  

TL;DR: Please review [1]


I was asked to discuss the topic on the mailing list, so here goes.

Since some time Siebrand is making an effort to improve code quality by
making it phpcs-strict compliant [0]. This involves explicitly declaring
the visibility of class members.

Alas, intended or not, in very many cases he did not only explicitly
declare the class variable's visibility, but he also changed it from the
implicit 'public' to explicit 'protected' or 'private', thus introducing
a major API change without a proper deprecation period. Apparently this
was not noticed (or at least not challenged) by the reviewers. I checked
a few of his commits and they were all merged within hours.

Now, to be clear about that, I appreciate both changes - the phpcs
compliance as well as the more limited accessibility of class variables.
This was long overdue. However, to introduce something like this a
proper deprecation period is in my opinion essential, in particular
considering the extent of the changes. I do believe that Siebrand
checked that the variables he declared protected or private were not
used by extensions. However, he missed one (EditPage::mTokenOk) which
subsequently resulted in a bug in an extension (SemanticForms). Given
the number of the now newly hidden variables I am quite sure, that there
are other cases. If only because many extensions are not hosted on WMF
servers, so they can not be checked.

To keep the changes and still be able to properly deprecate the direct
access to the member variables I submitted a patch [1] that makes use of
PHP magic functions [2]. They provide access to the class members and
issue a deprecation warning. The intention is to keep these functions
for the custom two releases [3], i.e. until 1.26, and then remove them.

This patch was shot down for three reasons:
quote
* it duplicates code
* there is no tests
* our code base barely use the magic methods and I am pretty sure Tim
Starling commented a while back about them being nasty.
/quote

When I pointed out, that these functions are not re-entrant and thus
Tims warning [4] did not apply the answer was I have merely copy pasted
Tim comment without even attempting to understand what it means. I was
subsequently asked to present this to the mailing list which I do with
this mail.

I would appreciate comments on the patch (preferably constructive), that
would allow us to not revert Siebrand's changes and still properly
deprecate formerly public class members.

Thanks.

Stephan



[0]
https://gerrit.wikimedia.org/r/#/q/status:merged+project:mediawiki/core+branch:master+topic:phpcs,n,z
[1] https://gerrit.wikimedia.org/r/#/c/151370/
[2]
http://php.net/manual/en/language.oop5.overloading.php#language.oop5.overloading.members
[3] https://www.mediawiki.org/wiki/Deprecation
[4] https://www.mediawiki.org/wiki/Special:Code/MediaWiki/85288#c17504

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

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

Re: [Wikitech-l] [QA] Prettier Jenkins results in Gerrit

[Tyler Romeo]

Yeah just noticed this as well. An awesome change indeed; much easier to read 
and interpret. Thanks!
-- 
Tyler Romeo
0x405D34A7C86B42DF

From: James Forrester jforres...@wikimedia.org
Reply: Wikimedia developers wikitech-l@lists.wikimedia.org
Date: August 20, 2014 at 17:22:42
To: QA (software quality assurance) for Wikimedia projects. 
q...@lists.wikimedia.org
Cc: Wikimedia developers wikitech-l@lists.wikimedia.org
Subject:  Re: [Wikitech-l] [QA] Prettier Jenkins results in Gerrit  

On 20 August 2014 13:02, Antoine Musso hashar+...@free.fr wrote:

 Hello,

 The tests results being reported to Gerrit are now much nicer. The
 first ever example is https://gerrit.wikimedia.org/r/#/c/155341/


 James E. Blair from Openstack found a nice trick to inject HTML in
 Gerrit comment. Christian Aistleitner kindly reviewed and tested the
 regex, and further improved the craziness.

 Daniel Zahn deployed the change on spot a few minutes ago and we now
 have slightly nicer and more readable test results being reported.

 \O/

 Ref:
 https://bugzilla.wikimedia.org/66095


​Lovely! Thanks all.​

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

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

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

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

[Tyler Romeo]

Agreed with Aaron. When these proposed additional APIs are actually 
implemented, then we can start arguing about what to call them.

I know that I personally will continue to call the API the “core web API” or 
sometimes just the “web API”, if it is clear based on the context in which I am 
talking.
-- 
Tyler Romeo
0x405D34A7C86B42DF

From: Aaron Halfaker ahalfa...@wikimedia.org
Reply: Wikimedia developers wikitech-l@lists.wikimedia.org
Date: August 15, 2014 at 11:05:13
To: Wikimedia developers wikitech-l@lists.wikimedia.org
Cc: MediaWiki API announcements  discussion 
mediawiki-...@lists.wikimedia.org
Subject:  Re: [Wikitech-l] [Mediawiki-api] Bikeshedding a good name for the 
api.php API  

As a heavy user, I generally just refer to the things api.php does as the
API. or MediaWiki's web API when I'm feeling verbose.

I'd be confused about the action API since I generally use it to read
which isn't really action -- even though it corresponds to action=query

As for the proposed REST API, I don't think that proposed things should
affect the naming scheme of things we already know and love.

Also, I think that all bike sheds should match the color of the house to
(1) denote whose bike shed it is and (2) help tie the yard together like
furniture in a living room.


On Fri, Aug 15, 2014 at 3:50 PM, Sumana Harihareswara suma...@wikimedia.org
 wrote:

 I like action API.

 Sumana Harihareswara
 Senior Technical Writer
 Wikimedia Foundation


 On Thu, Aug 14, 2014 at 5:06 PM, Brad Jorsch (Anomie) 
 bjor...@wikimedia.org
  wrote:

  Summing up, it seems like action API and api.php are the two
  contenders.
 
  api.php is least likely to be confused with anything (only its own
 entry
  point file). But as a name it's somewhat awkward.
 
  action API might be confused with the Action class and its subclasses,
  although that doesn't seem like a big deal.
 
 
  As for the rest:
 
  Just API is already causing confusion. Although it'll certainly
 continue
  to be used in many contexts.
 
  MediaWiki API, Web API, and MediaWiki web API are liable to be
  confused with the proposed REST API, which is also supposed to be
  web-accessible and will theoretically part of MediaWiki (even though I'd
  guess it's probably going to be implemented as an -oid). MediaWiki web
  APIs may well grow to encompass the api.php action API, the REST API,
 and
  maybe even stuff like Parsoid.
 
  MediaWiki API and Core API are liable to be confused with the various
  hooks and PHP classes used by extensions.
 
  JSON API wouldn't be accurate for well into the future, and would
 likely
  be confused with other JSON-returning APIs such as Parsoid and maybe
 REST.
 
  Classic API makes it sound like there's a full replacement.
 
  All the code name suggestions would be making things less clear, not
 more.
  If it had started out with a code name there would be historical inertia,
  but using a code name now would just be silly.
 
 
  ___
  Mediawiki-api mailing list
  mediawiki-...@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
 
 
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

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

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

[Tyler Romeo]

It is probably considered a blocker for the GUI config RFC, since the 
Configuration stuff is needed in order to implement non-global configuration 
formats. With this new config system, configuring MediaWiki is likely to become 
a lot easier in the not-so-distant future.
-- 
Tyler Romeo
0x405D34A7C86B42DF

From: Sumana Harihareswara suma...@wikimedia.org
Reply: Wikimedia developers wikitech-l@lists.wikimedia.org
Date: August 15, 2014 at 11:19:21
To: Wikimedia developers wikitech-l@lists.wikimedia.org
Subject:  Re: [Wikitech-l] Configuration related things that happened at 
Wikimania  

Is this work related to
https://www.mediawiki.org/wiki/Requests_for_comment/Extension_registration
,
https://www.mediawiki.org/wiki/Requests_for_comment/Graphical_configuration_interface
, or any other Request for Comment, by the way?

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

[Wikitech-l] PHP 5.3 EOL and MediaWiki 1.24

[Tyler Romeo]

Hi everybody,

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

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

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

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

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

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

Thoughts?

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

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

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

[Tyler Romeo]

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

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

This.

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

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

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

[Tyler Romeo]

On Mon, Aug 11, 2014 at 12:24 PM, Tim Landscheidt t...@tim-landscheidt.de
wrote:

 {{cn}}


More like the attendees were those who could afford to go and/or were given
scholarship.

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

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

[Tyler Romeo]

So I'd just like to make one point, I think this superprotect right has
proper technical implications and use cases. In other words, while you guys
may disagree with how it is currently being used (e.g., the MediaViewer
drama and whatnot), I think it is a good idea, and I am actually surprised
such a protection level has not already been enacted.

There are many legitimate cases (e.g., office actions and copyright-related
issues) where I could see the superprotect level coming in handy. There are
some cases where the WMF simply cannot afford (usually b/c of legal
reasons) to trust the community, even if they're 99.9% sure nothing will
happen. Sometimes all it takes is one rogue admin to trigger a lawsuit.

With that said, it's obviously a political matter as to what the proper
uses of this new protection level are, but I do think the existence of the
level itself is appropriate.

*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science


On Sun, Aug 10, 2014 at 9:19 AM, K. Peachey p858sn...@gmail.com wrote:

 Lets all welcome the new overlord Erik.

 Add a new protection level called superprotect
 Assigned to nobody by default. Requested by Erik Möller for the purposes
 of protecting pages such that sysop permissions are not sufficient to


 edit them.
 Change-Id: Idfa211257dbacc7623d42393257de1525ff01e9e
 
 https://gerrit.wikimedia.org/r/#q,Idfa211257dbacc7623d42393257de1525ff01e9e,n,z
 

 https://gerrit.wikimedia.org/r/#/c/153302/



 Someone clearly can't take criticism of their projects well.
 ___
 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] Superprotect user right, Comming to a wiki near you

[Tyler Romeo]

No, it is not. Unless we are continuing to discuss the technical implications 
of this change, I suggest this be moved to wikimedia-l.

Also, can we please stop using Wikipedia templates in this thread (e.g., 
{{cc}}). Not everybody here is a Wikipedia editor and knows what they mean. I’d 
prefer not to have to look up templates online just to figure it out.
-- 
Tyler Romeo
0x405D34A7C86B42DF

From: Lewis Cawte lewisca...@googlemail.com
Reply: Wikimedia developers wikitech-l@lists.wikimedia.org
Date: August 11, 2014 at 13:56:11
To: Wikimedia developers wikitech-l@lists.wikimedia.org
Subject:  Re: [Wikitech-l] Superprotect user right, Comming to a wiki near you  

Is wikitech-l really the best place for this discussion?

-- Lewis Cawte (Lcawte)

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

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

[Tyler Romeo]

On Mon, Aug 11, 2014 at 6:54 PM, John Mark Vandenberg jay...@gmail.com
wrote:

 Was this functionality was ever supported by MediaWiki core?


Of course this is supported by MediaWiki core, although I cannot attest as
to whether it was previously implemented on WMF wikis.

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

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

[Tyler Romeo]

Wow this is pretty depressing, although in today's age I cannot say I'm
surprised. Corporations have always been about controlling their consumers,
and it was really only a matter of time before the WMF fell into that as
well. I wonder whether there's any legitimate justification for all of
this, or whether it's just a repeat of the VisualEditor fiasco, aka, the
WMF knows best kind of thing.

*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science


On Sun, Aug 10, 2014 at 3:19 PM, Siebrand Mazeland siebr...@kitano.nl
wrote:


  Op 10 aug. 2014 om 20:12 heeft Ricordisamoa 
 ricordisa...@openmailbox.org het volgende geschreven:
 
  hopelessI'd really like to hear Jimbo's opinion on the
 matter/hopeless

 You should really watch Jimmy's speech at the Wikimania closing session.
 You might be surprised.

 Cheers!

 --
 Siebrand
 ___
 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] Bikeshedding a good name for the api.php API

[Tyler Romeo]

On Thu, Aug 7, 2014 at 7:42 AM, Legoktm legoktm.wikipe...@gmail.com wrote:

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


We should just go back to query.php and get rid of api.php so we can avoid
all this confusion. /s

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

Re: [Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords

[Tyler Romeo]

On Thu, Aug 7, 2014 at 6:01 AM, Brian Wolff bawo...@gmail.com wrote:

 I think TLS has a feature where the client can also provide a
 certificate, in order to use certificates to authenticate users. I've
 never heard of a site actually using it.


Indeed.

https://www.mediawiki.org/wiki/Extension:SSLClientAuthentication

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

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

[Tyler Romeo]

Definitely agree with this. It’s the only API that is part of core, so 
“MediaWiki API” makes sense.
-- 
Tyler Romeo
0x405D34A7C86B42DF

From: Bartosz Dziewoński matma@gmail.com
Reply: Wikimedia developers wikitech-l@lists.wikimedia.org
Date: August 6, 2014 at 9:52:34
To: Wikimedia developers wikitech-l@lists.wikimedia.org
Subject:  Re: [Wikitech-l] Bikeshedding a good name for the api.php API  

How about just the MediaWiki API? That's the only proper external API 
core MediaWiki has, as far as I'm aware.

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

Re: [Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords

[Tyler Romeo]

In terms of external authentication, we need Extension:OpenID to catch up to 
the OpenID standard in order to do that.

In terms of two-factor, I have like eight patches for Extension:OATHAuth 
attempting to make it production-worthy.

https://gerrit.wikimedia.org/r/132783
-- 
Tyler Romeo
0x405D34A7C86B42DF

From: svetlana svetl...@fastmail.com.au
Reply: Wikimedia developers wikitech-l@lists.wikimedia.org
Date: August 6, 2014 at 7:57:12
To: wikitech-l@lists.wikimedia.org wikitech-l@lists.wikimedia.org
Subject:  Re: [Wikitech-l] News about stolen Internet credentials; reducing 
Wikimedia reliance on usernames and passwords  

On Wed, 6 Aug 2014, at 21:49, Andre Klapper wrote:
 On Tue, 2014-08-05 at 22:05 -0700, Pine W wrote:
  After reading this [1] I am wondering if Wikimedia should start taking
  steps to reduce reliance on usernames and passwords.
  
 What steps do you refer to, or is this intentionally vague?
 Disallowing usernames and logins?
 Two-step authentication/verification?
 Something else?
  
 andre

from what i could read and parse:
use less of external things like skype and google accounts
so that there is only 1 username for everything

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

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

[Wikitech-l] MediaWiki now supports PBKDF2 and Bcrypt

[Tyler Romeo]

Hi everybody,

I was on the brink of celebrating the one-year anniversary of a patch I 
submitted being open, but today it was finally merged!

https://gerrit.wikimedia.org/r/77645

The old User::comparePasswords() and User::crypt() functions have been replaced 
with a new password hashing API. This means MediaWiki now natively supports 
Bcrypt and PBKDF2 as replacement password hashing algorithms. Furthermore, the 
system allows seamless transitioning, meaning users’ password hashes will be 
updated automatically the next time they log in.

This means that MD5 is almost out the door, which is a big win (a follow up 
patch, https://gerrit.wikimedia.org/r/149658, changes the default to PBKDF2, 
which would mean any wiki that upgrades to 1.24 would automatically switch away 
from MD5).

I’d like to thank Aaron Schulz, Chris Steipp, Krinkle, and many others who 
helped get this through.

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

Re: [Wikitech-l] MediaWiki now supports PBKDF2 and Bcrypt

[Tyler Romeo]

On Mon, Jul 28, 2014 at 5:24 PM, Pine W wiki.p...@gmail.com wrote:

 Thank you. Out of curiosity, why bcrypt and not scrypt? There is debate in
 the security community about which is better so my comment isn't intended
 as criticism. I'm just interested in the thinking behind this decision.


It is a matter of stability in PHP. Bcrypt has built-in support in PHP, as
does PBKDF2, whereas scrypt requires an extension. It should be noted,
however, that the patch that was merged implements an extensible password
API, so it would be trivial to implement scrypt support if we wanted to.

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

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

[Tyler Romeo]

FYI, I’d be willing to maintain the extension, but it’d be best it there was 
one other person, since it is WMF-deployed and thus I cannot merge my own 
patches.
-- 
Tyler Romeo
0x405D34A7C86B42DF

From: Quim Gil q...@wikimedia.org
Reply: Wikimedia developers wikitech-l@lists.wikimedia.org
Date: July 23, 2014 at 7:57:07
To: Wikimedia developers wikitech-l@lists.wikimedia.org
Subject:  [Wikitech-l] Reviewing a couple of TorBlock patches  

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


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.

(*) http://korma.wmflabs.org/browser/gerrit_review_queue.html -- the
algorithm happens to be buggy these days, but apparently equally buggy for
all repos, which still results in some kind of justice.


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

Re: [Wikitech-l] logging out on one device logs user out everywhere

[Tyler Romeo]

Just to be clear, this is a CentralAuth issue. MediaWiki core already has logout
localized by session, and I have an extension SecureSessions that already has
a feature that shows all your logged in sessions and lets them log out.

It is CentralAuth that does global logout.
-- 
Tyler Romeo
0x405D34A7C86B42DF

From: Jon Robson jdlrob...@gmail.com
Reply: Wikimedia developers wikitech-l@lists.wikimedia.org
Date: July 21, 2014 at 14:35:54
To: Wikimedia developers wikitech-l@lists.wikimedia.org
Subject:  Re: [Wikitech-l] logging out on one device logs user out everywhere  

It seems like there is agreement on an approach

As I understand it:
* special button that when clicked logs you out everywhere
* default behaviour is just to log you out on current device

Does anyone want to own this and help move it forward? I've got too
many things on my plate right now, but it's been bothering me for many
years.

Although I don't have time/energy to do all of this, I'm happy to help
out grabbing people to code review any patches, unblock any
disagreements.

/me hopes someone puts their hand up


On Wed, Jul 16, 2014 at 4:06 AM, Tyler Romeo tylerro...@gmail.com wrote:
 On Wed, Jul 16, 2014 at 12:50 AM, Jasper Deng jas...@jasperswebsite.com
 wrote:

 I'd prefer that we did Google's system that, in addition to allowing a
 separate sign out all other sessions option, also allows users to monitor
 which IP addresses their account was accessed from (which however would be
 akin to self CheckUser and might run afoul of our privacy policy).


 https://www.mediawiki.org/wiki/Extension:SecureSessions

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



--  
Jon Robson
* http://jonrobson.me.uk
* https://www.facebook.com/jonrobson
* @rakugojon

___
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] logging out on one device logs user out everywhere

[Tyler Romeo]

On Wed, Jul 16, 2014 at 12:50 AM, Jasper Deng jas...@jasperswebsite.com
wrote:

 I'd prefer that we did Google's system that, in addition to allowing a
 separate sign out all other sessions option, also allows users to monitor
 which IP addresses their account was accessed from (which however would be
 akin to self CheckUser and might run afoul of our privacy policy).


https://www.mediawiki.org/wiki/Extension:SecureSessions

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

Re: [Wikitech-l] Not logged in page

[Tyler Romeo]

https://gerrit.wikimedia.org/r/146515
-- 
Tyler Romeo
0x405D34A7C86B42DF

From: Jon Robson jdlrob...@gmail.com
Reply: Wikimedia developers wikitech-l@lists.wikimedia.org
Date: July 15, 2014 at 14:32:19
To: Wikimedia developers wikitech-l@lists.wikimedia.org
Subject:  Re: [Wikitech-l] Not logged in page  

Yes someone please submit a patch and I will help us get a fix for this merged.

On Tue, Jul 15, 2014 at 6:10 AM, Bartosz Dziewoński matma@gmail.com wrote:
 On Tue, 15 Jul 2014 13:00:04 +0200, David Cuenca dacu...@gmail.com wrote:

 Sometimes while not logged in I try to access my Watchlist and then the
 Not logged in page appears. It is quite useless since then you have to
 click again to go to the Log in page. Wouldn't it be better to just
 redirect to the log in page instead of showing that dumb Not logged in
 page?

 Or perhaps I am missing some hidden use or reasoning behind the existence
 of that page...?


 There is some old discussion on
 https://bugzilla.wikimedia.org/show_bug.cgi?id=15484, which asks for the
 same thing.


 --
 Matma Rex


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



--  
Jon Robson
* http://jonrobson.me.uk
* https://www.facebook.com/jonrobson
* @rakugojon

___
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] Not logged in page

[Tyler Romeo]

Yes. Actually, that is existing functionality. Special:Userlogin will redirect 
users
if the returnto (and optionally returntoquery) are specified. (The only 
exception is if
a hook intervenes).
-- 
Tyler Romeo
0x405D34A7C86B42DF

From: Risker risker...@gmail.com
Reply: Wikimedia developers wikitech-l@lists.wikimedia.org
Date: July 15, 2014 at 15:04:18
To: Wikimedia developers wikitech-l@lists.wikimedia.org
Subject:  Re: [Wikitech-l] Not logged in page  

Would this return the user to the page that was originally requested, and
from which they were diverted?

I ask because a lot of people bookmark their watchlist as the easiest way
to wind up where they want to be. Getting a log-in screen first if they're
not already logged in would work fine, but then they'd want to be sent back
to the watchlist.

Risker/Anne


On 15 July 2014 14:49, Tyler Romeo tylerro...@gmail.com wrote:

 https://gerrit.wikimedia.org/r/146515
 --
 Tyler Romeo
 0x405D34A7C86B42DF

 From: Jon Robson jdlrob...@gmail.com
 Reply: Wikimedia developers wikitech-l@lists.wikimedia.org
 Date: July 15, 2014 at 14:32:19
 To: Wikimedia developers wikitech-l@lists.wikimedia.org
 Subject: Re: [Wikitech-l] Not logged in page

 Yes someone please submit a patch and I will help us get a fix for this
 merged.

 On Tue, Jul 15, 2014 at 6:10 AM, Bartosz Dziewoński matma@gmail.com
 wrote:
  On Tue, 15 Jul 2014 13:00:04 +0200, David Cuenca dacu...@gmail.com
 wrote:
 
  Sometimes while not logged in I try to access my Watchlist and then the
  Not logged in page appears. It is quite useless since then you have to
  click again to go to the Log in page. Wouldn't it be better to just
  redirect to the log in page instead of showing that dumb Not logged
 in
  page?
 
  Or perhaps I am missing some hidden use or reasoning behind the
 existence
  of that page...?
 
 
  There is some old discussion on
  https://bugzilla.wikimedia.org/show_bug.cgi?id=15484, which asks for
 the
  same thing.
 
 
  --
  Matma Rex
 
 
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l



 --
 Jon Robson
 * http://jonrobson.me.uk
 * https://www.facebook.com/jonrobson
 * @rakugojon

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

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

Re: [Wikitech-l] Anonymous editors IP addresses

[Tyler Romeo]

I agree that it’s a double standard, but looking at the bright side, it becomes 
a big encouragement to anonymous users to register and log in. The Account 
Creation Experience Team (or whoever the hell is in charge of that) can correct 
me, but I would imagine that we would see a big drop in registered accounts if 
IPs were hashed.

Also, it’d be really annoying to have hashes as usernames, so we’d have to 
think of an alternative scheme that makes things more readable.
-- 
Tyler Romeo
0x405D34A7C86B42DF

From: Gilles Dubuc gil...@wikimedia.org
Reply: Wikimedia developers wikitech-l@lists.wikimedia.org
Date: July 11, 2014 at 9:34:18
To: Wikimedia developers wikitech-l@lists.wikimedia.org
Subject:  [Wikitech-l] Anonymous editors  IP addresses  

This interesting bot showed up on hackernews today:
https://news.ycombinator.com/item?id=8018284

While in this instance the access to anonymous' editors IP addresses is
definitely useful in terms of identifying edits with probable conflict of
interest, it makes me wonder what the history is behind the fact that
anonymous editors are identified by their IP addresses on WMF-hosted wikis.

IP addresses are closely guarded for registered users, why wouldn't
anonymous users be identified by a hash of their IP address in order to
protect their privacy as well? The exact same functionality of being able
to see all edits by a given anonymous IP would still exist, the IP itself
just wouldn't be publicly available, protected with the same access rights
as registered users'.

The use case that makes me think of that is someone living in a
totalitarian regime making a sensitive edit and forgetting that they're
logged out. Or just being unaware that being anonymous on the wiki doesn't
mean that their local authorities can figure out who they are based on IP
address and time. Understanding that they're somewhat protected when logged
in and not when logged out requires a certain level of technical
understanding. The easy way out of this argument is to state that these
users should be using Tor or something similar. But I still wonder why we
have this double standard of protecting registered users' privacy in
regards to IP addresses and not applying the same for anonymous users, when
simple hashing would do the job.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

Re: [Wikitech-l] Anonymous editors IP addresses

[Tyler Romeo]

As a quick implementation note, we would not be using a hash for the IP address.

Most likely, we would encrypt the IP with AES or something using a 
configuration-based secret key. That way checkusers can still reverse the hash 
back into normal IP addresses without having to store the mapping in the 
database.

-- 
Tyler Romeo
0x405D34A7C86B42DF

From: Gilles Dubuc gil...@wikimedia.org
Reply: Wikimedia developers wikitech-l@lists.wikimedia.org
Date: July 11, 2014 at 10:59:55
To: Wikimedia developers wikitech-l@lists.wikimedia.org
Subject:  Re: [Wikitech-l] Anonymous editors  IP addresses  

With hashing, a given IP would always give the same hash. So this
uniqueness property would remain for people with stable IPs.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] (no subject)

[Tyler Romeo]

On Thu, Jul 10, 2014 at 5:59 AM, Gerard Meijssen gerard.meijs...@gmail.com
wrote:

 I use GMAIL and I see it plenty fine.


I also use Gmail, and it says the only reason it wasn't sent to spam was
because I have a filter sending all wikitech emails to me inbox.

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

Re: [Wikitech-l] HTML templating progress; Knockout Components curly brace syntax

[Tyler Romeo]

I just want to be clear that any sort of template syntax that resembles or can 
be confused with wikitext is not something that we can or should allow in core. 
If MobileFrontend and whatnot want to use this syntax, so be it.

-- 
Tyler Romeo
0x405D34A7C86B42DF

From: Gabriel Wicke gwi...@wikimedia.org
Reply: Wikimedia developers wikitech-l@lists.wikimedia.org
Date: July 7, 2014 at 21:28:33
To: Wikimedia developers wikitech-l@lists.wikimedia.org
Subject:  [Wikitech-l] HTML templating progress; Knockout Components  curly 
brace syntax  

== Curly braces ==
The other thing they're adding is text interpolation so you can do
span{{name}}/span and people don't have to be sad about Knockout's HTML
attribute syntax. This can simplify the migration for existing handlebars
compatible templates as used by Mobile  Flow.

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

Re: [Wikitech-l] HTML templating progress; Knockout Components curly brace syntax

[Tyler Romeo]

In general, the syntax is different, which is why Knockout is a great solution. 
But using curly braces for variable insertion is similar to wikisyntax’s 
template transclusion. That alone is not really enough to cause a problem, but 
if we proceed in that general direction it could lead to issues.
-- 
Tyler Romeo
0x405D34A7C86B42DF

From: Dan Andreescu dandree...@wikimedia.org
Reply: Wikimedia developers wikitech-l@lists.wikimedia.org
Date: July 8, 2014 at 10:27:08
To: Wikimedia developers wikitech-l@lists.wikimedia.org
Subject:  Re: [Wikitech-l] HTML templating progress; Knockout Components  
curly brace syntax  

I'm not sure I follow, it seems to me knockout syntax and wikitext are
different, and have different purposes. Can you elaborate a bit more,
Tyler?

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

Re: [Wikitech-l] Wikimedia email list settings

[Tyler Romeo]

That's weird, because I use gmail and I always get copies of my own
messages when I send them.

-- 
Tyler Romeo
On Jul 6, 2014 12:38 AM, Pine W wiki.p...@gmail.com wrote:

 Thank you. Groan @ gmail.

 Pine


 On Sat, Jul 5, 2014 at 12:54 PM, Jeremy Baron jer...@tuxmachine.com
 wrote:

  On Jul 5, 2014 3:27 PM, Bináris wikipo...@gmail.com wrote:
   Fix= don't use gmail. It decides for you. They are like Microsoft and
  know
   what you need better than yourself. :-)
 
  More details:
 
  https://productforums.google.com/d/topic/gmail/fkbKPajx1Dw/discussion
  ___
  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] MediaWiki Bug Bounty Program

[Tyler Romeo]

On Fri, Jun 27, 2014 at 9:06 AM, Antoine Musso hashar+...@free.fr wrote:

 Doesn't WMF has a plan to provide badges in MediaWiki itself? Kind of
 Wikiloves which let you distribute barn pages on talk pages but a bit
 more robust?


Well we made an OpenBadges extension for Facebook OpenAcademy, but it's in
an infant state, and needs more attention (including from myself) if we
actually plan on using it more extensively.

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

Re: [Wikitech-l] MediaWiki Bug Bounty Program

[Tyler Romeo]

OK, so really the process that we need here is:

1) Get more people on the security team via NDA and whatnot (sign me up, by the 
way, obviously)
2) Develop a triage system to quickly investigate and handle invalid and 
duplicate bugs
3) Determine when and how we’re going to do the program
4) Do it.

-- 
Tyler Romeo
0xC86B42DF

From: Brian Wolff bawo...@gmail.com
Reply: Wikimedia developers wikitech-l@lists.wikimedia.org
Date: June 26, 2014 at 0:34:54
To: Wikimedia developers wikitech-l@lists.wikimedia.org
Subject:  Re: [Wikitech-l] MediaWiki Bug Bounty Program  

On 6/26/14, Chris Steipp cste...@wikimedia.org wrote:
 On Wed, Jun 25, 2014 at 5:49 PM, Alex Monk kren...@gmail.com wrote:
 Chris, why don't we leave privacy policy compliance to the users posting
 on
 the bug? Wikimedia personal user data shouldn't be going to the security
 product.

 There are a few cases where there may be legitimate private data in a
 security bug (look, sql injection, and here are some rows from the
 user table!, Hey, this was supposed to be suppressed, and I can see
 it, This user circumvented the block on this IP). But there might
 be ways to flag or categorize a report as also including private data?
 Someone with more bugzilla experience would need to comment.

 Why does WMF get the right to control by access to MediaWiki security bugs
 anyway? Could we not simply host MediaWiki stuff externally? Perhaps on
 the
 servers of any other major MediaWiki user.

 This certainly could be done. That other major MediaWiki user would
 have to be someone everyone trusts, and preferably with a strong track
 record of being able to keep their infrastructure secure. If there's a
 legitimate proposal to try it, let's definitely discuss.


Personally I'd prefer that MediaWiki related support software stay
hosted by WMF (at least for the foreseeable future). WMF just seems
like the logical people to host it, and I don't see any harm in
MediaWiki being a Wikimedia project in a similar sense as wikipedia
is a Wikimedia project. What I would like to see though is a mediawiki
world where WMF is not special. What I mean by that is that being a
WMF employee/contractor wouldn't get you any special treatment -
trusted people would get special access where needed because they're
trusted and have demonstrated their competence. A WMF staffer would
have to go through the same procedure as anyone else would have to to
get any sort of special access. Much of the people who have special
access would still be WMF employees, since WMF employs most senior
developers, but it wouldn't be you're a wmf employee = here's access
to everything even if you don't need it, you're not a WMF employee =
have to jump through a million hoops plus sign something in blood plus
bribe someone to get access to things that would be extremely helpful
to your work.

--bawolff

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

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

Re: [Wikitech-l] MediaWiki Bug Bounty Program

[Tyler Romeo]

I’ll be frank. I care a lot more about the security of MediaWiki as a software 
product,
as well as the security of its customers (both WMF and third-party) than I do 
about
some made-up notion of “open access” to security bugs.

I think it makes complete sense to have people with access to security bugs 
sign an
agreement saying they will not release said bugs to the public until they have 
been
fixed, released, and announced properly.
-- 
Tyler Romeo
0xC86B42DF

From: MZMcBride z...@mzmcbride.com
Reply: Wikimedia developers wikitech-l@lists.wikimedia.org
Date: June 26, 2014 at 9:44:25
To: Wikimedia developers wikitech-l@lists.wikimedia.org
Subject:  Re: [Wikitech-l] MediaWiki Bug Bounty Program  

Any process that involves volunteers signing non-public, indefinite vows
of secrecy and silence are antithetical to Wikimedia's values and mission.
This isn't a cult. Our bedrock principles are open access and transparency.

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