So that I can respond to commit access requests in a more prompt and
standardised manner, I've set up an OTRS queue:
commit-access-requests(a)wikimedia.org. I will get an email notification
when new tickets are opened in it. It has the same permissions as the
noc queue, but I imagine I'll be the only one looking at it for a while.
Moving to OTRS will make dialog with requesters easier and more reliable.
I will shortly migrate the outstanding requests to the queue, and
update the mediawiki.org page to indicate that new requests should be
sent to it.
I have modified the approval response template to encourage new users
to create a user page on mediawiki.org. This means that there will
still be a chance for new users to interact with mediawiki.org
regulars and to talk about their projects.
-- Tim Starling
Gabriel Wicke (gwicke): yes, *the* Gabriel Wicke, the man who wrote
the MonoBook skin and introduced us to Squid. We are in his debt and
he can work on whatever he wants.
Nathanael Thompson (than4213): has some grand plans for rewriting the
parser. We will see how it turns out in a branch.
Gurch: API
HappyDog: CodeReview extension, various other extensions currently
hosted offsite.
-- Tim Starling
Hi all,
I just got this email from bugzilla. Apparently Google Apps has screwed up
something again so the message itself doesnt annoy me, but why are the
users' passwords still sent in CLEARTEXT in these days??
Can someone (tm) of the mailman admins or tech guys please fix this up?
Thanks,
Marco
On Wed, Feb 10, 2010 at 2:47 PM, <wikitech-l-request(a)lists.wikimedia.org>wrote:
> Your membership in the mailing list Wikitech-l has been disabled due
> to excessive bounces The last bounce received from you was dated
> 10-Feb-2010. You will not get any more messages from this list until
> you re-enable your membership. You will receive 3 more reminders like
> this before your membership in the list is deleted.
>
> To re-enable your membership, you can simply respond to this message
> (leaving the Subject: line intact), or visit the confirmation page at
>
>
> https://lists.wikimedia.org/mailman/confirm/wikitech-l/dfe03c58a0a1fe2.....<https://lists.wikimedia.org/mailman/confirm/wikitech-l/dfe03c58a0a1fe2700f7…>
>
>
> You can also visit your membership page at
>
>
> https://lists.wikimedia.org/mailman/options/wikitech-l/marco%40harddisk.is-…
>
>
> On your membership page, you can change various delivery options such
> as your email address and whether you get digests or not. As a
> reminder, your membership password is
>
> <blanked>
>
> If you have any questions or problems, you can contact the list owner
> at
>
> wikitech-l-owner(a)lists.wikimedia.org
>
Hi all,
MediaWiki's skin system has been quite a mess for some while. I decided to
try rewriting it and you can see the end result on [1]. It's quite a big
patch, which is why I want to encourage all developers to test it and report
(or maybe even fix? :) any and all issues they stumble across. There is also
an example extension on [1] which I've been wanting to do for a long time
but which hasn't been possible with the old skin system. To be exact, it was
partially possible, as I noted on the MediaWiki.org page, but the
implementation was too buggy to be put live on any site IMHO.
What does this patch change exactly? When writing a new skin, you no longer
need to override SkinTemplate and write a class that utilises QuickTemplate,
you can just extend Skin class directly. Old SkinTemplate-based skins will
however continue functioning. I wrote a couple things about writing a new
skin with this new system on MediaWiki.org[2], feel free to check it out.
There are some changes which may cause problems, though. For example,
SkinTemplateToolboxEnd and MonoBookTemplateToolboxEnd hooks both take two
arguments instead of one and the hooks are in Skin.php instead of
SkinTemplate.php. I was also thinking that this could be a great opportunity
to add some new hooks to Skin.php, besides the SkinAfterSidebar hook. See
[3] for my thoughts about what could be improved.
I haven't ported Vector skin to use this new system because it's currently
under development. Because this change is quite a big one, I thought that
I'll commit it to SVN once MediaWiki 1.16 has been released so that it'll
make into the 1.17 release.
What are your thoughts and suggestions for this new skinning system?
[1] http://www.mediawiki.org/wiki/User:Jack_Phoenix/SkinSystemRewrite
[2]
http://www.mediawiki.org/wiki/User:Jack_Phoenix/SkinSystemRewrite/Documenta…
[3]
http://www.mediawiki.org/wiki/User:Jack_Phoenix/SkinSystemRewrite/Notes_and…
Thanks and regards,
--
Jack Phoenix
MediaWiki developer
On Wed, Feb 10, 2010 at 12:51 AM, <tstarling(a)svn.wikimedia.org> wrote:
> http://www.mediawiki.org/wiki/Special:Code/MediaWiki/62223
>
> Revision: 62223
> Author: tstarling
> Date: 2010-02-10 05:51:56 +0000 (Wed, 10 Feb 2010)
>
> Log Message:
> -----------
> * In preparation for deployment, revert the bulk of Michael's unreviewed work. Time for review has run out. The code has many obvious problems with it. Comparing against r38714 will give you an idea of which changes I am accepting. Fixes bug 22388.
> * Removed magic word hook, doesn't do anything useful.
> * OggPlayer.js still needs some work.
Looks like this change removed both the Oggthumb support as well as
the code that handles the cases where ffmpeg fails.
Ffmpeg will fail to generate a thumb if there is no keyframe in the
file after the point in time that you requested a thumb. This was
causing a failure to generate thumbs for many files because they are
short and only have a single keyframe at the beginning.
Seems like it is no easy way to display all the media files under a
wikimedia category -- for example if someone wants a picture of a
library, he or she will need to go into each sub-category under
"Libraries":
http://commons.wikimedia.org/wiki/Category:Libraries
While Wikimedia is not yet the most popular stock photo source, IMO
having this flattening functionality would be useful to those who are
looking for stock photos.
Rayson
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
While trying to get externallinks.sql.gz for enwiki, I found that the
file was empty. Looking at the hashes, I guess several of these metadata
dumps have failed (but marked as successful, of course):
http://download.wikimedia.org/enwiki/20100130/enwiki-20100130-md5sums.txt
e32d799e86f8d2be5ebb3eed048238c7 is the md5 for these 20-byte files.
Older stuff seems ok (enwiki-20100116-externallinks.sql.gz) - as does
data for other wikis (enwikibooks-20100206-externallinks.sql.gz).
- -Mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAktwMl8ACgkQst0AR/DaKHtZswCghbS4I+mKb1lDRvBbKREC+dww
NtoAn30rKLPMpQ0ZAl0JTkifeG8RE9YC
=HFYk
-----END PGP SIGNATURE-----
REMOVE ME FROM THIS MAILING LIST!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
-----Original Message-----
From: "Eric Sun" [esun(a)cs.stanford.edu]
Date: 02/08/2010 12:45 AM
To: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org>
Subject: Re: [Wikitech-l] importing enwiki into local database
Note: Original message sent as attachment
------------------------------------------------------------
Want to lose weight? Click here for diet help and solutions.
Diet Help
http://tagline.excite.com/c?cp=5y0A9LWBX7JPs3K8x4nd1wAAKZTVS3uidXGi8As47ZJz…
REMOVE ME FOR MTHIS MAILING LIST!!!!!!!!!!!!!!!!!!!!!
-----Original Message-----
From: "Eric Sun" [esun(a)cs.stanford.edu]
Date: 02/08/2010 12:45 AM
To: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org>
Subject: Re: [Wikitech-l] importing enwiki into local database
Note: Original message sent as attachment
------------------------------------------------------------
Click here to find experienced pros to help with your home improvement project.
Home Improvement Projects
http://tagline.excite.com/c?cp=Vi6LBh3bdR9Wm_9yHAGY8gAAKZTVS3uidXGi8As47ZJz…