Hi
I am interested in the Captcha extension project in GSOC'11. But I am
unable to find a mentor ( potential mentor ) who can help me out in my
problem related to captchas.
Please provide me with contact details of someone who will be
potentially mentoring this project.
Thank you.
I happened to be in my Windows 7 boot fixing a site in IE, so I decided
to try out "Git Extensions", that Git gui to see how well Git support is
in Windows.
Installation was nice, the Git Extensions installer also came with
mysgit and kdiff(?), which it would optionally install, since they're
important I let it install them.
The mysgit installation process was nice. It nicely asked for a
preference while installing on how to treat CRLFs, and explained each
option.
Installation had three options for shell, the third one had a warning,
something about replacing stuff... The second option seamed to be a
setup which was meant to play nice with users that like to use cygwin. I
chose the first option, bash.
mysgit seams to bundle a bash shell with it, it's easily accessible from
Git Extensions gui. The only downside is it doesn't seam to support
paste that I could find, however since you're not going to be using it
to do any cloning or anything that doesn't seam important. That aside,
the bash shell included has all the nice unixy goodies like ls, and
probably completion. And it does it without any of the cygwin messyness.
Git Extensions has a bundled plugin with support for GitHub, it sorta
works, sorta doesn't... Honestly, you don't really need it, just open up
your web browser, click the button to copy a repo url, and paste. You
don't need to use the Gui to make a pull request either.
I had a little awkwardness trying to get keys working, though most of
this was awkwardness with PuTTY, if you already have PuTTY setup you
shouldn't have as many issues. Just make sure to find the "Test
Connection" option in the "Manage Remotes" section of Git Extensions.
That was the only way I could find to get it to remember github's
identity key to stop that from causing errors when trying to do things.
It seamed to work a little better to clone a public repo using a
publicly accessible clone url, and then afterwards use the Manage
Remotes to tweak it to use a repo url you have push access to. Perhaps
there are less issues after you've cloned your first repo (that remote
identity key thing and all).
Git Extensions includes a manual with it, one about Git Extensions
itself. But I didn't look at the other options, I believe it has some
built in info on git as well.
Git Extensions also includes git's own git gui if you ever feel like
using it.
The built in git gui aside, Git Extensions includes just about every
option I could think of. Managing remotes, submodules, pushing and
pulling, commit, a good log view right in front of you, diff viewing,
bisect (what did that do again), all the merge options in pull right in
front of you, .......and on and on and on. It actually looks better and
has more than any of the screenshots I saw of it, perhaps I should make
my own overview and capture it a bit.
All in all... I think the support in Windows for git, especially if you
use Git Extensions, is good. Doesn't look like it's a good reason to
disqualify git anymore.
Also, since the bash shell is there, I think we can legitimately use
some custom scripts to help with dealing with piles of repos at once.
I'd probably pick python, ;) though theoretically you could write bash
scripts and use them on Windows with the Git Extensions setup.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Well, that used up all my good luck for the year, but the bz2s are ready
for download. The md5sums are still calculating, give them a couple
hours to show up. If all continues to go well we'll have the 7z files
in 4-5 days.
As before I do not plan to provide a single 350gb file of the bz2, nor a
single 7z file for download.
Happy trails,
Ariel
>
> I know my way to Commons which is substantiated by my contribution, and
> when I have smth to upload, I eventually upload and even sometimes write
> an
> article to include the picture, but I would not call it a systemic work.
> For me, an example of systemic activity would be the message on a
> designated page that the community YYY or a mosque ZZZ or a mountain WWW
> do
> not have any illustrations available on Commons, meeting a user who is
> going to travel to XXX or ZZZ or WWW but can not really look through all
> the Commons categories (when they exist anyway). At best this activity
> should be automated (even though I do not know how it can look like).
>
> Cheers
> Yaroslav
>
So coded, images needed, like a red link.
Fred
I've given extensions, core, and deployment access to a new member of
our ops team: Peter Youngmeister. He should be adding his userinfo as
we speak.
- Ryan Lane
----- Original Message -----
From: Brian J Mingus <brian.mingus(a)Colorado.EDU>
Date: Tuesday, March 29, 2011 7:15 pm
Subject: Re: [Wikitech-l] [Xmldatadumps-l] March 17 en wikipedia history bz2 files ready
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Cc: Jamie Morken <jmorken(a)shaw.ca>, "Ariel T. Glenn" <ariel(a)wikimedia.org>, xmldatadumps-l(a)lists.wikimedia.org
> >
> According to this data the 7z dump for enwp will reach 1
> terabyte on Jan 2,
> 2145.
>
> =)
Hi,
I made a graph for the uncompressed XML file size for the enwiki pages-meta-history files over time, I thought that these files would be growing exponentially but they appear to grow linear. For comparison in 2145 the raw XML should be about 178 TB I think, so the 7z files are growing linearly about 180x faster than the raw XML.
"http://nekrom.com/wikipedia/enwiki%20history%20uncompressed%20XML%20dump%20…"
(data below)
cheers,
Jamie
enwiki-20060816-pages-meta-history.xml 782741875000 (728.99 GB)
enwiki-20070402-pages-meta-history.xml 1763048493749 (1641.97 GB) (229 days since previous dump)
enwiki-20080103-pages-meta-history.xml 2807444044080 (2614.64 GB) (276 days since previous dump)
enwiki-20100130-pages-meta-history.xml 5873134833455 (5469.78 GB) (758 days since previous dump)
enwiki-20110115-pages-meta-history[1-15].xml 7218617857754 (6722.86 GB) (350 days since previous dump)
enwiki-20110115-pages-meta-history1.xml 1 080 719 385 129
enwiki-20110115-pages-meta-history2.xml 677 956 948 289
enwiki-20110115-pages-meta-history3.xml 550 889 319 423
enwiki-20110115-pages-meta-history4.xml 447 001 611 247
enwiki-20110115-pages-meta-history5.xml 453 700 983 270
enwiki-20110115-pages-meta-history6.xml 540 208 590 115
enwiki-20110115-pages-meta-history7.xml 458 817 000 243
enwiki-20110115-pages-meta-history8.xml 649 710 293 818
enwiki-20110115-pages-meta-history9.xml 471 183 250 318
enwiki-20110115-pages-meta-history10.xml 406 115 459 739
enwiki-20110115-pages-meta-history11.xml 342 840 308 580
enwiki-20110115-pages-meta-history12.xml 310 507 626 798
enwiki-20110115-pages-meta-history13.xml 362 264 384 002
enwiki-20110115-pages-meta-history14.xml 269 988 897 698
enwiki-20110115-pages-meta-history15.xml 196 713 799 085
>
> --
> Brian Mingus
> Graduate student
> Computational Cognitive Neuroscience Lab
> University of Colorado at Boulder
>
----- Original Message -----
From: Brian J Mingus <brian.mingus(a)Colorado.EDU>
Date: Tuesday, March 29, 2011 7:15 pm
Subject: Re: [Wikitech-l] [Xmldatadumps-l] March 17 en wikipedia history bz2 files ready
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Cc: Jamie Morken <jmorken(a)shaw.ca>, "Ariel T. Glenn" <ariel(a)wikimedia.org>, xmldatadumps-l(a)lists.wikimedia.org
> >
> According to this data the 7z dump for enwp will reach 1
> terabyte on Jan 2,
> 2145.
>
> =)
wanna bet? :)
cheers,
Jamie
>
> --
> Brian Mingus
> Graduate student
> Computational Cognitive Neuroscience Lab
> University of Colorado at Boulder
>
Dear Platonides,
I'm not sure if that is a good practice. How would identifying the
version (id) revised?
2011/3/28 Platonides <Platonides(a)gmail.com>:
> Wilfredo Rodriguez wrote:
>> Good morning.
>>
>> If many people work in the process of verification and selection of
>> items, what is the proper way to record the list csv without the
>> following problems occur:
>>
>> 1) Repeat entries (Someone reviewed the same article because he did
>> not know that was already in the list)
>> 2) Create a shared list and easy to edit (We're talking about a list
>> that may be so large that it is impossible to edit)
>>
>> Thank you very much for your help
>>
>> User:Wilfredor
>
> Use a hidden category to track the reviewed articles?
>
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
--
Wilfredo Rafael Rodríguez Hernández
--------------------------------------------------------
msn,googletalk = wilfredor(a)gmail.com
cv = http://www.wilfredor.co.cc
blog = http://wilfredor.blogspot.com
fotos = http://picasaweb.google.com/wilfredor/
Last week I promised you I would return to beating the 1.17 tarball
drum. So let the beating begin.
The first batch of bugs is focused on the new installer. Chad, Raimond,
Max, and others have all been working on getting this in shape, but a
few bugs still remain. We really need to get these cleared out before
we release a tarball since this will be the first thing most people see.
[Installer] Javascript-opened sections not open on back or error
http://bugzilla.wikimedia.org/26937
[Installer] Install does not complete when choosing a CC license
http://bugzilla.wikimedia.org/27170
[Installer] $*Key values sometimes not filled
http://bugzilla.wikimedia.org/26481
[Installer] Chrome saves config as LocalSettings.php.php
http://bugzilla.wikimedia.org/27579
[Installer] Cannot abort or postpone slow operations during upgrades via
web interface
http://bugzilla.wikimedia.org/27929
Installer doesn't create extension tables
http://bugzilla.wikimedia.org/28237
Installer does not respect initial DBport declaration
http://bugzilla.wikimedia.org/28162
Labels for DB types on page=DBConnect are too narrow
http://bugzilla.wikimedia.org/28158
While most people do stick with MySQL, a fair number of rebels install
the other major Open Source database: PostgreSQL. We focus our own
development on MySQL, but not having support for PostgreSQL would be
pretty embarrassing. As a result, these bugs are fairly important. Greg
has likely fixed the first one, Chad has started looking at the second
one, but the third is wide open.
Postgres install fails with no schema
http://bugzilla.wikimedia.org/28171
Error on Postgres install - wfGetDB called when it shouldn't
http://bugzilla.wikimedia.org/28172
Postgres defaults to a unix socket - mention in install?
http://bugzilla.wikimedia.org/28173
If layout and javascript are more your thing, we have a couple of those
left, too:
width of <gallery> always 100%
http://bugzilla.wikimedia.org/27540
New wikilink window grows in width each time when opened in IE and
Chrome
http://bugzilla.wikimedia.org/27566
Finally, a bonus 1.17 blocker. Tim has suggested two separate ways to
solve the problem. Should we go with the “simple” fix or the ”complex”
fix? Truth be told, at this point, we can probably only afford the
simple one.
Apostrophe in linktrail breaks bolded links
http://bugzilla.wikimedia.org/27473
Happy Hacking!
Mark.
