headers
Sergey Chernyshev | 1 Aug 02:00
Picon
Gravatar

Re: Extensions in Bugzilla

Actually Maps was just developed by Jeroen De Dauw under supervision of
Yaron Koren as part of Google Summer of Code - they might be interested in
maintaining it as well, just didn't get around to applying for it, maybe.

        Sergey

--
Sergey Chernyshev
http://www.sergeychernyshev.com/

On Fri, Jul 31, 2009 at 5:58 PM, Chad <innocentkiller <at> gmail.com> wrote:

> On Fri, Jul 31, 2009 at 4:52 PM, Aude<aude.wiki <at> gmail.com> wrote:
> > On Fri, Jul 31, 2009 at 2:01 PM, Chad <innocentkiller <at> gmail.com> wrote:
> >
> >> Hey all,
> >>
> >> I've compiled a list[1] of extensions in Bugzilla that don't have a
> default
> >> assignee. If you want to be (or should already be) the assignee for any
> >> of these, please let me know. Would like to really cut that list down
> >> so bugs are getting triaged to someone who cares. Right now, they're
> >> all being assigned to wikibugs-l, and we know how many bugs he
> >> resolves :p
> >>
> >> -Chad
> >>
> >> [1] http://www.mediawiki.org/wiki/User:^demon/Unloved_extensions
> >>
> >
(Continue reading)

Permalink | Reply | 2 comments |
headers
Chad | 1 Aug 02:02
Picon

Re: Extensions in Bugzilla

On Fri, Jul 31, 2009 at 8:00 PM, Sergey
Chernyshev<sergey.chernyshev <at> gmail.com> wrote:
> Actually Maps was just developed by Jeroen De Dauw under supervision of
> Yaron Koren as part of Google Summer of Code - they might be interested in
> maintaining it as well, just didn't get around to applying for it, maybe.
>
>        Sergey
>
>
> --
> Sergey Chernyshev
> http://www.sergeychernyshev.com/
>
>
> On Fri, Jul 31, 2009 at 5:58 PM, Chad <innocentkiller <at> gmail.com> wrote:
>
>> On Fri, Jul 31, 2009 at 4:52 PM, Aude<aude.wiki <at> gmail.com> wrote:
>> > On Fri, Jul 31, 2009 at 2:01 PM, Chad <innocentkiller <at> gmail.com> wrote:
>> >
>> >> Hey all,
>> >>
>> >> I've compiled a list[1] of extensions in Bugzilla that don't have a
>> default
>> >> assignee. If you want to be (or should already be) the assignee for any
>> >> of these, please let me know. Would like to really cut that list down
>> >> so bugs are getting triaged to someone who cares. Right now, they're
>> >> all being assigned to wikibugs-l, and we know how many bugs he
>> >> resolves :p
>> >>
>> >> -Chad
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Dunbar | 1 Aug 03:15
Picon
Gravatar

Re: Extensions in Bugzilla

2009/7/31 Chad <innocentkiller <at> gmail.com>:
> Hey all,
>
> I've compiled a list[1] of extensions in Bugzilla that don't have a default
> assignee. If you want to be (or should already be) the assignee for any
> of these, please let me know. Would like to really cut that list down
> so bugs are getting triaged to someone who cares. Right now, they're
> all being assigned to wikibugs-l, and we know how many bugs he
> resolves :p
>
> -Chad
>
> [1] http://www.mediawiki.org/wiki/User:^demon/Unloved_extensions
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l <at> lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

DidYouMean is mine

Andrew Dunbar (hippietrail)

--

-- 
http://wiktionarydev.leuksman.com http://linguaphile.sf.net
Permalink | Reply | 1 comment |
headers
Chad | 1 Aug 03:20
Picon

Re: Extensions in Bugzilla

On Fri, Jul 31, 2009 at 9:15 PM, Andrew Dunbar<hippytrail <at> gmail.com> wrote:
> 2009/7/31 Chad <innocentkiller <at> gmail.com>:
>> Hey all,
>>
>> I've compiled a list[1] of extensions in Bugzilla that don't have a default
>> assignee. If you want to be (or should already be) the assignee for any
>> of these, please let me know. Would like to really cut that list down
>> so bugs are getting triaged to someone who cares. Right now, they're
>> all being assigned to wikibugs-l, and we know how many bugs he
>> resolves :p
>>
>> -Chad
>>
>> [1] http://www.mediawiki.org/wiki/User:^demon/Unloved_extensions
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l <at> lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>
> DidYouMean is mine
>
> Andrew Dunbar (hippietrail)
>
>
> --
> http://wiktionarydev.leuksman.com http://linguaphile.sf.net
>
> _______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Dale | 1 Aug 03:51
Picon

Wiki <at> Home Extension

Want to point out the working prototype of the Wiki <at> home extension. 
Presently it focuses on a system for transcoding uploaded media to free 
formats, but will also be used for "flattening sequences" and maybe 
other things in the future ;)

Its still rough around the edges ... it presently features:
* Support for uploading a non-free media assets,

* putting those non free media assets into a jobs table and distributing 
the transcode job into $wgChunkDuration length encoding jobs. ( each 
pieces is uploaded then reassembled on the server. that way big 
transcoding jobs can be distributed to as many clients that are 
participating )

* It supports multiple derivatives for different resolutions based on 
the requested size.
** In the future I will add a hook for oggHanlder to use that as well .. 
since a big usability issue right now is users embedding HD or high res 
ogg videos into a small video space in an article ... and it naturally 
it performs slowly.

* It also features a JavaScript interface for clients to query for new 
jobs, get the job, download the asset, do transcode & upload it (all 
through an api module so people could build a client as a shell script 
if they wanted)
** In the future the interface will support preferences , basic 
statistics and more options like "turn on wiki <at> home every-time I visit 
wikipedia" or only get jobs while I am away from my computer.

* I try and handle derivatives consistently with the "file"/ media
(Continue reading)

Permalink | Reply | 43 comments |
headers
Gregory Maxwell | 1 Aug 04:33
Picon

Re: Wiki <at> Home Extension

On Fri, Jul 31, 2009 at 9:51 PM, Michael Dale<mdale <at> wikimedia.org> wrote:
> the transcode job into $wgChunkDuration length encoding jobs. ( each
> pieces is uploaded then reassembled on the server. that way big
> transcoding jobs can be distributed to as many clients that are
> participating )

This pretty much breaks the 'instant' gratification you currently get on upload.

The segmenting is going to significant harm compression efficiency for
any inter-frame coded output format unless you perform a two pass
encode with the first past on the server to do keyframe location
detection.  Because the stream will restart at cut points.

> * I tie transcoded chunks to user ids this makes it easier to disable
> bad participants.

Tyler Durden will be sad.

But this means that only logged in users will participate, no?
Permalink | Reply | 34 comments |
headers
Sergey Chernyshev | 1 Aug 04:44
Picon
Gravatar

Re: Extensions in Bugzilla

I didn't mean that you should kick those guys out ;)
Just tried to explain why it probably doesn't have a person assigned yet.

        Sergey

On Fri, Jul 31, 2009 at 8:02 PM, Chad <innocentkiller <at> gmail.com> wrote:

> On Fri, Jul 31, 2009 at 8:00 PM, Sergey
> Chernyshev<sergey.chernyshev <at> gmail.com> wrote:
> > Actually Maps was just developed by Jeroen De Dauw under supervision of
> > Yaron Koren as part of Google Summer of Code - they might be interested
> in
> > maintaining it as well, just didn't get around to applying for it, maybe.
> >
> >        Sergey
> >
> >
> > --
> > Sergey Chernyshev
> > http://www.sergeychernyshev.com/
> >
> >
> > On Fri, Jul 31, 2009 at 5:58 PM, Chad <innocentkiller <at> gmail.com> wrote:
> >
> >> On Fri, Jul 31, 2009 at 4:52 PM, Aude<aude.wiki <at> gmail.com> wrote:
> >> > On Fri, Jul 31, 2009 at 2:01 PM, Chad <innocentkiller <at> gmail.com>
> wrote:
> >> >
> >> >> Hey all,
> >> >>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Dale | 1 Aug 06:13
Picon

Re: Wiki <at> Home Extension

Gregory Maxwell wrote:
> On Fri, Jul 31, 2009 at 9:51 PM, Michael Dale<mdale <at> wikimedia.org> wrote:
>   
>> the transcode job into $wgChunkDuration length encoding jobs. ( each
>> pieces is uploaded then reassembled on the server. that way big
>> transcoding jobs can be distributed to as many clients that are
>> participating )
>>     
>
> This pretty much breaks the 'instant' gratification you currently get on upload.
>   

true... people will never upload to site without instant gratification ( 
cough youtube cough ) ...

At any rate its not replacing the firefogg  that has instant 
gratification at point of upload its ~just another option~...

Also I should add that this wiki <at> home system just gives us distributed 
transcoding as a bonus side effect ... its real purpose will be to 
distribute the flattening of edited sequences. So that 1) IE users can 
view them 2) We can use effects that for the time being are too 
computationally expensive to render out in real-time in javascript 3) 
you can download and play the sequences with normal video players and 4) 
we can transclude sequences and use templates with changes propagating 
to flattened versions rendered on the wiki <at> home distributed computer

While presently many machines in the wikimedia internal server cluster 
grind away at parsing and rendering html from wiki-text the situation is 
many orders of magnitude more costly with using transclution and temples
(Continue reading)

Permalink | Reply | 33 comments |
headers
Gregory Maxwell | 1 Aug 08:47
Picon

Re: Wiki <at> Home Extension

On Sat, Aug 1, 2009 at 12:13 AM, Michael Dale<mdale <at> wikimedia.org> wrote:
> true... people will never upload to site without instant gratification (
> cough youtube cough ) ...

Hm? I just tried uploading to youtube and there was a video up right
away. Other sizes followed within a minute or two.

> At any rate its not replacing the firefogg  that has instant
> gratification at point of upload its ~just another option~...

As another option— Okay. But video support on the site stinks because
of lack of server side 'thumbnailing' for video.  People upload
multi-megabit videos, which is a good thing for editing, but then they
don't play well for most users.

Just doing it locally is hard— we've had failed SOC projects for this—
doing it distributed has all the local complexity and then some.

> Also I should add that this wiki <at> home system just gives us distributed
> transcoding as a bonus side effect ... its real purpose will be to
> distribute the flattening of edited sequences. So that 1) IE users can
> view them 2) We can use effects that for the time being are too
> computationally expensive to render out in real-time in javascript 3)
> you can download and play the sequences with normal video players and 4)
> we can transclude sequences and use templates with changes propagating
> to flattened versions rendered on the wiki <at> home distributed computer

I'm confused as to why this isn't being done locally at Wikimedia.
Creating some whole distributed thing seems to be trading off
something inexpensive (machine cycles) for something there is less
(Continue reading)

Permalink | Reply | 32 comments |
headers
Brian | 1 Aug 08:54
Picon
Favicon

Re: Wiki <at> Home Extension

On Sat, Aug 1, 2009 at 12:47 AM, Gregory Maxwell <gmaxwell <at> gmail.com> wrote:

> On Sat, Aug 1, 2009 at 12:13 AM, Michael Dale<mdale <at> wikimedia.org> wrote:
>
>
> Once you factor in the ratio of video to non-video content for the
> for-seeable future this comes off looking like a time wasting
> boondoggle.
>

I think you vastly underestimate the amount of video that will be uploaded.
Michael is right in thinking big and thinking distributed. CPU cycles are
not *that* cheap. There is a lot of free video out there and as soon as we
have a stable system in place wikimedians are going to have a heyday
uploading it to Commons.
Permalink | Reply | 31 comments |

Gmane