Ryan Lane | 1 Sep 2012 01:00
Picon

Reviews needed for enabling self-registration on labsconsole

Today I put some time into fixing the remaining issues needed to
enable self-registration on labsconsole. I need reviews on the
following changes to deploy/enable it:

https://gerrit.wikimedia.org/r/#/q/status:open+topic:selfregistration,n,z

- Ryan
George Herbert | 1 Sep 2012 01:13
Picon
Gravatar

Re: scaled media (thumbs) as *temporary* files, not stored forever

On Fri, Aug 31, 2012 at 10:26 AM, David Gerard <dgerard <at> gmail.com> wrote:
> On 31 August 2012 18:21, Jon Robson <jdlrobson <at> gmail.com> wrote:
>
>> +1 I was very surprised to learn any thumbnail sizes could be generated. We
>> should standardise on a tiny, small,medium high and original resolutions. 5
>> sizes seems more than enough.
>
>
> I would suggest checking against the corpus before saying "x should be
> enough for anyone". There are also occasional but valid uses for
> non-standard sizes.
>
>
> - d.

True, but if we were to institute a cleanup program to rationalize
sizes to a limited set, even if particular users object on a page here
or there and we leave it be, the vast bulk of the work is easy and
gets us the size usage win.

The questions to me are what sizes to standardize towards, and how can
we tell where things are used at what size?

--

-- 
-george william herbert
george.herbert <at> gmail.com
Platonides | 1 Sep 2012 01:13
Picon

Re: Work offer inside

On 31/08/12 22:31, Jeff Green wrote:
> On Fri, 31 Aug 2012, Mark A. Hershberger wrote:
> 
>> On 08/31/2012 04:01 PM, Jeff Green wrote:
>>> We are currently stuck at the step of mapping out how we originate mail
>>> for the whitelist. Production and Google Apps mail are easy. But people
>>> say we may have volunteers, board members, etc. who do not use our known
>>> mail routes.
>>
>> I'm not why you couldn't give volunteers, etc. a server to send from and
>> add that IP to your trusted senders for the domain that they use
>> (assuming they're using one of your domains for their email address).
> 
> Andrew suggested giving them Google apps accounts. I think it's a great
> solution--it allows people to use gmail or pretty much any mail client
> they want.

Volunteers don't have  <at> wikimedia.org addresses...

Moreover, I expect Ops to know which wikimedia.org emails are valid, so
they could in theory send a mass mail alerting of an upcomin change,
although I expect anyone with that email would be in internal-l.

Posts going to a mailing list through gmane could be a problem though,
since the mail goes user -> gmane -> mchenry -> distribution.
Bartosz Dziewoński | 1 Sep 2012 01:17
Picon

Re: scaled media (thumbs) as *temporary* files, not stored forever

Please don't. The current syntax is nice, concise, consistent and not
overflowing with special characters. The proposed one is verbose and
"looks technical". But defaulting to thumb seems like a good idea to
me (but we ought to make some usage stats first :) ).

2012/9/1, Brion Vibber <brion <at> pobox.com>:
> On Fri, Aug 31, 2012 at 3:52 PM, Daniel Zahn <dzahn <at> wikimedia.org> wrote:
>
>> Maybe we could have "large","medium","small" etc as aliases for
>> standard/popular sizes to encourage using less of the non-standard
>> ones?
>>
>
> I kinda like this. It would also be nice if simply including an image
> defaulted to some sane size, even without using explicit "|thumb".
>
> In fact, we should think about just redoing how images get included in the
> first place maybe. :P
>
> I'd kind of like to see something like this:
>
> {{#media:Foobar.jpg}} <- default to a nice size, displayed in some
> nice-looking way suitable to the output. Sane framing and positioning
> typical for most usages.
>
> {{#media:Foobar.jpg|caption=Hello this is my caption about [[stuff]].
> Enjoy!}} <- caption should probably be an explicitly named parameter
>
> * Consider having *no size option* at all. :)
> * Definitely don't have "left" "right" or "center" options.
(Continue reading)

Mark Holmquist | 1 Sep 2012 01:17
Picon

Re: Work offer inside

> Andrew suggested giving them Google apps accounts. I think it's a great
> solution--it allows people to use gmail or pretty much any mail client
> they want.

However, it forces them to use the google mail servers, which may be 
less-than-desirable for some of us (me included) for various reasons. 
Better to handle blacklisting, and let people use their own mail servers 
or whatever else they'd like.

--

-- 
Mark Holmquist
Contractor, Wikimedia Foundation
mtraceur <at> member.fsf.org
http://marktraceur.info
Platonides | 1 Sep 2012 01:25
Picon

Re: scaled media (thumbs) as *temporary* files, not stored forever

Ariel wrote:
> But there's plenty of "odd" sizes with lots of thumbs too. For example, 
> over 65K files with width 181px

181px images are tipically made when 180px images are "bad", with the
squid/scaler refusing to deliver the latest version. Adding 1px there
forces a regeneration of the file, solving the issue.
Going up to 65K seems too much, though.

On 31/08/12 22:35, Roan Kattouw wrote:
> On Fri, Aug 31, 2012 at 1:22 PM, Jeremy Baron <jeremy <at> tuxmachine.com> wrote:
>> I believe the status quo is no thumbs (of any size) are generated at
>> upload time. They are all just done on demand.
>>
> That's correct in theory. In practice (for uploads using
> Special:Upload at least) the user is redirected to the file
> description page after a successful upload, which contains a thumb of
> the file of a given size (800px?), which is then immediately generated
> on demand :) . Special:UploadWizard has similar behavior: the success
> page contains 200px(?) thumbs of all the images the user uploaded.
> 
> Roan

Plus another tiny one at the file history section.

I remember seeing a change about rounding the requested image size some
months ago, so the "request any size" may not be true any longer.
Platonides | 1 Sep 2012 01:34
Picon

Re: Should we make parser test executions via phpunit.php behave like running them with parserTests.php ?

On 31/08/12 12:01, Daniel Werner wrote:
> Hi everyone,
> 
> Started poking on parser tests lately and found myself riddled after a
> while.
> It seems like when running parser test files with phpunit.php they follow
> different rules as when running them with parserTests.php.
> 
> If I observed this correctly, phpunit.php collects all articles to be
> created with "!!article", creates them, and then it runs tests. With
> parserTests.php on the other hand everything is executed in the order it is
> defined. In some tests it can be important whether a article already exists
> or not.

That was done for creating the "articles" once, outside of the test
loop. Originally they were also created in place, but inserting all
articles for each test was really slow.

If a test relies on some articles existing, those should be defined
before it. If it's not documented, it should be.
With that rule in place, the difference on creating at the start or on
demand doesn't matter.

(...)
> I would very much appreciate if anyone could explain to me why there are
> both of these files and why we maintain (more or less) a whole bunch of
> redundant code for those tests.
> 
> Cheers,
> Daniel
(Continue reading)

Brion Vibber | 1 Sep 2012 01:38
Picon
Favicon
Gravatar

Re: scaled media (thumbs) as *temporary* files, not stored forever

On Fri, Aug 31, 2012 at 6:17 PM, Bartosz Dziewoński <matma.rex <at> gmail.com>wrote:

> Please don't. The current syntax is nice, concise, consistent and not
> overflowing with special characters. The proposed one is verbose and
> "looks technical".

The current syntax is actually hard to machine-parse, with lots of
language-specific overrides and weird options that combine in non-obvious
ways. Not to mention that it overrides the simple link syntax... I wish
when we'd renamed Image: to File: that we'd left the magic behavior only on
the Image: alias so that links would be rationalized. :(

Keep in mind also that in the glorious unicorn-filled future most people
who aren't doing low-level template work will rarely see the markup.
They'll just push a button to insert an image.

> But defaulting to thumb seems like a good idea to
> me (but we ought to make some usage stats first :) ).
>

Yeah... changing existing behavior gets scary. :)

-- brion
_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
bawolff | 1 Sep 2012 01:39
Picon

Re: Code review statistics and trends

Slightly hijacking this thread but is related.

I tried my hand at creating some gerrit related statistics:
https://toolserver.org/~bawolff/gerrit-stats.htm

Statistics might be the wrong word, its more the first 25 results of a
saved search in reverse order - but also includes the total number of
changesets with no review whatsoever, and some other things. There may
be more things on it in the future.

Last of all it includes a wall of shame, because I missed the old wall.

This is still a rather rough version (As can be noted by lack of css
or anything pretty). It also will update rather sporadically (I don't
feel all that good about putting my private key on the toolserver to
make this into a cron script on that server, so for now it is run by
hand).

Anyhow, feedback appreciated :)

[Also source isn't public at the moment, but if anyone wants it let me
know. It is a fairly hacky php script at the moment]
George Herbert | 1 Sep 2012 01:49
Picon
Gravatar

Re: scaled media (thumbs) as *temporary* files, not stored forever

On Fri, Aug 31, 2012 at 4:38 PM, Brion Vibber <brion <at> pobox.com> wrote:
> Keep in mind also that in the glorious unicorn-filled future most people
> who aren't doing low-level template work will rarely see the markup.
> They'll just push a button to insert an image.

Is that really a rainbow coming out of the Unicorn, Brion?  It seems
like an unlikely place to...... Nevermind.

>> But defaulting to thumb seems like a good idea to
>> me (but we ought to make some usage stats first :) ).
>>
>
> Yeah... changing existing behavior gets scary. :)

Usage stats win.  So - how can we get those?

--

-- 
-george william herbert
george.herbert <at> gmail.com

Gmane