On 2014-06-10, 8:59 PM, John wrote:
There is zero reason that this shouldnt be in an extension.
Basically a few users want to install a shinny new toy called swiftmailer
into core, just because its shiny. In doing so they add a complexity and
headache. Such a addition should be done as an
On 11/06/14 16:18, Daniel Friesen wrote:
- ((In other words, the library we're entrusting all our SMTP handling
to is practically dead and no longer maintained, Whoops.))
Only 3 open bugs though. Sometimes code just keeps working for
decades, even without being maintained. Some might even
On 11.06.2014 9:01, Matthew Walker wrote:
This also has knock on impacts elsewhere. BD808 has a patch that uses
PSR-log and Monolog for logging. We're starting to move to a model where we
recognize that we shouldn't write everything and that things in core have
significantly better replacements
Hi,
from my point of view this discussion mixes two or three different questions:
* Do we want core to regularly use external libraries (which are
installed via one git submodule or composer)?
* Should Swiftmailer be used in core?
* (How) Do we want to handle this for plain git cloning to be
Just to add to the technical stuff:-
* We made a local repo to fork the original swiftmailer repo at
https://github.com/wikimedia/mediawiki-core-vendor-swiftmailer/tree/5.2.0-patch,
and our https://gerrit.wikimedia.org/r/#/c/137538/ makes composer take up
the files from our repo and not the
On 2014-06-11, 12:07 AM, Tim Starling wrote:
On 11/06/14 16:18, Daniel Friesen wrote:
- ((In other words, the library we're entrusting all our SMTP handling
to is practically dead and no longer maintained, Whoops.))
Only 3 open bugs though. Sometimes code just keeps working for
decades,
Le 11/06/2014 04:30, Tim Starling a écrit :
In CR comments on https://gerrit.wikimedia.org/r/#/c/135290/
it has been proposed that we make a git clone of the MW core not be
installable until $IP/vendor is populated somehow -- either by
separately cloning the mediawiki/core/vendor project, or
On Wed, Jun 11, 2014 at 1:58 PM, Antoine Musso hashar+...@free.fr wrote:
A rough comparison on top of my mind, should probably start up a formal
RFC about it though they are probably some going on.
Please find Bryan's RFC here:-
Hi,
using polipo http proxy which works fine with wikipedia as long as
the machine is online.
For offline usage, polipo has the option to store cached http data
persistently on disk - and something perhaps style sheet related
goes wrong when trying to do this with wikipedia and firefox.
The
On Wed, Jun 11, 2014 at 4:28 AM, Antoine Musso hashar+...@free.fr wrote:
- depends on upstream to incorporate our patches
- might not be used as-is on Wikimedia cluster
I would just like to point out that you can override where Composer finds
packages using the composer.json file. In other
OK, now that I have some more time, I will expand on what I’ve already said in
the Gerrit patch.
== Introduction ==
The WMF does not have that many developers. And it’s not that they haven’t
hired enough or anything like that. It’s just they do not have that many people
in general. As of last
On Wed, Jun 11, 2014 at 4:28 AM, Antoine Musso hashar+...@free.fr wrote:
== git submodule ==
+ command already available
+ already used by Wikimedia to handle extensions dependencies in the
wmf branches
+ let us review the code
+ ability to patch third parties
- require to fully clone
I will mention that any solution short of sucking in the third party
dependencies into the main repo (not as a submodule) -- which no one
wants to do anyway -- will be slightly awkward to git bisect. Not
impossible; the pain is about the same for both main options:
a) in theory git-bisect should
I'm not a developer so it's perfectly normal that I can't understand
anything about your talk; nevertheless, please, remember of KISS principle
when building any installing tools for poor, final users. I'm waiting for
something like pip install core.
Alex
2014-06-11 15:58 GMT+02:00 C. Scott
On Wed, Jun 11, 2014 at 10:51 AM, Tyler Romeo tylerro...@gmail.com wrote:
curl -sS https://getcomposer.org/installer | php
... That's just awful.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
On Wed, Jun 11, 2014 at 10:42 AM, Alex Brollo alex.bro...@gmail.com wrote:
I'm not a developer so it's perfectly normal that I can't understand
anything about your talk; nevertheless, please, remember of KISS principle
when building any installing tools for poor, final users. I'm waiting for
On Wed, Jun 11, 2014 at 10:56 AM, Brad Jorsch (Anomie)
bjor...@wikimedia.org wrote:
... That's just awful.
How so?
*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
___
Wikitech-l mailing list
Fwiw, that's not required. Lots of packages exist already. Even if you
don't have a package for your chosen distro you can easily install it to
your $PATH in less scary ways.
-Chad
On Jun 11, 2014 7:56 AM, Brad Jorsch (Anomie) bjor...@wikimedia.org
wrote:
On Wed, Jun 11, 2014 at 10:51 AM, Tyler
On Wed, Jun 11, 2014 at 10:58 AM, Tyler Romeo tylerro...@gmail.com wrote:
On Wed, Jun 11, 2014 at 10:56 AM, Brad Jorsch (Anomie)
bjor...@wikimedia.org wrote:
... That's just awful.
How so?
Well, it makes *me* wince because you're directing people to pull code
over the network and feed it
Ouch, thanks for wasting a few of my brain cells. This is why do dont add
stupid code to core.
My web server doesnt have curl installed, nor does it have /usr/bin/local/
You havent bothered to think your code through. Why dont you un-fuck your
code, configure it as an extension and go from
On Wed, Jun 11, 2014 at 11:05 AM, Zack Weinberg za...@cmu.edu wrote:
Well, it makes *me* wince because you're directing people to pull code
over the network and feed it straight to the PHP interpreter, probably
as root, without inspecting it first. And the site is happy to send
it to you via
Can we kill the subthread dealing with the awful pipe the output of
curl to php install for composer? It's evilness is not really on
topic (not until we start writing suggested install directions in the
wiki). As Chad noted, there are sane-sysadmin ways to install
composer. I think it would be
On Wed, Jun 11, 2014 at 11:21 AM, Tyler Romeo tylerro...@gmail.com wrote:
It's over HTTPS. As long as you trust that getcomposer.org is the domain
you are looking for, this is really no different than installing via a
package manager.
Nothing stops you from installing it over insecure HTTP.
No one has really addressed the point of making this an extension and not
adding the excessive overhead to core.
Especially for something that may have such a wide impact.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
Thanks Zack for actually explaining the reasoning to me, rather than trying to
insult my intelligence and then use it as an argument against the proposal.
--
Tyler Romeo
0xC86B42DF
From: Zack Weinberg za...@cmu.edu
Reply: Wikimedia developers wikitech-l@lists.wikimedia.org
Date: June 11, 2014
In the current discussion about git submodules vs. composer there are
several different underlying assumptions about the user's situation. I think
it would help the discussion to clarify which use cases we are dealing with.
Here is an attempt:
1) Shared hosting without shell. The user uploads
Hello!
Reminder: This TechTalk is starting in 30 minutes.
*If you would like to join the hangout or follow along on YouTube:*
https://plus.google.com/events/chpgv8usjd6dn38on07njjk28hg
IRC: #wikimedia-office
*More information about this Tech Talk from Jared Zimmerman: *
If you or someone you
On Jun 10, 2014 10:19 AM, Quim Gil q...@wikimedia.org wrote:
The video can be watched from the Google+ URL that we are advertising.
Even if not logged in? Please double check with a clean cookie jar.
(Seems to just give me a login prompt. No chance to play the video. I just
trued with the
On 2014-06-11, 11:47 AM, Gabriel Wicke wrote:
In the current discussion about git submodules vs. composer there are
several different underlying assumptions about the user's situation. I think
it would help the discussion to clarify which use cases we are dealing with.
Here is an attempt:
1)
As Daniel hinted at, I'd like to add one more use case:
(4) prospective developers who want to do a small install for local
testing and contribute patches.
This turns out to be very similar to use case (2), but it motivates
the use of git (rather than a tarball) more strongly. Case (4) also
Le 11/06/2014 15:51, Brad Jorsch (Anomie) a écrit :
- require to fully clone each repositories
Couldn't you do a shallow clone, if the disk space or bandwidth is a
concern?
The git submodule add|update subcommands support --depth to produce
shallow clone.
The commit:
Le 11/06/2014 15:51, Brad Jorsch (Anomie) a écrit :
- needs to install composer
This is one of my pet peeves. It's one thing to have to install
dependencies to run MediaWiki, but having to install various dependencies
just to *install* it? Ugh!
Composer is a first step. Then there's
On 06/06/2014 11:05 PM, Sumana Harihareswara wrote:
At the Wednesday, 11 June RfC meeting we'll briefly look at several RfCs
to decide on next actions. Early in the week I'll make a list and send
it out onlist.
https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-06-11
would
On 06/11/2014 12:29 PM, C. Scott Ananian wrote:
As Daniel hinted at, I'd like to add one more use case:
(4) prospective developers who want to do a small install for local
testing and contribute patches.
Scott I have started to summarize the use cases at
Also: people with shell but no git.
Sent from my mobile device
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wednesday, June 11, 2014, Jeremy Baron jer...@tuxmachine.com wrote:
On Jun 10, 2014 10:19 AM, Quim Gil q...@wikimedia.org
javascript:_e(%7B%7D,'cvml','q...@wikimedia.org'); wrote:
The video can be watched from the Google+ URL that we are advertising.
Even if not logged in? Please double
On 11 Jun 2014, at 22:05, Antoine Musso hashar+...@free.fr wrote:
Le 11/06/2014 15:51, Brad Jorsch (Anomie) a écrit :
- needs to install composer
This is one of my pet peeves. It's one thing to have to install
dependencies to run MediaWiki, but having to install various dependencies
just
On 9 Jun 2014, at 20:58, Bartosz Dziewoński matma@gmail.com wrote:
On Mon, 09 Jun 2014 20:52:44 +0200, Martijn Hoekstra
martijnhoeks...@gmail.com wrote:
In this case, which post are you replying to in flow when you reply to
multiple people? In mediawiki you sort of work around the
On Mon, Jun 9, 2014 at 5:55 PM, Rachel Farrand rfarr...@wikimedia.org
wrote:
Please join us on google hangout June 11 @ 1900 UTC
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WikiFontiso=20140611T12p1=224ah=1
for the following Tech Talk:
*How, What, Why of WikiFont*
On 12/06/14 05:29, C. Scott Ananian wrote:
As Daniel hinted at, I'd like to add one more use case:
(4) prospective developers who want to do a small install for local
testing and contribute patches.
For development, I like to have everything checked out from some kind
of version control
One thing that concerns me about the proposed composer setup, that I
haven't mentioned yet, is the nesting of the project hierarchy, with
mediawiki/core/vendor inside mediawiki/core.
You know that we have mediawiki/extensions instead of
mediawiki/core/extensions -- that makes it easy to check out
On 11/06/14 05:01, Matthew Walker wrote:
This also has knock on impacts elsewhere. BD808 has a patch that uses
PSR-log and Monolog for logging. We're starting to move to a model where we
recognize that we shouldn't write everything and that things in core have
significantly better replacements
On Wed, Jun 11, 2014 at 7:20 PM, Isarra Yos zhoris...@gmail.com wrote:
Problem with composer is it doesn't actually work for all use cases (farms
in particular can be problematic, even if the wmf did get it working), so
depending on it isn't really a good idea unless there is a sane fallback.
On 11/06/14 22:26, Tim Starling wrote:
One thing that concerns me about the proposed composer setup, that I
haven't mentioned yet, is the nesting of the project hierarchy, with
mediawiki/core/vendor inside mediawiki/core.
You know that we have mediawiki/extensions instead of
On 11/06/14 23:21, Tyler Romeo wrote:
On Wed, Jun 11, 2014 at 7:20 PM, Isarra Yos zhoris...@gmail.com wrote:
Problem with composer is it doesn't actually work for all use cases (farms
in particular can be problematic, even if the wmf did get it working), so
depending on it isn't really a good
I actually think that Composer-installed stuff should be under $IP/includes
as that's where most code should be.
On Wed, Jun 11, 2014 at 3:26 PM, Tim Starling tstarl...@wikimedia.org
wrote:
One thing that concerns me about the proposed composer setup, that I
haven't mentioned yet, is the
On 11/06/14 14:49, I wrote:
In particular, there is a mail library called SwiftMailer which
provides bounce detection, among other things. Bounce detection would
be a nice thing to have.
Sorry, it seems I was misled on this. SwiftMailer does not have any
special handling for bounces, judging
On 11/06/14 16:18, Daniel Friesen wrote:
- Current stable 1.2.0, released in March of 2010
Note that the SMTP part is implemented in Net_SMTP, which was last
released in 2013, and the MIME printer part (which we don't currently
use) is in Mail_Mime, last released May 2014.
Swift, by contrast,
48 matches
Mail list logo
