from:"John Du Hart"

Re: [Wikitech-l] editing channels - "How was this edit made?"

2012-11-19 Thread John Du Hart

On Mon, Nov 19, 2012 at 7:43 PM,   wrote:
> You n*rds are 100 years behind Facebook, who already shows
> Yesterday via email
> About an hour ago via mobile
> 59 minutes ago near Tsoying, Kao-hsiung
> 24 minutes ago via POCO Beautycamera
> Throw in the towel.
>

Another excellent post by jidanni


-- 
John

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

Re: [Wikitech-l] Moving MediaWikiWidgets.org to Wikimedia

2012-09-04 Thread John Du Hart

On Tue, Sep 4, 2012 at 2:06 PM, [[w:en:User:Madman]]
 wrote:
> On Tue, Sep 4, 2012 at 1:39 PM, John Du Hart  wrote:
>> Does MediaWikiWiki really need any more shitty/insecure addons that no
>> one is going to maintain? I think we have enough already.
>
> Does MediaWiki's development community really need any more people
> discouraging volunteers by calling their good-faith contributions
> shitty? I think we have enough already.
>
> Maybe we should stick to constructive criticism.
>
> Thanks,
> -Madman
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Hey if you want to make mediawiki.org a dumping ground for anything
mediawiki related, have fun with that.

-- 
John

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

Re: [Wikitech-l] Moving MediaWikiWidgets.org to Wikimedia

2012-09-04 Thread John Du Hart

On Tue, Sep 4, 2012 at 9:26 AM, Mr. Gregory Varnum
 wrote:
> I use and like this extension. I know many others do as well. This debate 
> over its value to some and security is interesting (well - not really) but 
> aside from the point of this thread.
>
> Should the widgets be housed on MW.org rather than an outside site? Given 
> their wide usage and the preference towards all things MW being on MW.org, I 
> think they absolutely should and fully support that idea.
>
> Don't like the extension? Don't use it. For those of us that do, this move 
> would be very helpful. Arguing about the merits of the extension vs the value 
> of moving its components seems irrelevant. It's widely used enough and 
> arguing about it is unlikely to change that. Unless we're suddenly worried 
> about storage space on MW.org this seems like it should be more about how 
> than why.
>
> I would propose subpages to the main extension page.
>
> -Greg aka varnent
>
> 
> Sent from my iPhone. Apologies for any typos. A more detailed response may be 
> sent later.
>
> On Sep 4, 2012, at 8:11 AM, Jeroen De Dauw  wrote:
>
>> Hey,
>>
>> The essential problem is that people can't get stuff through the
>>> gatekeepers, so they come up with a workaround. Noting that the
>>> workaround is insecure and saying "just don't do that" doesn't solve
>>> the original need and won't help security. It's not clear to me what
>>> will, but the gatekeeping is an obvious start.
>>
>> I don't think this extension really affects this. It is the same as having
>> widgets implemented as extensions in that:
>>
>> * They can only be enabled by administrative people
>> * They can be obtained from verified sources or from non-trusted ones
>>
>> Widgets are inferior in that:
>>
>> * An attacker compromising an admin account can put in arbitrary JS code
>>
>> Widgets are superior in that:
>>
>> * They cannot create PHP vulnerabilities
>> * Changes can be kept track of on-wiki
>> * The source is clearly visible to wiki users, increasing the scrutiny of
>> the code
>> * They are easier to deploy for most people
>> * They encourage more collaboration compared to the tons of low qualify and
>> unmaintained single widget extensions
>>
>> It seems to me that this extension does not lose on security compared to
>> regular extensions at all, and that it offers quite a few benefits for the
>> kind of functionality it is intended to be used for.
>>
>> The problem with creating a new system that has no gatekeepers
>>> is that it encourages people who have no business writing code to
>>> end up doing so.
>>
>> This system has as much gatekeeping as regular extensions do. I think
>> several people are making assumptions here without having had a decent look
>> at the extension.
>>
>> Cheers
>>
>> --
>> Jeroen De Dauw
>> http://www.bn2vs.com
>> Don't panic. Don't be evil.
>> --
>> ___
>> 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

Does MediaWikiWiki really need any more shitty/insecure addons that no
one is going to maintain? I think we have enough already.

Pick out the best of the bunch and nuke the rest.

-- 
John

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

Re: [Wikitech-l] GSoC Project Update (ConventionExtension)

2012-08-27 Thread John Du Hart

Thanks the explain in-depth about why storing configuration in articles is
a good thing. Keep up the good work.
On Aug 26, 2012 2:11 PM, "akshay chugh"  wrote:

> -1
>
> On Sun, Aug 26, 2012 at 11:34 PM, John Du Hart 
> wrote:
>
> > On Wed, Aug 22, 2012 at 8:40 AM, akshay chugh 
> > wrote:
> > > 6. Parser tags, Magic Words (Variables) and a parser function
> > >  parser tags --> , , ,
> > > , and
> > > 
> >
> > This is a disgusting way to store data.
> >
> > --
> > John
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
>
>
>
> --
> Thanks,
> Akshay Chugh
> skype- chughakshay16
> irc - chughakshay16(#mediawiki)
> [[User:Chughakshay16]] on mediawiki.org
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] GSoC Project Update (ConventionExtension)

2012-08-26 Thread John Du Hart

On Wed, Aug 22, 2012 at 8:40 AM, akshay chugh  wrote:
> 6. Parser tags, Magic Words (Variables) and a parser function
>  parser tags --> , , ,
> , and
> 

This is a disgusting way to store data.

-- 
John

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

Re: [Wikitech-l] Inline styles trouble on the mobile site

2012-07-02 Thread John Du Hart

So you've found and instance of where a user has poor design skills and you
immediate response to that is to start a discussion on killing inline
styles? Give me a break.
On Jul 2, 2012 10:43 AM, "Jon Robson"  wrote:

> > Yes, please, because fixing things such as (put your sunglasses first)
> >
> https://pt.wikipedia.org/?oldid=30926886&action=edit§ion=3&preview=yes&uselang=en
> > is a PITA and will take years! (there are tons of it!)
>
> Wow! This is exactly why I think inline styles might be a bad thing
> :-) - this really draws attention of the user away from the content.
>
> I've started a wiki page for this discussion - it seems like a better
> place to do this from now on since this thread has already been
> confused and gained a lot of length! I've given it the generic heading
> 'Deprecating Inline Styles' and when I get time will add a mobile
> specific section:
> http://www.mediawiki.org/wiki/Deprecating_Inline_Styles
>
> ___
> 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] bot activity in #mediawiki on freenode

2012-06-21 Thread John Du Hart

On Thu, Jun 21, 2012 at 12:25 PM, Krenair  wrote:
> If you're moving all bots, including wikibugs, then you can't use
> -codereview because wikibugs isn't a code review bot. It's for bugs.
>
> Krenair
>
>

Will the world end if we do this? No.

-- 
John

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

Re: [Wikitech-l] IE7 tax

2012-06-14 Thread John Du Hart

On Thu, Jun 14, 2012 at 9:57 AM, Chris McMahon  wrote:
> On Thu, Jun 14, 2012 at 5:21 AM, Arun Ganesh wrote:
>
> 6% of wikimedia project page views are from IE6/7 - because of the
>> following:
>> - IE6 ships default with XP
>> - Legal users with SP2+ can upgrade to IE8
>> - If you have 90s era hardware, no SP for you. Can only be solved by buying
>> some new hardware (or switching to linux)
>> - IT admins who dont know much about IT and have kept the workforce hostage
>> through their ignorance. Can be solved if the workforce and boss demands
>> it.
>
>
> I'd like to reframe these examples.
>
> First, as I understand it, most IE6/IE7 users globally are running pirated
> versions of Windows.  For financial or political reasons, they will not or
> can not acquire legal versions and thus can't upgrade their browsers.

No, I'm pretty sure that's not true at all. Even if they are running a
pirated version they can still update their browsers.



-- 
John

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

Re: [Wikitech-l] Changing the MediaWiki logo?

2012-06-12 Thread John Du Hart

I support that fully.
On Jun 12, 2012 5:48 PM, "Chad"  wrote:

> Hi,
>
> Little bit of a different thread today--but something's been kind of biting
> at me over the last couple of weeks and I thought it'd be best to get it
> out there :)
>
> What support would there be for changing the MediaWiki logo and
> being consistent with it?
>
> I'm not suggesting a drastic change, like substituting puppies for the
> flower. I'm looking at a more subtle change, as in moving from our
> current logo to something like[0]. Originally, I didn't like the SVG
> version
> but over time it's managed to grow on me quite a bit. Although, I stil
> think the text could use tweaking, something closer to the current color
> would be nice. There's a couple of pretty big reasons I think we should
> switch to this (or something like it):
>
> 1) It scales much nicer. The current version looks absolutely awful at
> higher resolutions, and at lower ends becomes rather featureless. A
> version natively designed as an SVG (but keeping the original design
> ideas) takes care of that.
> 2) It fits much nicer with the other WMF logos (other than the puzzle
> globe, which will never match :)
> 3) We've already started selling stickers based on the SVG version[1],
> so it might be good to update it on MediaWiki.org to match.
>
> So...thoughts? Should we do this more formal-like in an RfC or
> something? Other colors you'd like to paint the bikeshed?
>
> -Chad
>
> [0] http://commons.wikimedia.org/wiki/File:Mediawiki_logo_reworked_2.svg
> [1]
> http://shop.wikimedia.org/products/wikimedia-project-stickers-pack-of-12
>
> ___
> 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] Facebook grabs the Mediawiki logo instead of the site logo

2012-06-04 Thread John Du Hart

Yeah I remember that.
On Jun 4, 2012 7:45 PM, "Chad"  wrote:

> On Mon, Jun 4, 2012 at 7:35 PM,   wrote:
> > Here Facebook grabs the Mediawiki logo instead of the site logo.
> >
> >
> http://www.facebook.com/groups/tg.taiwan/permalink/374509135949001/?comment_id=374537129279535&offset=0&total_comments=1
> >
> > Doing the same experiment with e.g.,
> > http://en.wikipedia.org/wiki/1st_clan_chief ,
> > a page also without any user embedded images,
> > oddly does not cause the mediawiki logo to be chosen.
> >
> > Though it does not choose the site logo, at least it doesn't choose the
> > mediawiki logo.
> >
>
> Didn't we discuss this almost a year ago?
>
> Indeed, we did:
> http://lists.wikimedia.org/pipermail/mediawiki-l/2011-July/037710.html
>
> -Chad
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] some people complained already about my recent security alerts for PHP, OpenOffice, LibreOffice...

2012-05-22 Thread John Du Hart

How dare they complain about you posting off topic material!
On May 21, 2012 4:39 PM, "Thomas Gries"  wrote:

> ... in consequence, you will _/not /_receive further major security alerts.
>
> ___
> 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] Daring to consider replacing gerrit (help write gareth)

2012-04-08 Thread John Du Hart

On Sun, Apr 8, 2012 at 4:18 PM, Antoine Musso  wrote:
> Meanwhile, dont waste your time coding something we are most certainly
> never going to use.

Statements like that from WMF staff are hurtful towards volunteer
developers. Don't turn this into another MobileFrontend situation.

-- 
John

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

Re: [Wikitech-l] Daring to consider replacing gerrit (help write gareth)

2012-04-08 Thread John Du Hart

So what happened to considering Phabricator in the future?

On Sun, Apr 8, 2012 at 5:29 PM, Platonides  wrote:
> On 08/04/12 22:49, Daniel Friesen wrote:
 - The project needs a good database system. I copied our database
 classes in but never got to using them. I'm isolating all database stuff
 into some model classes so different database handing can be swapped in.
 Anyone who feels up to it can adapt our database code to work as a
 framework for the review system.
>>>
>>> I think it would be easier with our classes. Too much fetch()s in
>>> ProjectModel.php
>>
>> Someone would need to adapt the classes to work outside MW.
>> I started using Mysqli and prepared statements since it's an easy way to
>> get the database stuff out of the way right away.
>
> I think they work. You do:
>
> $conf = array( 'host' => ..., 'user' => ..., 'pass'=> ..., 'dbname'
> =>..., 'tableprefix'=> ... )
> $db = Database::factory( 'mysql', $conf );
>
> And you have a perfectly working Database object.
>
> Or if you prefer something much more lightweight,
>  https://fisheye.toolserver.org/browse/erfgoed/api/includes/Database.php?hb=true
> is a Database class which aims to provide a similar interface to ours.
>
>
 - Right now I'm implementing git handling using proc_open to interact
 with git's porcelain and plumbing commands. Anyone who feels up to the
 task is free to implement a PHP extension for interfacing with git we
 can swap over to using.
>>>
>>> Please, remove the usage of __call() there. Make a different function
>>> for each one, even if they're going to be dummy ones right now.
>>> This way we can easily replace them with real implementations instead of
>>> wondering which ones are called by the magic.
>>
>> Drop ShellGit entirely and make Git the only class?
>
> No, I mean:
> function diff() {
>   return call_user_func_array( array( $this->git, __METHOD__ ),
> get_func_args() );
> }
>
> function show() {
>   return call_user_func_array( array( $this->git, __METHOD__ ),
> get_func_args() );
> }
>
> etc.
>
> (still, I think ShellGit misses a __call and won't work right now)
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
John

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

Re: [Wikitech-l] Federated Login to Wikipedia. Re: OAuth

2012-03-21 Thread John Du Hart

On Wed, Mar 21, 2012 at 10:01 AM, Andreas Åkre Solberg
 wrote:
> If you are interested in doing a pilot with connecting wikipedia to Feide, we 
> may provide you with further details to proceed with that.

Yeah, I'd rather not tie down the 6 largest website in the world to an
educational login service.
-- 
John

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

Re: [Wikitech-l] integrating who's been awsome to MediaWiki

2012-03-15 Thread John Du Hart

You do realize you've been making posts on a public mailing list right?
On Mar 15, 2012 1:06 PM, "Eranga Mapa"  wrote:

> Hi Sumanah
> Still I did not hear from James
> Can you look into this matter.
> When can I get a space to host my extension in Git??
> ___
> 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] OAuth

2012-03-13 Thread John Du Hart

This isn't something that can be implemented as an extension, it needs
to be in core. This goes way beyond just allowing a user to log in to
a site with their MediaWiki account, it needs full integration with
our permissions and API to be of any use.

On Tue, Mar 13, 2012 at 8:50 AM, Petr Bena  wrote:
> Hi, it's been almost 4 years since we came with the idea of
> implementing an OAuth to mediawiki. I think it's time to start.
> Question now is if it should be a part of core or extension for
> mediawiki. I myself would rather make it as extension, since there is
> probably no use for most of installations, except for large wikis.
>
> Quote:
> OAuth provides a standard protocol to negotiate secure access tokens
> and to provide third-party tools (web or client) with granular access
> to private resources. This protocol does not reveal usernames or
> passwords to the third-party tool. Offering OAuth based authorization
> on Mediawiki wiki's will increase the reusability of its data and spur
> the creation of an ecosystem of app's around Mediawiki.
>
> Is there anyone who is willing to help with this? If there is no one
> interested in this, or no comments, I would start a new extension
> called OAuth, which only purpose would be to enable this feature in
> mediawiki.
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
John

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

Re: [Wikitech-l] Database dump of Bugzilla

2012-03-03 Thread John Du Hart

I don't understand the question. Are you implying that I have some sort of
relationship with one of these vendors? If that's the case then I'd like to
inform you that's not the case. My motive here is giving developers and
users access to better tools so that we can make a better product.
On Mar 3, 2012 7:08 PM, "David Gerard"  wrote:

> On 3 March 2012 23:52, John Du Hart  wrote:
> > On Mar 3, 2012 6:35 PM, "Antoine Musso"  wrote:
>
> >> My point. I do not think there is anything better for us than Bugzilla.
>
> > I know you don't think that currently however I would like the
> opportunity
> > to convince you otherwise.
>
>
> Which one are you involved with?
>
>
> - 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] Database dump of Bugzilla

2012-03-03 Thread John Du Hart

I know you don't think that currently however I would like the opportunity
to convince you otherwise.
On Mar 3, 2012 6:35 PM, "Antoine Musso"  wrote:

> Le 03/03/12 23:37, David Gerard a écrit :
> 
>
>> Have you ever fixed it when it's broken? Anything looks good when it's
>> working, but I've found the experience of trying to bugfix a broken
>> Mantis horrible.
>>
>
> Luckily, I had people fixing my bug reports :-)
>
>  If Bugzilla mostly works and its breakages have so far been fixable
>> in-house, that's a *powerful* advantage right there, and it would take
>> really quite strong reasons to move.
>>
>
> My point. I do not think there is anything better for us than Bugzilla.
>
> --
> Antoine "hashar" Musso
>
>
> __**_
> 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] Database dump of Bugzilla

2012-03-03 Thread John Du Hart

It's a bug tracker. It's not critical to the operation of a clone and can
be replaced. In fact, some teams are using mingle which is a proprietary
agile project manager.
On Mar 3, 2012 6:26 PM, "David Gerard"  wrote:

> On 3 March 2012 22:44, John Du Hart  wrote:
>
> > I really don't understand why we'd rather suffer than use a superior
> > proprietary product.
>
>
> https://wikimediafoundation.org/wiki/Values
>
> Duplicability down to the infrastructure is considered extremely
> important, or the free content isn't free. "Open core" fails this
> test.
>
>
> - 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] Database dump of Bugzilla

2012-03-03 Thread John Du Hart

On Sat, Mar 3, 2012 at 5:25 PM, Chad  wrote:
> Then again, I'm fine with the status quo so I'm not volunteering to
> test anyway.
>

Oops too late, already had you down ;)

-- 
John

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

Re: [Wikitech-l] Database dump of Bugzilla

2012-03-03 Thread John Du Hart

On Sat, Mar 3, 2012 at 5:38 PM, David Gerard  wrote:
> On 3 March 2012 20:23, John Du Hart  wrote:
>
>> I agree with that, just because it's proprietary doesn't mean we can't
>> consider it.
>
>
> It's a seriously strong point in its disfavour.
>
>
> - d.
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

I really don't understand why we'd rather suffer than use a superior
proprietary product.

-- 
John

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

Re: [Wikitech-l] Database dump of Bugzilla

2012-03-03 Thread John Du Hart

On Mar 3, 2012 2:20 PM, "Antoine Musso" +
wmf @
free.fr>
wrote:
>
> Le 03/03/12 02:11, John Du Hart a écrit :
>
>> I'm currently investigating alternative bug tracker and project
management
>> software for MediaWiki. To do that I'll be installing some different
>> software on the Labs and importing existing bugs for evaluation by the
>> development team and users.
>
>
> Hello John,
>
> I beg you to first establish a list of requirements and features we are
looking after.  You do not want to invest any time installing a software we
could dismiss right away just by looking at its specs (see at the bottom of
this mail for examples).
>

Fair enough. I think what I'm looking for is a bug tracker that is more
easier to use for both developers and users. I would also like tools that
allow us to better visualize progress on bugs and what's fixed or needed
for a released. Finally an API that doesn't suck would be nice

> Let me ask you a question, why do you feel we should move to another bug
tracker?
> Do you think that Bugzilla is missing features we could use?
> For example, maybe some bug tracker also assist in planning release
management.  I know Mantis has a nice interface for that.
> Is that because other tools have a nicer interface? We could probably
enhance the Bugzilla one.
>
> I am not a huge fan of Bugzilla. It is certainly lagging in terms of neat
features lack reporting and ease of navigation between components. But so
far, Bugzilla seems to fit our needs nicely.
>

But I'm sure we could do better!

> As for testing there is probably no point in loading our existing bugs
since close to nobody, beside hexmode, know our bugs well enough to take
advantage of it.  Instead we can use some demo accounts or just install a
version for sandboxing purposes. Both way would be easier than investing
time in migrating bugs to some other tracker.
>

I disagree. I think that if the software supports an importer it wouldn't
hurt to use it for the demo.

> If you want some bugs, you can try out Bugzilla JSON interface which is
used to generate the release reports. Entry point is:
>  https:// <https://bugzilla.wikimedia.org/jsonrpc.cgi>
bugzilla.wikimedia.org
<https://bugzilla.wikimedia.org/jsonrpc.cgi>/<https://bugzilla.wikimedia.org/jsonrpc.cgi>
jsonrpc.cgi <https://bugzilla.wikimedia.org/jsonrpc.cgi>
>

Again most of the software supports an import via a database dump so I'd
rather use that.

> Guillaume wrote a blog post about bug tracker, you might want to have a
look at it:
> http://<http://www.gpaumier.org/blog/520_scaling-up-software-development-for-wikimedia-websites-tools/>
www.gpaumier.org<http://www.gpaumier.org/blog/520_scaling-up-software-development-for-wikimedia-websites-tools/>
/blog/520_scaling-up-software-development-for-<http://www.gpaumier.org/blog/520_scaling-up-software-development-for-wikimedia-websites-tools/>
wikimedia<http://www.gpaumier.org/blog/520_scaling-up-software-development-for-wikimedia-websites-tools/>
-websites-tools/<http://www.gpaumier.org/blog/520_scaling-up-software-development-for-wikimedia-websites-tools/>
>

Interesting. Again, it seems we're in agreement for the need of a better
project management tool.

>
> Find below my comments about the proposed softwares:
>
>> The following software is planned for test:
>>
>>  - JIRAhttp://www.atlassian.com/software/jira/overview>
www.atlassian.com <http://www.atlassian.com/software/jira/overview>
/software/ 
<http://www.atlassian.com/software/jira/overview>jira<http://www.atlassian.com/software/jira/overview>
/overview <http://www.atlassian.com/software/jira/overview>>
>> + Greenhopper + Bonfire
>
>
> I guess it was installed on Toolserver just because it was written in
Java, a language that River Tarnell like.
> Anyway, I would dismiss it just because that is a proprietary software.
>
>
>>- YouTrackhttp://www.jetbrains.com/youtrack/>
www.jetbrains.com
<http://www.jetbrains.com/youtrack/>/<http://www.jetbrains.com/youtrack/>
youtrack 
<http://www.jetbrains.com/youtrack/>/<http://www.jetbrains.com/youtrack/>
>
>
>
> Proprietary software as well.

Like I replied earlier, this is not a major concern.
>
>>- Redmine> <http://www.redmine.org/>www.redmine.org/<http://www.redmine.org/>
>
>>- ChiliProjecthttps://www.chiliproject.org/>
www.chiliproject.org/ <https://www.chiliproject.org/>>
>
>
> The later being a fork of the former. Both are written in ruby which, as
far as I know, our operation team do not want to hear about on our
production cluster.
>
>

Fair enough.

>
> > - The Bug Geniehttp://www.thebuggenie.com/index.php>

Re: [Wikitech-l] Database dump of Bugzilla

2012-03-03 Thread John Du Hart

On Sat, Mar 3, 2012 at 3:17 PM, Merlijn van Deen  wrote:
> On 3 March 2012 20:20, Antoine Musso  wrote:
>
>> Anyway, I would dismiss it just because that is a proprietary software.
>>
> I never quite understand this argument. What is wrong with using
> proprietary software if it's the best software you can use?  Or, to turn it
> around: Why force your developers to work with suboptimal software /just
> because/ it's open source?
>
> Best,
> Merlijn
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

I agree with that, just because it's proprietary doesn't mean we can't
consider it.

-- 
John

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

Re: [Wikitech-l] Database dump of Bugzilla

2012-03-03 Thread John Du Hart

On Sat, Mar 3, 2012 at 7:46 AM, Merlijn van Deen  wrote:
> However, wouldn't adapting
> Bugzilla to be less annoying be a more sensible option? Converting bugs
> always is somewhat annoying.

I agree however there's only so much that can be done to improve
Bugzilla. BZ itself is only built to be a bugtracker, however it seems
that we are starting to need more features such as scrum (since teams
using that now use a different piece of software).

-- 
John

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

[Wikitech-l] Database dump of Bugzilla

2012-03-02 Thread John Du Hart

I'm currently investigating alternative bug tracker and project management
software for MediaWiki. To do that I'll be installing some different
software on the Labs and importing existing bugs for evaluation by the
development team and users. The following software is planned for test:


   - JIRA  + Greenhopper +
   Bonfire
   - YouTrack 
   - The Bug Genie 
   - Redmine 
   - ChiliProject 

If you have any suggestions for this list I'd be glad to hear it.

Of course, this goes back to the original request. To do this I need a dump
of the current Bugzilla install. Is it possible for me to get this and
under what conditions? Thank you.

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

Re: [Wikitech-l] install php-fss on php 5.3

2012-03-02 Thread John Du Hart

I've never heard of it and do not believe it's in use in production.
On Mar 2, 2012 10:01 AM, "Yury Katkov"  wrote:

> Hi everyone!
> I want to install php module php-fss on php5.3 since I heard that it boosts
> MediaWiki performance a lot. Is it possible to do that? Is it installed on
> wikipedias?
> -
> Yury Katkov
> ___
> 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] [ANN] MediaWiki Short URL Builder configuration tool

2012-02-27 Thread John Du Hart

On Feb 27, 2012 9:57 PM,  wrote:
>
> Actually if you put it in the installer you are making a commitment to
> handhold them through thick and thin, though better and worse, till the
> death of their wiki do we part. I do (NOT!).
>

What.

> > "C" == Chad   writes:
> >> Plus, I might know how to maintain them now, but five years later will
I
> >> still know? I'm not getting any younger.
>
> C> I can't speak for nginx or IIS or lighttpd, but I know that Apache's
> C> mod_rewrite has been functioning the same way for a long time, so I
can't
> C> imagine that configuration for that will change. On the MediaWiki
side--we
> C> haven't changed the behavior of $wgArticlePath, $wgScriptPath and the
> C> rest in a very very long time (and I can't imagine we'd break it
either).
>
> I'm talking about me. I can't even understand the comments I myself
> wrote in code six months ago.
>

Sounds like you need to write better comments then.

> C> The process is different for each webserver, which is why there's
> C> no "one-size-fits-all" answer to how to do this.
>
> Anyways, I'll stick with my Big Ten Inch,
> http://www.youtube.com/watch?v=b_VqNuLdrGo&list=PL648DE656FFB7A7A7
>
> ___
> 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] [ANN] MediaWiki Short URL Builder configuration tool

2012-02-24 Thread John Du Hart

Thanks jidanni, I'm glad that we can always count on you for fair and
balanced opinion.
On Feb 24, 2012 8:48 PM,  wrote:

> http://shorturls.redwerks.org/ should link to
> http://www.mediawiki.org/wiki/Manual:Short_URL#Advantages_.26_disadvantages.
> for a balanced view. I'll stick with my long URLs.
>
> ___
> 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] [GSoC 2012] Proposal - Realtime Collaboration on Visual Editor

2012-02-19 Thread John Du Hart

No, that's not the answer.
On Feb 19, 2012 8:22 AM, "Thomas Gries"  wrote:

> Am 19.02.2012 14:20, schrieb Ashish Dubey:
> > Hi Everyone
> >
> > The idea of realtime collaboration,
>
>
> use Etherpad Lite
> See https://www.mediawiki.org/wiki/Extension:EtherpadLite
>
>
>
> ___
> 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 Skinning Tutorial

2012-02-14 Thread John Du Hart

This is amazing Daniel, the depth of it is astounding. Thank you so much.

On Mon, Feb 13, 2012 at 5:27 PM, Daniel Friesen
 wrote:
> I finally have a tutorial on MediaWiki Skinning for 1.18+ online on
> Redwerks' Blog.
> http://blog.redwerks.org/2012/02/08/mediawiki-skinning-tutorial/
>
> The tutorial covers the general conceptual areas of a skin, laying out the
> files for a skin, all the small boilerplate pieces used to output types of
> content, an overview of things you should test for in your skin when
> implemented, a bit on i18n and related info on variants and rtl, and a touch
> on accessibility.
>
> --
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
John

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

Re: [Wikitech-l] Phabricator

2012-02-13 Thread John Du Hart

Good idea, I've done just that.

https://www.mediawiki.org/wiki/Phabricator/todo
On Feb 13, 2012 1:33 PM, "Ryan Lane"  wrote:

> > I compeletely agree with that. It would be a complete waste to have chad
> > and others' work from the past 5 months thrown away at the last minute
> for
> > a solution brought up this late. We can initially use git for the
> migration
> > however if we decide to later, Phabricator is still available. :-)
> >
>
> Indeed. We should continue to evaluate phabricator, and see if it fits
> our model better than Gerrit in the long run. Also, we should start
> keeping a list of things phabricator needs to be usable (like we are
> doing with Gerrit).
>
> - Ryan
>
> ___
> 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 Complete Rewrite of Mobile Frontend & Rename MobileFrontend2

2012-02-13 Thread John Du Hart

Just as a note I've made a reply to the other thread, "MobileFrontend
& John Du Hart's rewrite"

On Sun, Feb 12, 2012 at 5:39 PM, Ryan Lane  wrote:
>> We already have SubPageList, SubPageList2, and SubPageList3 sitting around
>> (SubPageList and SubPageList3 are in SVN, SubPageList is supposed to be the
>> one more up to date then either the 2 or 3) inside MW.org and SVN. Heck it's
>> hard to have as much of a naming mess as we've had with Dynamic Page List.
>> So I see no reason for MobileFrontend2 to be forced to be renamed.
>>
>> Can we just let John DuHart get on with writing the code so that we can have
>> a working 1:1 replacement, put it through all the testing we need to make it
>> the mobile code used on WMF's cluster, and then replace MobileFrontend/ with
>> MobileFrontend2/'s code.
>>
>
> And for ages there was confusion about which one was actually up to
> date and usable. At some point everything just said "Use SubPageList,
> it's the up to date version". Same thing with DynamicPageList. People
> expect things with what appear to be version numbers. It's unfriendly,
> at least, to name an extension to look like a newer version.
>
> Is it really too much to ask for it to be named something else?
>
> - Ryan
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
John

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

Re: [Wikitech-l] Welcome David Schoonover - Systems Engineer - Data Analytics

2012-02-13 Thread John Du Hart

On Mon, Feb 13, 2012 at 12:07 PM, Rob Lanphier  wrote:
> I've also found David will immediately will draw a dinosaur[2] on a
> whiteboard in whatever room he is in.  So, those of you in our SF
> office, if you see a plesiosaur on the whiteboard near you, that
> probably means he's been there recently.  Or maybe it's been there a
> while but now won't erase.  Either way, he probably drew it.

Hey I like dinosaurs! Welcome David!


-- 
John

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

Re: [Wikitech-l] MobileFrontend & John Du Hart's rewrite

2012-02-13 Thread John Du Hart

Thanks to everybody for talking through this and clarifying the issues.

So I'd like to move forward and figure out how we all should proceed.

I'm completely fine with renaming MobileFrontEnd2 to help avoid
confusion.  :-)  I'll look at the suggestions and pick one.

My ideal scenario would be me continuing this rewrite while the mobile
team continues with feature development on MobileFrontend. I really
believe that there are several issues with the current MobileFrontend
that are better resolved with a full rewrite instead of a slow
refactoring of the existing extension.  But I'm also happy to work with
Arthur to refactor and rewrite the current MobileFrontend more gradually
to resolve the issues raised.

I could work with the mobile team to come up with a checklist of goals
to complete in the refactoring and rewriting before we can write off the
need for a replacement for MobileFrontend. Functionaility wise,
MobileFrontend2 is a clone of the original with very minimal UI changes.
Maybe we could write Selenium tests for this?  Maybe I could work with
Chris McMahon to learn what tests need writing for this extension and
write them.

--
John

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

Re: [Wikitech-l] Phabricator

2012-02-13 Thread John Du Hart

On Fri, Feb 10, 2012 at 9:59 PM, Rob Lanphier  wrote:

>  On Fri, Feb 10, 2012 at 12:01 PM, John Du Hart 
> wrote:
> > Just want to check in to see how everyone's doing. I see a lot of account
> > creations however no posts to differential. Is there a problem I'm not
> > aware of? Documentation problems? Software issues? Do we see something we
> > don't like?
> >
> > What's up?
>
> Hi John,
>
> Just mulling it over, mainly.  I love having a test instance to play
> with, and agree with you that it looks way easier to use than Gerrit
> on the surface.  I don't want that to be taken as an endorsement of
> the system just yet, because I don't know enough about either system
> (Gerrit or Phabricator) to have a valid opinion about which is better
> for us.
>
> What Chad, Sumana and I spoke about earlier today was the tough
> reality we're in.  In order to get moved to Git in the very short
> term, we're going to have to stay the course on Gerrit.  That said,
> one beautiful thing about Git is that Git repos are far more portable
> than SVN repos.  We could decide we're going to use Gerrit on a
> probationary basis, and have a serious reevaluation in three months.
> Sumana and I would like to go in that direction, and we twisted Chad's
> arm hard enough on this point that he might just say he agrees with
> us, even if he's secretly blowing us off ;-)
>
> There's at least one feature we would need to use this system, which
> is LDAP integration.  I don't think we can seriously consider a system
> that doesn't have some sort of sensible plan for how it's going to
> work with our LDAP server.  I do, however, love the idea of using
> OAuth for filling in credentials from other services like Github.  It
> would be ridiculously cool if people could use their Wikimedia SUL
> logins to access this system.
>
> It's also nice that this is written in PHP.  Since we have an
> abundance of PHP developers, that means it's far more likely that
> customization we need would actually happen.
>
> In general, it's good to have options.  Like I said, I don't want to
> put the brakes on our immediate plans, but I think it's worth
> consideration after we've given Gerrit a try.
>
> Rob
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>


I compeletely agree with that. It would be a complete waste to have chad
and others' work from the past 5 months thrown away at the last minute for
a solution brought up this late. We can initially use git for the migration
however if we decide to later, Phabricator is still available. :-)

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

Re: [Wikitech-l] RFC Complete Rewrite of Mobile Frontend & Rename MobileFrontend2

2012-02-12 Thread John Du Hart

On Feb 12, 2012 5:15 AM, "Arthur Richards"  wrote:
>
> On Sun, Feb 12, 2012 at 2:48 PM, K. Peachey  wrote:
> >
> > I think it's actually better completely out from the current extension
> > for a few reasons,
> >
> > * MF1 is currently a cluster extension so all the code needs to be
> > reviewed before deployed
> > * MF1 is already regularly deployed (close to weekly iirc)
> > * John is working on having it [MF2] operate in a completely different
> > method than current [MF1] so it would avoid possible breakage and
> > compatibility issues
> >
>
> I think you make good points here - we definitely understand the logic. A
> lot of the things I think John is planning to address in his new extension
> are things that we also would like to see in the existing MobileFrontend
> extension, so hopefully we will be able to still coordinate and work
> together to minimize duplicated work.
>
>
> > >  However, we feel that naming the rewrite 'MobileFrontend2' is
> > problematic
> > > as users have already started to confuse it with the current
extension.
> >
> > Whom? It's not like it's really advertised anywhere apart from CR and
> > SVN so it shouldn't be causing that many issues at the current stage.
> >
>
> Place a '2' after an existing extension name implies that it is an
> improved, and newer, version of an existing extension. Assuming John will
> be building his extension as something completely different from the
> existing MobileFrontend (like you outlined above), it is inappropriate to
> name it 'MobileFrontend2'. We should work to find an acceptable
alternative
> that makes its functionality clear, and clearly differentiates it from the
> existing MobileFrontend extension.
>

If it wasn't a rewrite I wouldn't of placed a two after. Functionality
wise, this will be a 1:1 replacement, with back end changes only.

> --
> Arthur Richards
> Software Engineer, Mobile
> [[User:Awjrichards]]
> IRC: awjr
> +1-415-839-6885 x6687
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Phabricator

2012-02-11 Thread John Du Hart

On Sat, Feb 11, 2012 at 4:46 PM, Ryan Lane  wrote:

> On Fri, Feb 10, 2012 at 5:08 AM, John Du Hart 
> wrote:
> > Unless you've been living under a rock (If you have, how's the wifi under
> > there?) we're moving to git soon. Along with this will come a change in
> how
> > we do code review. However, some people have expressed concerns over the
> > usability of gerrit. Therefore I'd like to propose an alternative.
> >
> > Phabricator is a code review tool written by and for Facebook that has
> > been open sourced. For an introduction, see this:
> > http://phabricator.com/docs/phabricator/article/Introduction.html
> >
> > I've written up some documentation about Phabricator for our uses here:
> > https://www.mediawiki.org/wiki/Phabricator
> >
> > I would really like for some of our developers and reviewers to try this
> > out as an alternative to gerrit. Personally I've found it much more
> > pleasurable to work with than gerrit. If we think this might be a viable
> > solution for us then I'd be willing to work on adding more integration
> > (LDAP support and Unit testing integration).
> >
> > Let me know if you have any questions or feedback. Thanks!
> >
>
> I forgot. There's one other thing I wanted to point out about
> phabricator. To properly use it, you must have php installed wherever
> you are working from. I like that it uses PHP on the server side, but
> despise that it uses it on the client side.
>
> I also have a few questions:
>
> * Who's going to get stuck with maintaining the LDAP support?
> * Does it already integrate with Jenkins?
> * Does it use the system SSH, or a separate SSH daemon?
> * What permissions model does it have?
> * Does it manage the repositories and branches?
> * How are repos created?
> * Does it support server side branches?
> * Does it handle merges automatically?
>
> - Ryan
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

* Me
* Why would it need to, it runs unit and lint tests before the diff is
posted

The rest of the questions are irrelevant because, unlike gerrit,
Phabricator does not manage git repositories.

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

Re: [Wikitech-l] Phabricator

2012-02-10 Thread John Du Hart

Just want to check in to see how everyone's doing. I see a lot of account
creations however no posts to differential. Is there a problem I'm not
aware of? Documentation problems? Software issues? Do we see something we
don't like?

What's up?

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

Re: [Wikitech-l] MobileFrontend & John Du Hart's rewrite

2012-02-10 Thread John Du Hart

On Fri, Feb 10, 2012 at 12:53 PM, Sumana Harihareswara <
suma...@wikimedia.org> wrote:

> John, Patrick, and anyone else who is interested in the MobileFrontend
> extension:
>
> John Du Hart is working on a rewrite, aiming to make it less Wikimedia
> Foundation-centric, and there is disagreement regarding whether his
> rewrite is desired.  Please read and comment:
>
>
> https://www.mediawiki.org/wiki/Extension_talk:MobileFrontend#Issues_with_MobileFrontend_and_possible_rewrite_11940
>
> (Can someone please forward this to mobile-l as well?  Thanks.)
>
> --
> Sumana Harihareswara
> Volunteer Development Coordinator
> Wikimedia Foundation
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

I've replied on the talkpage.

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

[Wikitech-l] Phabricator

2012-02-09 Thread John Du Hart

Unless you've been living under a rock (If you have, how's the wifi under
there?) we're moving to git soon. Along with this will come a change in how
we do code review. However, some people have expressed concerns over the
usability of gerrit. Therefore I'd like to propose an alternative.

Phabricator is a code review tool written by and for Facebook that has
been open sourced. For an introduction, see this:
http://phabricator.com/docs/phabricator/article/Introduction.html

I've written up some documentation about Phabricator for our uses here:
https://www.mediawiki.org/wiki/Phabricator

I would really like for some of our developers and reviewers to try this
out as an alternative to gerrit. Personally I've found it much more
pleasurable to work with than gerrit. If we think this might be a viable
solution for us then I'd be willing to work on adding more integration
(LDAP support and Unit testing integration).

Let me know if you have any questions or feedback. Thanks!

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

Re: [Wikitech-l] Picture of the Year contest extension

2012-02-05 Thread John Du Hart

On Sat, Feb 4, 2012 at 6:32 PM, Mono  wrote:

> Hi,
>
> It's likely many of you have heard of or even participated in the Picture
> of the Year contest. Every year, the Wikimedia community votes for a
> picture of the year from the pool of images promoted to featured picture
> status in the previous year on the Wikimedia Commons. This typically occurs
> in late spring; last year's contest took place in May and was a huge
> success.
>
> This year, we're looking to improve the operation of the contest. In the
> past, with the notable exception of a community-developed JavaScript
> interface, the galleries, voting, and counting has been done manually. This
> hurts the efficiency of the contest significantly, as these somewhat
> tedious tasks will be repeated year after year.
>
> It would be really wonderful if we could get a couple of developers to put
> an extension together. I've searched fairly extensively for something that
> would be sufficient for our needs and I've come to the conclusion that
> building such an extension would be the most future-proof and efficient way
> to accomplish the task.
>
> I considered using a Toolserver-based system, but authenticating users in a
> SecurePoll-like way on a large scale would be difficult. (It's possible
> that some parts of the SecurePoll code could be used for this.) The
> functionality needs for the extension include:
> *a front-end voting gallery where users can vote while logged in with a SUL
> account on Commons
> *an administration panel to manage the front-end galleries, including
> account verification requirements, dates, and statistics
> *a user right for committee members to access the interface
>
> This is certainly a "project," but it could be used for every POTY contest,
> perhaps some other contests, and it doesn't have to be elaborate. However,
> as I said, it would be really great if we could get just a couple people
> who have some experience developing MediaWiki extensions to help program
> this in time for this year's contest.
>
> If anyone is interested in helping out or would like some more information,
> please contact me as soon as possible - anything helps!
>
> Thanks,
> User:Mono
>
> --
> Sent from my iPad
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

For someone who is not fimilar with the commons PoTY voting process, could
you share with us some dates so we have an idea of when the delivery date
would be?

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

Re: [Wikitech-l] how did spammers spam only some pretty links?

2012-01-23 Thread John Du Hart

On Mon, Jan 23, 2012 at 6:16 AM,  wrote:

> How did the spammers manage to spam only the third file?
> 17097 http://mapki.com/wiki/Main_Page
> 17097 http://mapki.com/mediawiki/index.php?title=Main_Page
> 11985 http://mapki.com/wiki/Google_Map_Parameters
> 39100 http://mapki.com/mediawiki/index.php?title=Google_Map_Parameters
> I have almost given up on that site.
> http://mapki.com/wiki/Sitesupport-url is useless, and as usual there is
> no way to contact the Sysop.
> I think the config scripts should drive home how important it is to make
> sure users can contact the owner, with plenty of fields for such
> information, etc. and a Special Page called Contact where that stuff
> gets stored. Important things not to forget for non WMF sites!
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

Probably poorly written bot scripts that only work off of pretty URLs.

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

Re: [Wikitech-l] [Foundation-l] COMPLETED: Mailing lists server migration today

2012-01-22 Thread John Du Hart

On Sun, Jan 22, 2012 at 11:51 PM, John Vandenberg  wrote:

> Hi Mark,
>
> There are a lot of http links to mail.wiki[pm]edia.org, where mailman
> and pipermail used to work.  They are in email footers headers and in
> Wikipedia.
>
>
> https://google.com/search?q=%22mail.wikipedia.org%22+-site:lists.wikimedia.org
>
> Thanks,
> John Vandenberg
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

Confirming this, they still point to the older IP. Probably should be set
to CNAME the new sub-domain.

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

Re: [Wikitech-l] Help needed getting rid of the last bits of hook LanguageGetMagic

2012-01-19 Thread John Du Hart

FlaggedRevs and MetavidWiki done
https://www.mediawiki.org/wiki/Special:Code/MediaWiki/109571

For LST there's already hardcoded translations and I'm not sure how to do
those. Is it right to include the english ones in the translations?

On Thu, Jan 19, 2012 at 9:43 AM, John Du Hart  wrote:

> I'll take of of those last 3 usages.
>
>
> On Thu, Jan 19, 2012 at 9:12 AM, Siebrand Mazeland 
> wrote:
>
>> Dear all,
>>
>> Over the past days I've been trying to get rid of the deprecated hook
>> LanguageGetMagic in the repo[1]. I've updated about 60 extensions, I
>> estimate, to use $magicWords imported through $wgExtensionMessagesFiles,
>> instead of the hook.
>>
>> As you may know, I'm not much of a developer, so when it gets harder, I
>> throw the towel in the ring... There are three extensions that make a more
>> esotheric use of LanguageGetMagic, that I'm not able to convert to use
>> $magicWords. These are:
>>
>> * FlaggedRevs/FlaggedRevs.setup.php:
>> $wgHooks['LanguageGetMagic'][] = 'FlaggedRevsHooks::onLanguageGetMagic';
>> * LabeledSectionTransclusion/lst.php:$wgHooks['LanguageGetMagic'][] =
>> 'LabeledSectionTransclusion::setupMagic';
>> *
>> MetavidWiki/includes/MV_GlobalFunctions.php:$wgHooks['LanguageGetMagic'][]
>> = 'mvMagicParserFunction_Magic';
>>
>> If you can help out here, please do so. It would be much appreciated.
>>
>> Next, in my opinion, would be to start throwing warnings using
>> wfDeprecated on use of the hook LanguageGetMagic, but I haven't really
>> been able to find where that could be done for a hook. If you can be of
>> help there, please let me know. There may also be some other deprecated
>> hooks that could get more attention if they would throw warnings on use.
>>
>> [1]
>> https://www.mediawiki.org/wiki/Special:Code/MediaWiki/tag/languagegetmagic
>>
>> Cheers!
>>
>> Siebrand
>>
>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>
>
>
> --
> John
>



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

Re: [Wikitech-l] Help needed getting rid of the last bits of hook LanguageGetMagic

2012-01-19 Thread John Du Hart

I'll take of of those last 3 usages.

On Thu, Jan 19, 2012 at 9:12 AM, Siebrand Mazeland wrote:

> Dear all,
>
> Over the past days I've been trying to get rid of the deprecated hook
> LanguageGetMagic in the repo[1]. I've updated about 60 extensions, I
> estimate, to use $magicWords imported through $wgExtensionMessagesFiles,
> instead of the hook.
>
> As you may know, I'm not much of a developer, so when it gets harder, I
> throw the towel in the ring... There are three extensions that make a more
> esotheric use of LanguageGetMagic, that I'm not able to convert to use
> $magicWords. These are:
>
> * FlaggedRevs/FlaggedRevs.setup.php:
> $wgHooks['LanguageGetMagic'][] = 'FlaggedRevsHooks::onLanguageGetMagic';
> * LabeledSectionTransclusion/lst.php:$wgHooks['LanguageGetMagic'][] =
> 'LabeledSectionTransclusion::setupMagic';
> *
> MetavidWiki/includes/MV_GlobalFunctions.php:$wgHooks['LanguageGetMagic'][]
> = 'mvMagicParserFunction_Magic';
>
> If you can help out here, please do so. It would be much appreciated.
>
> Next, in my opinion, would be to start throwing warnings using
> wfDeprecated on use of the hook LanguageGetMagic, but I haven't really
> been able to find where that could be done for a hook. If you can be of
> help there, please let me know. There may also be some other deprecated
> hooks that could get more attention if they would throw warnings on use.
>
> [1]
> https://www.mediawiki.org/wiki/Special:Code/MediaWiki/tag/languagegetmagic
>
> Cheers!
>
> Siebrand
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



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

Re: [Wikitech-l] Wednesday wikipedia shut down does not get through

2012-01-19 Thread John Du Hart

On Thu, Jan 19, 2012 at 5:56 AM, Thomas Dalton wrote:

> On 19 January 2012 02:48, Daniel Friesen 
> wrote:
> > You do realize that going by what you are saying. If 503's weren't cached
> > for that reason, then EVERY single request would be forwarded to the
> > apaches.
>
> I'm talking about external caches, as I assumed everyone else was. The
> internal caches are entirely under the WMF's control so they can be
> made to do whatever the WMF wants them to do. There's no problem
> there.
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>


The operations team can indeed do "whatever they want", however they do not
have infinite amount of time to determine how to do it and test it

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

Re: [Wikitech-l] Wednesday wikipedia shut down does not get through

2012-01-18 Thread John Du Hart

Cache pollution.

On Wed, Jan 18, 2012 at 12:57 PM, OQ  wrote:

> On Wed, Jan 18, 2012 at 11:49 AM, Chad  wrote:
> > On Wed, Jan 18, 2012 at 12:31 PM, Thomas Gries  wrote:
> >>> You should do a straightforward real shutdown instead, and deliver a
> fake 404 with explanation link.
> >>> And for several more days.
> >> +1
> >>
> >
> > Doing it via 404s would mess up search engines.
> >
> > -Chad
> >
>
> Do it via 503's then.
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



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

Re: [Wikitech-l] Change request please: Congress Lookup page text

2012-01-18 Thread John Du Hart

Fixed: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/109359

On Wed, Jan 18, 2012 at 8:19 AM, Sue Gardner  wrote:

> Hey folks,
>
> I'm not sure where to send this, so I'll send it here. Could someone
> please change the Congress Lookup page text, as per the note below?
> Essentially, it is changing two instances of "will" to "would" and
> adding one new "would" -- that's all. No formatting changes, just the
> three words.
>
> Thanks,
> Sue
>
> http://en.wikipedia.org/wiki/Special:CongressLookup < This page
>
> --
>
> Call your elected officials.
>
> Tell them you are their constituent, and you oppose SOPA and PIPA.
>
> Why?
>
> SOPA and PIPA put the burden on website owners to police
> user-contributed material and call for the unnecessary blocking of
> entire sites. Small sites won't have sufficient resources to defend
> themselves. Big media companies may seek to cut off funding sources
> for their foreign competitors, even if copyright isn't being
> infringed. Foreign sites will be blacklisted, which means they won't
> show up in major search engines. SOPA and PIPA build a framework for
> future restrictions and suppression.
>
> In a world in which politicians regulate the Internet based on the
> influence of big money, Wikipedia — and sites like it — cannot
> survive.
>
> Congress says it's trying to protect the rights of copyright owners,
> but the "cure" that SOPA and PIPA represent is worse than the disease.
> SOPA and PIPA are not the answer: they will fatally damage the free
> and open Internet.
>
> CHANGE TO THIS
>
> Call your elected officials.
>
> Tell them you are their constituent, and you oppose SOPA and PIPA.
>
> Why?
>
> SOPA and PIPA would put the burden on website owners to police
> user-contributed material and call for the unnecessary blocking of
> entire sites. Small sites won't have sufficient resources to defend
> themselves. Big media companies may seek to cut off funding sources
> for their foreign competitors, even if copyright isn't being
> infringed. Foreign sites will be blacklisted, which means they won't
> show up in major search engines. SOPA and PIPA would build a framework
> for future restrictions and suppression.
>
> In a world in which politicians regulate the Internet based on the
> influence of big money, Wikipedia — and sites like it — cannot
> survive.
>
> Congress says it's trying to protect the rights of copyright owners,
> but the "cure" that SOPA and PIPA represent is worse than the disease.
> SOPA and PIPA are not the answer: they would fatally damage the free
> and open Internet.
>
> --
>
> In other words.
>
> SOPA and PIPA put the burden >>> SOPA and PIPA would put the burden
> SOPA and PIPA build a framework >>> SOPA and PIPA would build a framework
> they will fatally damage >>> they would fatally damage
>
> --
>
> Sue Gardner
> Executive Director
> Wikimedia Foundation
>
> 415 839 6885 office
> 415 816 9967 cell
>
> Imagine a world in which every single human being can freely share in
> the sum of all knowledge.  Help us make it a reality!
>
> http://wikimediafoundation.org/wiki/Donate
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




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

Re: [Wikitech-l] enable setting language preference without requiring login

2012-01-11 Thread John Du Hart

On Wed, Jan 11, 2012 at 7:57 PM,  wrote:

> Why can't MediaWiki do like all major sites' software, and allow setting
> the interface language without requiring the user to establish an account?
>
> Observe the bottom of e.g.,
> http://www.facebook.com/
> http://www.flickr.com/
> http://www.youtube.com/
> Each has a language selector that doesn't require login.
> http://www.couchsurfing.org/
> even puts it right at top.
>
> Yes, patient users  can set their language preference in Preferences.
> But what about read-only sites? I.e., What should one suggest on
>
> http://www.mediawiki.org/wiki/Manual:Preventing_access#Restrict_account_creation
> to say to users who wish to view in a different language?
> Painfully suffix "?uselang=..." to the end of each URL they browse?
>
> One might argue "users will confuse MediaWiki uselang= with
> XX.wikipedia.org languages" ... well they haven't yet with the language
> choice in Preferences.
>
> I'm not saying rip it out of Preferences. I'm saying add an additional
> way to set it for even non-logged in users, just like the aforementioned
> "real websites" do.
>
> Also consider the current accessibility up until the point the user has
> managed to register an account and finally set his/her language
> preference... all of which has to be somehow accomplished in the "dark"
> of the default language, unless he/she knows to add the magic
> uselang=... to MediaWiki URLs every step of the way.
>
> Please don't suggest an add-on for such basic functionality.
>
> OK, I filed https://bugzilla.wikimedia.org/show_bug.cgi?id=33677
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

Just wondering, is there a reason why you think it's necessary to make a
maliinglist post every time you file a bug that complains about MediaWiki
missing a feature?

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

Re: [Wikitech-l] PHP 5.3.9 released (page says "All users are strongly encouraged to upgrade to PHP 5.3.9.")

2012-01-11 Thread John Du Hart

On Wed, Jan 11, 2012 at 1:58 PM, Thomas Gries  wrote:

> Am 11.01.2012 19:42, schrieb Chad:
> > A new PHP version 5.3.9 has been released, see
> > http://www.php.net/archive/2012.php#id2012-01-11-1
> > The page says "All users are strongly encouraged to upgrade to PHP
> 5.3.9."
> >
> > They said almost the same thing for 5.3.1 too[0], and look how well that
> > turned out ;-)
> Security Enhancements and Fixes in PHP 5.3.9:
>
>  * Added max_input_vars directive to prevent attacks based on hash
>collisions. (CVE-2011-4885)
>  * Fixed bug #60150 (Integer overflow during the parsing of invalid
>exif header). (CVE-2011-4566)
>
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

Which can be easily backported

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

Re: [Wikitech-l] Bugzilla: Minor enhancements should not be tagged "highest" priority.

2012-01-03 Thread John Du Hart

So instead of bug fixes or security patches operations should spend time
deploying an extension so you know who has the most edits? Not a great idea.

On Jan 3, 2012 8:06 AM, "Strainu"  wrote:

> 2011/12/30 Dan Collins :
> > There are also numerous "highest priority" extension installations.
>
> Site request should be treated with the highest priority.
>
> Strainu
>
> ___
> 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 changes to bugs by Jan Kucera (Kozuch)

2011-12-30 Thread John Du Hart

Left him a note about this thread.
https://en.wikipedia.org/wiki/User_talk:Kozuch#Discussion_about_your_actions_in_Wikitech-l


On Fri, Dec 30, 2011 at 1:04 PM, John Du Hart  wrote:

> Revert it. Just like enwiki, you can't do stuff like this without
> discussion.
>
>
> On Fri, Dec 30, 2011 at 11:48 AM, Chad  wrote:
>
>> On Fri, Dec 30, 2011 at 11:42 AM, Jeremy Baron 
>> wrote:
>> > On Fri, Dec 30, 2011 at 11:38, Amir E. Aharoni
>> >  wrote:
>> >> As long as it's there, people will think that we do.
>> >>
>> >> This mass change should have been discussed somewhere first, but then
>> >> i never understood why voting is bad. Mozilla haven't disabled it in
>> >> their Bugzilla and Google use it in Google code (as stars), although i
>> >> don't whether either of them actually prioritize bugs according to it.
>> >
>> > I thought stars were the only way to subscribe to future updates? and
>> > hence they're not necessarily votes.
>> >
>>
>> CC list? But yes, we've just never used the voting--it's mainly just
>> there as a "favorites" type list.
>>
>> -Chad
>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>
>
>
> --
> John
>



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

Re: [Wikitech-l] Mass changes to bugs by Jan Kucera (Kozuch)

2011-12-30 Thread John Du Hart

Revert it. Just like enwiki, you can't do stuff like this without
discussion.

On Fri, Dec 30, 2011 at 11:48 AM, Chad  wrote:

> On Fri, Dec 30, 2011 at 11:42 AM, Jeremy Baron 
> wrote:
> > On Fri, Dec 30, 2011 at 11:38, Amir E. Aharoni
> >  wrote:
> >> As long as it's there, people will think that we do.
> >>
> >> This mass change should have been discussed somewhere first, but then
> >> i never understood why voting is bad. Mozilla haven't disabled it in
> >> their Bugzilla and Google use it in Google code (as stars), although i
> >> don't whether either of them actually prioritize bugs according to it.
> >
> > I thought stars were the only way to subscribe to future updates? and
> > hence they're not necessarily votes.
> >
>
> CC list? But yes, we've just never used the voting--it's mainly just
> there as a "favorites" type list.
>
> -Chad
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



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

Re: [Wikitech-l] irc bot

2011-12-15 Thread John Du Hart

On Thu, Dec 15, 2011 at 5:33 AM, Petr Bena  wrote:

> Hi all,
>
> I would like to notice that I am now working on rewrite of mw-bot,
> called wm-bot (wikimedia bot - it's supposed to serve in various
> wikimedia chans), the bot now is supporting exactly same functions as
> mw bot + some more, and I think it would be good if we replaced
> current mw-bot in future at some point. The reasons are:
>
> - Old bot is written in java and nearly no one has access to source
> code, neither is managing it, the bot is still running without
> problems rather thanks to original creator who did a great work and
> made a very stable code, extending the bot with more features could be
> problem.
>
> - New bot is in svn (tools/wmib) so that anyone can participate on
> development and even on operation of the bot
>
> - New bot is running on wmf labs so that it should be running on more
> stable server with better connectivity and also is better accessible
> for others, because apart of toolsever it's no problem to give acess
> to service user account to more devs (anyone with svn account can get
> access there) so that more people can operate the bot and patch it.
>
> I converted current database and it's running in #mediawiki-move so
> that you can try various commands like (!mediawiki !b ), any
> feedback on this whole idea and bot is welcome also please before you
> start commiting changes to source code, keep in mind that I now work
> on splitting it to more files so that we avoid conflicts when
> commiting changes, it should be done by today.
>
> Thanks
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

"- Old bot is written in java"

And C# is an improvement?

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

Re: [Wikitech-l] Compiling Debian Packages (was Re: 1.18 PHP version requirement)

2011-11-21 Thread John Du Hart

So instead of having a script that just has to run basic unix commands in
order to manage vhosts you now need something to parse an http.conf file.

I'm pretty sure I know what I'd choose.

On Nov 20, 2011 1:25 AM, "Dmitriy Sintsov"  wrote:

On 19.11.2011 22:59, Happy Melon wrote:
> "Better" here is clearly in the eye of the beholder. The ...
My method does not require creation of symlinks and numeric prefixes,
that's why it's better. Ancient languages used numeric labels for lines
of code. Cut / paste of single text line is faster than renaming
symlinks. Commenting line with # is better as well. These points are
objective, not subjective. I would stop talking about that yesterday if
you weren't insisting that it's a personal preference (it's not).
Dmitriy



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

[Wikitech-l] Coding Convention: Method chaining

2011-11-15 Thread John Du Hart

Right now our coding conventions manual never touches on method chaining,
nor have I personally seen this practice in core. So I'm interested in what
the rest of the community feels about adapting this practice more, and if
there are trade offs I'm not aware of. Let's make an example, take this
code from Abuse Filter:

$out = $this->getOutput();
$out->setPageTitle( wfMsg( 'abusefilter-examine' ) );
 $out->addWikiMsg( 'abusefilter-examine-intro' );

So, instead of writing it like that, it could be written

 $this->getOutput()
->setPageTitle( wfMsg( 'abusefilter-examine' ) )
 ->addWikiMsg( 'abusefilter-examine-intro' );

It's just another style I've encountered on other projects and I personally
like.

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

Re: [Wikitech-l] [Ticket#2011091710005702] SVN Extension Access

2011-11-04 Thread John Du Hart

>> One of the access-granting developers looked at the code sample,
>> Extension:Realnames, and had some criticisms, as it tries to find and 
>> replace all
>> username links in the page output HTML, and the User::newFromName( 
>> $m['username']
>> ); query in the callback for each match is not batched.
>>

We're really being that nitpicky? I've seen some really shit-quality
code committed to extensions, batch calling the User class is really
minor thing that (imo) shouldn't halt this process. It's extensions
access, not core, he's asking for.

That's what I have to say right now, I might some up with something
else tomorrow.

-- 
John

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

Re: [Wikitech-l] Temporary password too short

2011-10-26 Thread John Du Hart

No, maybe stewards but not admins.

On Oct 26, 2011 9:40 AM, "Olivier Beaton"  wrote:

> Admins should be required (At least at wmf) to use an authenticator, no?
>
> On Wed, Oct 26, 2011 at 9:24 AM, Helder  wrote:
> > On Wed, Oct 26, 2011 at 11:13, Neil Harris 
> wrote:
> >>
> >> If there's one measure I'd like to see that isn't (as far as I know) yet
> >> implemented, it would be to require admins and other privileged users to
> set
> >> strong passwords, perhaps initially by Javascript-based warnings, and
> later
> >> by locking out those accounts completely, after a warning period of
> perhaps
> >> one year.
> >
> >
> > +1
> > ___
> > 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] migration to git: available and suggested Web viewers ?

2011-10-23 Thread John Du Hart

On Sun, Oct 23, 2011 at 6:45 AM, Daniel Friesen
 wrote:
> On Sun, 23 Oct 2011 02:09:29 -0700, Thomas Gries  wrote:
>
>> RE: http://www.mediawiki.org/wiki/Git_conversion
>>
>> For Subversion SVN, ViewVC is a nice repository browser, which we also
>> use on
>> http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/
>>
>> I searched for similar browsers for "git", but could not find similar
>> ones.
>>
>> My starting point was
>> http://stackoverflow.com/questions/438163/whats-the-best-web-interface-for-git-repositories
>>
>> found:
>> gitalist http://www.gitalist.com/
>> gitweb http://git.or.cz/gitwiki/Gitweb
>> cgit http://hjemli.net/git/cgit/
>> FishEye (Atlassian, not free)
>>
>> Perhaps, ViewVC can be "patched" to work with git ?
>>
>> This page http://www.mediawiki.org/wiki/Git_Graphical_User_Interfaces
>> is (currently) only dedicated to Git GUIs, not to Git Viewers:
>> perhaps a page for Git Viewers should be started, too?
>>
>>
>
> The general standard is GitWeb, it's even bundled with Gerrit so it will
> be the default available when git is setup:
> https://gerrit.wikimedia.org/r/gitweb?p=operations%2Fpuppet.git
>
> 'patching' ViewVC to work with git will be impossible. git is
> fundamentally different from svn so there are so many differences you'll
> have to rewrite it completely.
>
> Besides the ones you list there is one built into Gitorious:
> https://gitorious.org/mediawiki/mediawiki-trunk-phase3/trees/master
>
> When I talked with Ryan Lane about our git setup one of the things he
> mentioned was how with Labs it would be possible for me to setup Gitorious
> on Labs, puppetize it, and later have it pushed out to production. Since
> git is distributed there isn't much to setting up a new git ui. So later
> on it should be possible for anye of us to setup whatever other git ui we
> like and have it pushed out to production... heck, we could have as many
> as we want.
>
> --
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>


I'll throw GitLab into the ring, http://gitlabhq.com/

It's ruby though, so I don't know if ops will care for that. It does
look pretty sweet though.

-- 
John

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

Re: [Wikitech-l] Bootstrapping Music (was Re: Bug 189)

2011-10-23 Thread John Du Hart

On Sun, Oct 23, 2011 at 5:34 PM, John Vandenberg  wrote:
>
> Does the lilypond '-safe' mode not resolve the security problems?
>

According to the other thread, nope.

--
John

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

Re: [Wikitech-l] wikipedia lacks a "share' button

2011-10-21 Thread John Du Hart

I agree with this, it's really not a technical issue at this point so it
doesn't have a place on wikitech-l

On Fri, Oct 21, 2011 at 10:06 AM, Russell Nelson wrote:

> This sounds like something non-technical, like you would discuss at a
> village pump. Maybe you should do that and then get back to us with a
> greater variety of user opinions? If you're right and this is a dumb idea,
> then you'll save us a lot of time by canvassing users.
> -russ
>
> On Fri, Oct 21, 2011 at 9:27 AM, John Du Hart 
> wrote:
>
> > Why.
> >
> > Why does an encyclopedia need a share button? I can see the purpose on
> > Commons, but for an article? I just don't see the justification. What do
> > you
> > really need to share with your friends from an reference source. What
> does
> > a
> > button do that copypaste can't?
> >
> > There's also the technical problems this would incur. Each of these
> buttons
> > require yet another HTTP request each, which would make the hard work by
> RL
> > team moot.
> >
> > It just doesn't make sense.
> >
> > On Oct 20, 2011 11:54 PM,  wrote:
> > Gentlemen, where is the Share button?
> > All other sites have them by now, but on Wikipedia one cannot even find
> > its definition in http://en.wikipedia.org/wiki/Share .
> > At least on ones account preferences there should be a way to "activate
> > sharing with the following websites ... " causing a share button to
> > appear in the navigation menu.
> > If there is an extension, then wikipedia should install it and not
> > depend on browser plugins, etc.
> > OK, I made https://bugzilla.wikimedia.org/show_bug.cgi?id=31853
> >
> > ___
> > 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
>



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

Re: [Wikitech-l] wikipedia lacks a "share' button

2011-10-21 Thread John Du Hart

Why.

Why does an encyclopedia need a share button? I can see the purpose on
Commons, but for an article? I just don't see the justification. What do you
really need to share with your friends from an reference source. What does a
button do that copypaste can't?

There's also the technical problems this would incur. Each of these buttons
require yet another HTTP request each, which would make the hard work by RL
team moot.

It just doesn't make sense.

On Oct 20, 2011 11:54 PM,  wrote:
Gentlemen, where is the Share button?
All other sites have them by now, but on Wikipedia one cannot even find
its definition in http://en.wikipedia.org/wiki/Share .
At least on ones account preferences there should be a way to "activate
sharing with the following websites ... " causing a share button to
appear in the navigation menu.
If there is an extension, then wikipedia should install it and not
depend on browser plugins, etc.
OK, I made https://bugzilla.wikimedia.org/show_bug.cgi?id=31853

___
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] Proposed Authentication Schema for Wikimedia projects

2011-10-18 Thread John Du Hart

Looks like an interesting idea. The MediaWiki extension needs some work
though so I'll fork that and work on it today.

On Mon, Oct 17, 2011 at 10:51 PM,  wrote:

> I originally posted this idea on G+ and Arthur Richards suggested I
> cross-post it here.  My friend, Isaac Potoczny-Jones is a computer security
> professional.  He developed a new authentication schema that layers on top
> of existing technologies and leverages a user's smartphone and QRCodes to
> improve authentication usability, eliminate human-generated passwords, and
> further improve security by separating the authentication channel from the
> login session.   He's calling this capability "Animate Login" and as part of
> the proof of concept, he developed a MediaWiki implementation.   I believe
> the Wikimedia foundation should pursue adding this technique as part of the
> primary login options for it's projects.  I would personally love to be able
> to just point my phone at the login screen and have the system log me in to
> Wikipedia without having to type anything or remember complex passwords.
>  Wikimedia has worked hard to consolidate logins across the many projects
> over the last couple years and this would be a great way of providing
> seamless login.   It should be very low overhead and relatively easy to
> implement.  Isaac is very interested in seeing his tool put to use on
> Wikipedia.   Wikimedia could lead the way to improved authentication that
> also vastly improves the user experience!
>
> Isaac explains the project in some detail on this Google Plus post:
> https://plus.google.com/u/0/112702172838704084335/posts/B9UR2zzDY3f?hl=en
>
> His landing page for the project is here:
> http://animate-innovations.com/content/animate-login
>
> The website has videos, links to a MediaWiki instance where its in use and
> more.
>
> From the conversations I've had with him, I know that he has thought long
> and hard about this application and has sought to address/understand all of
> the potential attack vectors.  Compared to human-generated passwords, this
> would be vastly more secure and dramatically improve the user experience of
> logging in.  It might even entice new or old editors to login and give it a
> try and thus re-engage them in editing.  I'm also certain it could generate
> a fair bit of buzz as people learn they can use their smartphone to login to
> Wikipedia.
>
> I hope you'll consider working with Isaac.  I'll point him to this thread
> so he knows it is here.   I know he'd love to see this implemented in
> Wikipedia.
>
> Don
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



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

Re: [Wikitech-l] Giving up on LiquidThreads

2011-10-11 Thread John Du Hart

Wow. I'm in a state of complete shock for the lack of care here, #1 for the
fact that you (or apparently the whole swedish Wikipedia community which I
find very hard to believe) can't put in the 5 minutes needed entering a bug
report for something that may effect many others, and (#2) you instead go
the route of discussion to end up at a resolution to abandon the system in
whole.

> LiquidThreads has again crashed after the upgrade to MediaWiki 1.18.

Something will always break. There are no guarantees that stuff will always
work, expect it to be wonky right after deployment (it *IS* pre-release
software)

> We don't see how LiquidThreads could ever become a reliable system

It's in the midst being rewritten
http://www.mediawiki.org/wiki/LiquidThreads_3.0

Honestly I'm completely blown away by the fact that the remote thought of
letting this go unreported for over a *WEEK* without being reported to the
technical staff was at any point an acceptable decision, and your response
one week later being "nah we're just not going to use this anymore".
Honestly, how do you all decide not to report an issue as bad sounding
as "crashed"
(I'm assuming a DB error of some sort). I'm pretty sure if you reported this
when it happened it would most likely be resolved by now.

Above all, you have the right to decide that you don't want LQT, but to do
so saying that there's some bug and refusing to report it because "have no
interest in this bug getting fixed" is absolutely infuriating to me and
probably other developers.

(Note: I speak for myself and my own opinions)

On Tue, Oct 11, 2011 at 7:38 PM, Lars Aronsson  wrote:

> On 10/12/2011 01:18 AM, K. Peachey wrote:
> > On Wed, Oct 12, 2011 at 9:13 AM, Lars Aronsson  wrote:
> >> The Swedish Wikisource community has decided not to file any
> >> bug report for the fact that LiquidThreads has again crashed
> >> after the upgrade to MediaWiki 1.18.
> >
> > So you aren't going to file a bug so everyone else has to suffer and
> > possibly find this bug themselves when it could be fixed if someone
> > filed it?
>
> Correct. We have no interest in this bug getting fixed. The matter
> doesn't exist anymore. It is a non-topic. This is the difference
> from last time this happened. Thanks for understanding.
>
>
> --
>   Lars Aronsson (l...@aronsson.se)
>   Aronsson Datateknik - http://aronsson.se
>
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

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

Re: [Wikitech-l] Puppet repository published in a public git repository

2011-09-20 Thread John Du Hart

Wooo, thanks Ryan

On Sep 19, 2011 5:09 PM, "Ryan Lane"  wrote:
> We've just released our puppet repository into a public git
> repository. For more information, see the blog post about this:
>
>
http://blog.wikimedia.org/2011/09/19/ever-wondered-how-the-wikimedia-servers-are-configured/
>
> As noted in the blog post, we are releasing this to treat operations
> like a software development project. Users with Labs access can push
> changes to the repository. We aren't currently ready to start giving
> out Labs access en masse, but will hopefully have a process ready by
> the New Orleans hack-a-thon.
>
> More info to come about Labs later.
>
> - Ryan
>
> ___
> 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] sep11.wikipedia.org

2011-09-11 Thread John Du Hart

http://en.wikipedia.org/wiki/September_11_attacks

2011/9/11 Краснов Кирилл 

> Sorry, what is sep11.wikipedia.org? Is it project Wikipedia Org?
> Why not domain jan01.wikipedia.org, mar08.wikipedia.org, etc?
>
> 2011/9/10 MZMcBride :
> > Benjamin Lees wrote:
> >> On Fri, Sep 9, 2011 at 1:44 PM, Platonides 
> wrote:
> >>> Looks fixed to me (redirects to archive.org)
> >>
> >> sep11.wikipedia.org redirects to archive.org, but
> >> sep11.wikipedia.org/wiki/ still redirects to sep11memories.org.
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



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

Re: [Wikitech-l] Taking suggestions for a template language syntax for our skin system

2011-09-11 Thread John Du Hart

It's over complicated for our needs, and we really don't need another full
featured language to learn and parse. It's like saying everyone should learn
ruby so we can do skins in it.

On Sun, Sep 11, 2011 at 12:05 PM, Russell N. Nelson - rnnelson <
rnnel...@clarkson.edu> wrote:

> Geez, I didn't mean to squash the discussion! TRAC isn't *that* weird a
> language, is it?
> 
> From: wikitech-l-boun...@lists.wikimedia.org [
> wikitech-l-boun...@lists.wikimedia.org] on behalf of Russell N. Nelson -
> rnnelson [rnnel...@clarkson.edu]
> Sent: Thursday, September 08, 2011 2:18 PM
> To: Wikimedia developers
> Subject: Re: [Wikitech-l] Taking suggestions for a template language syntax
> for our skin system
>
> How about http://en.wikipedia.org/wiki/TRAC_%28programming_language%29 ?
>
> It has the benefit that simple things are simple, but you can create
> complicated things because it's a full programming language.
> ___
> 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
>



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

Re: [Wikitech-l] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90092 <-- pls. can someone CR and set a status other than "new"

2011-09-01 Thread John Du Hart

Why is this so urgent that you cannot wait for someone to get around to
doing code review? If you think it should be back ported add a 1.18 tag to
the revision.

On Thu, Sep 1, 2011 at 2:40 PM, Thomas Gries  wrote:

> Re:http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90092
>
> Hi,
>
> can someone pls. set this revision to "resolved" or "ok" ?
>
> My commit r90092 was the basis of several follow-ups, and the latest fix
> by Brion (*),
>
> I then submitted a large suite of testcases
>
> http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/tests/qunit/suites/resources/jquery/jquery.highlightText.test.js?view=log
> for many languages including RTL for Brion's fix (passes all tests, see
> http://localhost/phase3/tests/qunit/ )
>
> Moreover I think, that his patch
> http://svn.wikimedia.org/viewvc/mediawiki?view=revision&revision=94702 (*)
> should also put back-ported into the 1.17wmf or 1.18 branch.
>
> However, I do not know how to request this formally - or informally.
>
> Tom
>
>
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



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

Re: [Wikitech-l] Wikimedia architecture overview in #wikimedia-tech

2011-08-18 Thread John Du Hart

I'll try my best to be there but can we make sure there's a log of this for
everyone afterwards?

Thanks!

On Aug 18, 2011 11:27 AM, "Sumana Harihareswara" 
wrote:
> On Mon, Aug 15, 2011 at 8:45 PM, K. Peachey  wrote:
>> On Tue, Aug 16, 2011 at 10:23 AM, Ryan Lane  wrote:
>>> The Ubuntu Ensemble community is going to be working on replicating
>>> our environment using Ensemble, inside of the Labs infrastructure. To
>>> aid them in this project, I'll be giving them an overview of our
>>> architecture in IRC at #wikimedia-tech on Monday, Aug 22, at 17:00
>>> UTC.
>>>
>>> I'm sure this would also be useful to our own community, so if you are
>>> interested, please attend. Come armed with questions.
>>>
>>> - Ryan
>
> Using http://www.worldtimebuddy.com/ I have divined that 17:00UTC is
> 1pm in New York, 10am in San Francisco, 7pm in Leipzig, and 8pm in
> Haifa. Mark your calendar!
>
>
http://www.worldtimebuddy.com/meeting?lid=5128581,2147714,1850147,0,2879139,294801&h=5128581&sts=21899760&sl=13-13
>
>
> Sumana Harihareswara
> Volunteer Development Coordinator
> 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

[Wikitech-l] mysql_* functions and MediaWiki

2011-07-30 Thread John Du Hart

Earlier this month, the PHP developer team moved to start soft deprecating
the mysql.so extension via documentation, with a intent to fully
E_DEPRECATED in a later release. [1] Therefore, I thought it would be
appropriate to start a small discussion as to how this should be handled.

At the current moment, MediaWiki is still using these functions in its
DatabaseMysql class. Being a new contributor to MW this came across as odd
as to why no MySQLi implementation was available, so I went ahead and
created one [2] (Patch [3]). Right now it's just another $wgDBtype, how it
should really be integrated is what I want to discuss. Should any
implementation (not necessarily mine) using MySQLi just be another DBType in
the installer perhaps? (Most software I've seen goes this route) Also, at
what point (time or event) do we do away with mysql function support? Also,
are there any performance regressions with MySQLi that we should be aware
about?

[1]: 
http://marc.info/?l=php-internals&m=131031747409271&w=
2 
[2]:
https://github.com/johnduhart/mediawiki-trunk-phase3/commit/552a90f5142bb108cb268e1e47da10351b4f873f
[3]: https://gist.github.com/1115789

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

Re: [Wikitech-l] About LQT - on hold?

2011-05-29 Thread John Du Hart

There won't be anything to test until the rewrite is done since it's still
undergoing major changes. There's no point in deploying code and testing for
it if that code will change drastically in a few months.

On Sun, May 29, 2011 at 12:27 PM, Amir E. Aharoni <
amir.ahar...@mail.huji.ac.il> wrote:

> 2011/5/29 MZMcBride :
> > HW wrote:
> >> As of a member of Chinese Wikipedia community, we have submitted a bug
> >> https://bugzilla.wikimedia.org/show_bug.cgi?id=29114 on requestion for
> adding
> >> LQT to Chinese Wikipedia. However, it seems that it is on hold. Due to a
> large
> >> amount of comment on Chinese Wikipedia Village Pump, we need it as soon
> as
> >> possible. When will it be enable? Or, need to wait for central action?
> >
> > http://www.mediawiki.org/wiki/Extension:LiquidThreads/Status
>
> Thank you for the link.
>
> This page says in the end: "Production deployment of LiquidThreads
> with its improved backend to all Wikimedia wikis using LiquidThreads.
> Timeline: Before Wikimania, August 2."
>
> Putting Wikimania as a target date is very nice, because Wikimania and
> the hackathon that preceeds it will happen in a country that speaks
> Hebrew and Arabic - right-to-left languages. If the new LQT will be
> deployed before Wikimania only to wikis that use LQT now, this means
> that until Wikimania, LQT will not be tested by right-to-left language
> users on right-to-left language wikis.
>
> And so this will become a missed opportunity. If a development version
> of LQT will be tested on an RTL wiki before Wikimania, the RTL bugs
> will be already known before the beginning of the hackathon and would
> be easily fixed during it with the help of Israeli developers that
> will be present in Haifa. If it won't be tested before Wikimania,
> fixing these RTL bugs will be much, much harder.
>
> And so i repeat my request: Please install LQT on the Hebrew Wikinews
> and on other wikis whose users offer their help in testing.
>
> --
> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
> http://aharoni.wordpress.com
> "We're living in pieces,
>  I want to live in peace." - T. Moore
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



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

Re: [Wikitech-l] GitHub Mirror of the svn repository

2011-03-16 Thread John Du Hart

On Wed, Mar 16, 2011 at 5:48 PM, Brion Vibber  wrote:

> On Wed, Mar 16, 2011 at 2:42 PM, Brion Vibber  wrote:
>
> > On Wed, Mar 16, 2011 at 2:35 PM, Chad  wrote:
> >
> >> > Could the owners of the github and gitorious mirrors update the
> project
> >> > descriptions to indicate that they're inactive?
> >>
> >> I thought I had access to do this, but apparently not. CC'ing Ævar :)
> >> I'm not sure who runs the gitorious mirror.
> >>
> >
> > Appears to belong to some mysterious 'svnmirror' user who's mirrored a
> > number of projects... and not updated anything since last summer. :(
> >
> > http://gitorious.org/~svnmirror
> >
>
> (I sent a message to that user on Gitorious asking to either add us as
> admins for the Gitorious 'mediawiki' project or rename it away so we can
> add
> our own in that spot that can have a copy of our official mirror.)
>
> -- brion
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

Imho "svnmirror" sounds like a official account for mirroring svns,
run by Gitorious.
You should poke the people at Gitorious too, no one is going to log into
that account anytime soon.

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

72 matches

Mail list logo