Re: [Wikitech-l] Bug 189

[Sumana Harihareswara]

If you know some combination musician/developers, please feel free to
send them my way! :-)  And I know Mark Hershberger recently committed
the LilyPond extension for MediaWiki[0] into Subversion[1], and it is
getting reviewed there.  That's a good way current MediaWiki
developers can contribute to improving the state of music scholarship
on Wikimedia projects.

Take a look at the music markup discussion on meta.[2]  Basically, the
Wikimedia community needs someone to write a MediaWiki extension that
will let users insert musical notation and have it show up as sheet
music within a Wikipedia page, or improve the existing LilyPond
extension to a deployable state.

For those who don't know, Ting Chen is the chair of the Wikimedia
Board of Trustees.[3]  Thanks for the suggestion, Ting.

[0] http://www.mediawiki.org/wiki/Extension:LilyPond
[1] https://www.mediawiki.org/wiki/Special:Code/MediaWiki/98424
[2] https://meta.wikimedia.org/wiki/Music_markup
[3] https://wikimediafoundation.org/wiki/Board_of_Trustees

Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation



On Sun, Oct 16, 2011 at 3:00 AM, Ting Chen  wrote:
> Hello dear developer community,
>
> today I would like to awake your attention and interest on a very old
> bug with the number 189:
> https://bugzilla.wikimedia.org/show_bug.cgi?id=189, and related to it
> Bug 29630: https://bugzilla.wikimedia.org/show_bug.cgi?id=29630
>
> It is about the possibility of different MediaWiki plug-ins that would
> enable our projects, mostly WikiSource, but also Wikipedia, to input and
> show music notes on an easy way. You can really have impact on our
> projects by addressing this bug and make a lot of Wikisource community
> members happy.
>
> Any takers on this?
>
> Greetings
> Ting

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

Re: [Wikitech-l] Bug 189

[Jeremy Baron]

On Oct 18, 2011 8:51 PM, "Sumana Harihareswara" 
wrote:
[…]
> For those who don't know, Ting Chen is the chair of the Wikimedia
> Board of Trustees.[3]  Thanks for the suggestion, Ting.
>
> [3] https://wikimediafoundation.org/wiki/Board_of_Trustees

FWIW, when first saw Ting's mail I assumed that using an address I'd never
seen before instead of his foundation address was intentional and an
indication that he was not acting in his official capacity.

But maybe I was reading to much into it; he can certainly clarify explicitly
or make any other comments if he likes.

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

Re: [Wikitech-l] Bug 189

[Ting Chen]

On 19.10.2011 03:06, wrote Jeremy Baron:
> FWIW, when first saw Ting's mail I assumed that using an address I'd 
> never seen before instead of his foundation address was intentional 
> and an indication that he was not acting in his official capacity. But 
> maybe I was reading to much into it; he can certainly clarify 
> explicitly or make any other comments if he likes.

That's right. Though I still think that this is a good thing to do :-)

Greetings
Ting

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

Re: [Wikitech-l] Bug 189

[Nikola Smolenski]

On Sun, 2011-10-16 at 12:00 +0200, Ting Chen wrote:
> today I would like to awake your attention and interest on a very old 
> bug with the number 189: 
> https://bugzilla.wikimedia.org/show_bug.cgi?id=189, and related to it 
> Bug 29630: https://bugzilla.wikimedia.org/show_bug.cgi?id=29630
> 
> It is about the possibility of different MediaWiki plug-ins that would 
> enable our projects, mostly WikiSource, but also Wikipedia, to input and 
> show music notes on an easy way. You can really have impact on our 
> projects by addressing this bug and make a lot of Wikisource community 
> members happy.
> 
> Any takers on this?

It is my understanding that there are three road blockers on this one:

1) ABC vs Lilypond, and which exact implementation to use. At this point
I assume everyone is so sick of waiting that no one will care what is
used so long as something is used.

2) IIRC, Brion wanted this to be made around an universal system for
handling automatically-generated images, that would also be useful for
math and future similar extensions. But since this is such an old
request, and such a system is not in sight, perhaps he could look the
other way just one more time :)

3) And the big one, security. It has not been shown that any of the
proposed implementations is secure. I was thinking that perhaps a way to
overcome this would be to have a dedicated system just for handling
music rendering. It would work something like this:

a) A dedicated server used only for music rendering. The server runs
several virtual machines with the music rendering software. It only
accepts the notes and returns the images.

b) When the parent server receives a text with the notes, it only passes
it to a free virtual machine. When it receives the images from the
virtual machine, it passes them back to the client.

c) If it doesn't receive the images within a certain time, it shuts down
the virtual machine, starts a new one and returns an error image to the
client.

Is there a hole in this system that would make it possible to hack the
parent server by means of a malicious file?


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

Re: [Wikitech-l] Bug 189

[Platonides]

Using Virtual Machines is a too big overhead compared to just coding it 
right, and still it would not protect against eg. javascript injection.

Looking into LilyPond exception, I don't see any big problem:
- It relies in Math variables for storing the files in the same folder 
(it was made before Math extension was split).
- $wgMathPath isn't properly escaped, but that's minor.
- Usage of hardcoded text, math_failure, , etc. in error messages.
- It uses escapeshellarg instead of wfEscapeShellArg but the filename is 
safe anyway (and our servers aren't windows).
- Maybe of greater concern is that it assumes to own everything in 
$wgTmpDirectory when those files could have been created:
  a) By another extension
  b) By another instance of LilyPond

I don't know why it needs to trim the images generated by LilyPond, but 
there's probably a reason for that.
Assuming that LilyPond code doesn't allow to open files, or execute 
programs, the current version of LilyPond is apparently safe.

Although I have to admit that it is not pretty, and its "store files 
without tracking" is something that we shouldn't repeat with new extensions.


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

Re: [Wikitech-l] Bug 189

[Roan Kattouw]

On Sun, Oct 23, 2011 at 6:55 PM, Platonides  wrote:
> I don't know why it needs to trim the images generated by LilyPond, but
> there's probably a reason for that.
> Assuming that LilyPond code doesn't allow to open files, or execute
> programs, the current version of LilyPond is apparently safe.
>
>From my memory of reading bug 189 a few years ago, the biggest concern
Tim had at the time was that Lilypond does not (or, at least, at the
time did not; I haven't kept up with LilyPond development news at all)
limit memory or time usage. For certain pathological (or well-crafted,
if you're an attacker) inputs, the process of converting LilyPond
syntax to an image with sheet music may consume a very large amount of
time and/or memory. From my casual re-reading it seems that it's quite
easy to write an infinite loop in LilyPond. LilyPond does have a safe
mode, but it does not protect against infinite loops, nor does it
claim to. Clearly, this presents a resource exhaustion / denial of
service vulnerability given that certain inputs can cause the LilyPond
interpreter to run forever, and any user that can edit or even preview
pages can inject such inputs.

So in order to run LilyPond on WMF servers and be able to feed it
arbitrary user input while protecting against resource exhaustion, we
need to be able to limit the amount of time and memory that each
LilyPond process can use, either in LilyPond itself or in the
MediaWiki extension that spawns LilyPond processes. To my knowledge,
no one has volunteered for this task so far.

Roan

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

Re: [Wikitech-l] Bug 189

[Neil Harris]

On 23/10/11 19:36, Roan Kattouw wrote:
> On Sun, Oct 23, 2011 at 6:55 PM, Platonides  wrote:
>> I don't know why it needs to trim the images generated by LilyPond, but
>> there's probably a reason for that.
>> Assuming that LilyPond code doesn't allow to open files, or execute
>> programs, the current version of LilyPond is apparently safe.
>>
> > From my memory of reading bug 189 a few years ago, the biggest concern
> Tim had at the time was that Lilypond does not (or, at least, at the
> time did not; I haven't kept up with LilyPond development news at all)
> limit memory or time usage. For certain pathological (or well-crafted,
> if you're an attacker) inputs, the process of converting LilyPond
> syntax to an image with sheet music may consume a very large amount of
> time and/or memory. From my casual re-reading it seems that it's quite
> easy to write an infinite loop in LilyPond. LilyPond does have a safe
> mode, but it does not protect against infinite loops, nor does it
> claim to. Clearly, this presents a resource exhaustion / denial of
> service vulnerability given that certain inputs can cause the LilyPond
> interpreter to run forever, and any user that can edit or even preview
> pages can inject such inputs.
>
> So in order to run LilyPond on WMF servers and be able to feed it
> arbitrary user input while protecting against resource exhaustion, we
> need to be able to limit the amount of time and memory that each
> LilyPond process can use, either in LilyPond itself or in the
> MediaWiki extension that spawns LilyPond processes. To my knowledge,
> no one has volunteered for this task so far.
>
> Roan
>

Linux provides the setrlimit() system call for this purpose -- you could 
either call it as a wrapper around lilypond, or hack it into a de-fanged 
version of Lilypond.

If you're going to be running an auxiliary rendering process or 
special-use server anyway, a few moments Googling finds the "softlimit" 
program, provided as part of the daemontools package, which looks like 
it is intended for providing the sort of limited sandboxing required here.

- Neil


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

Re: [Wikitech-l] Bug 189

[Roan Kattouw]

On Sun, Oct 23, 2011 at 9:14 PM, Neil Harris  wrote:
> Linux provides the setrlimit() system call for this purpose -- you could
> either call it as a wrapper around lilypond, or hack it into a de-fanged
> version of Lilypond.
>
> If you're going to be running an auxiliary rendering process or special-use
> server anyway, a few moments Googling finds the "softlimit" program,
> provided as part of the daemontools package, which looks like it is intended
> for providing the sort of limited sandboxing required here.
>
Yes, that sort of thing is what I meant by limiting CPU/mem usage on
the MW extension side. However, someone would have to actually do
that, as well as cleaning up the other coding style issues that I seem
to recall were floating around Extension:LilyPond in its current
state. So far, I don't believe anyone has actually shown themselves
willing to do that work.

Roan

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

Re: [Wikitech-l] Bug 189

[Platonides]

Neil Harris wrote:
> Linux provides the setrlimit() system call for this purpose -- you could
> either call it as a wrapper around lilypond, or hack it into a de-fanged
> version of Lilypond.
>
> If you're going to be running an auxiliary rendering process or
> special-use server anyway, a few moments Googling finds the "softlimit"
> program, provided as part of the daemontools package, which looks like
> it is intended for providing the sort of limited sandboxing required here.
>
> - Neil

We already have several ulimit.sh inside phase3/bin for that.
If LilyPond extension were using wfShellExec instead of exec, it would 
be automatically limited by $wgMaxShellTime, $wgMaxShellMemory and 
$wgMaxShellFileSize (unless on Windows).




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

Re: [Wikitech-l] Bug 189

[Daniel Friesen]

On Sun, 23 Oct 2011 14:42:24 -0700, Platonides 
wrote:

> Neil Harris wrote:
>> Linux provides the setrlimit() system call for this purpose -- you could
>> either call it as a wrapper around lilypond, or hack it into a de-fanged
>> version of Lilypond.
>>
>> If you're going to be running an auxiliary rendering process or
>> special-use server anyway, a few moments Googling finds the "softlimit"
>> program, provided as part of the daemontools package, which looks like
>> it is intended for providing the sort of limited sandboxing required  
>> here.
>>
>> - Neil
>
> We already have several ulimit.sh inside phase3/bin for that.
> If LilyPond extension were using wfShellExec instead of exec, it would
> be automatically limited by $wgMaxShellTime, $wgMaxShellMemory and
> $wgMaxShellFileSize (unless on Windows).
Does that even work? I've regularly had issues with convert commands that
can't get enough mem to finish and are never killed so they sit in the
process list hoarding it.


-- 
~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

Re: [Wikitech-l] Bug 189

[Tim Starling]

On 23/10/11 18:07, Nikola Smolenski wrote:
> It is my understanding that there are three road blockers on this one:
> 
> 1) ABC vs Lilypond, and which exact implementation to use. At this point
> I assume everyone is so sick of waiting that no one will care what is
> used so long as something is used.

Lilypond would provide more flexibility for editors. I originally
thought that ABC would be better for security, but it turns out that
it is full of buffer overflow vulnerabilities, so I'm now recommending
Lilypond without reservations.

[...]
> 3) And the big one, security. It has not been shown that any of the
> proposed implementations is secure. I was thinking that perhaps a way to
> overcome this would be to have a dedicated system just for handling
> music rendering. It would work something like this:
> 
> a) A dedicated server used only for music rendering. The server runs
> several virtual machines with the music rendering software. It only
> accepts the notes and returns the images.
> 
> b) When the parent server receives a text with the notes, it only passes
> it to a free virtual machine. When it receives the images from the
> virtual machine, it passes them back to the client.
> 
> c) If it doesn't receive the images within a certain time, it shuts down
> the virtual machine, starts a new one and returns an error image to the
> client.
> 
> Is there a hole in this system that would make it possible to hack the
> parent server by means of a malicious file?

I think that would be overkill. All we really need is basic resource
limiting (say ulimit.sh plus PoolCounter), and LilyPond should be run
with --jail.

LilyPond has two secure modes: --safe and --jail. Running with --safe
is easy to support but has restricted functionality, which will impact
users. Running with --jail is more complex to set up, but allows
commonly-used macros to be imported.

Ideally music rendering would be split out on to different servers,
using internal api.php requests. This allows cluster-wide LilyPond
resource usage to be limited by limiting the number of servers in the
LilyPond rendering pool. It also simplifies the operations task by
reducing the number of servers that run LilyPond, making both
configuration and monitoring easier.

-- Tim Starling


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

Re: [Wikitech-l] Bug 189

[Magnus Manske]

Or we do without any servers, at the expense of older browsers:
http://0xfe.blogspot.com/2010/05/music-notation-with-html5-canvas.html

Magnus

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

Re: [Wikitech-l] Bug 189

[Nikola Smolenski]

On 24/10/11 09:49, Magnus Manske wrote:
> Or we do without any servers, at the expense of older browsers:
> http://0xfe.blogspot.com/2010/05/music-notation-with-html5-canvas.html

A problem with that is that it is not a notation standard. It can't be 
imported or edited into specialized notation programs, for example.

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

Re: [Wikitech-l] Bug 189

[Magnus Manske]

On Mon, Oct 24, 2011 at 9:22 AM, Nikola Smolenski  wrote:
> On 24/10/11 09:49, Magnus Manske wrote:
>> Or we do without any servers, at the expense of older browsers:
>> http://0xfe.blogspot.com/2010/05/music-notation-with-html5-canvas.html
>
> A problem with that is that it is not a notation standard. It can't be
> imported or edited into specialized notation programs, for example.

It was just a general notion, not recommending a specific
implementation or notation.

Abc notation rendering (untested):
https://code.google.com/p/abcjs/

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

Re: [Wikitech-l] Bug 189

[Owen Davis]

Magnus Manske  googlemail.com> writes:

> 
> Or we do without any servers, at the expense of older browsers:
> http://0xfe.blogspot.com/2010/05/music-notation-with-html5-
canvas.html
> 

After reading this thread, I was going to suggest this library as well.  :) I 
have played around with it and I think it is quite nice for tablature, but it 
is probably not as good for traditional musicians?  It's true that it has a 
non-standard notation but it is oriented towards editing as simple text, 
and it is entirely client side, which solves a lot of the other problems you 
have discussed.

The official site of that javascript library is http://vexflow.com/ (there are 
more examples and demos there).  It uses an MIT license.  As part of a 
Wikia hackathon last year I wrote a simple extension which adds one 
parser hook, loads that javascript library and renders notation from a 
wiki page.  The downside is the "flash of unstyled text" effect that you get 
as the page loads, but it does work quite well and the extension is only 
~100 lines of code, including the code for the editing box that I created 
so that you can do ajax/live edits.   If anyone wants to check out a demo 
of that, I can send a link to my devbox...

Owen@wikia


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

Re: [Wikitech-l] Bug 189

[Neil Harris]

On 24/10/11 18:23, Owen Davis wrote:
>
> After reading this thread, I was going to suggest this library as well.  :) I
> have played around with it and I think it is quite nice for tablature, but it
> is probably not as good for traditional musicians?  It's true that it has a
> non-standard notation but it is oriented towards editing as simple text,
> and it is entirely client side, which solves a lot of the other problems you
> have discussed.
>
> The official site of that javascript library is http://vexflow.com/ (there are
> more examples and demos there).  It uses an MIT license.  As part of a
> Wikia hackathon last year I wrote a simple extension which adds one
> parser hook, loads that javascript library and renders notation from a
> wiki page.  The downside is the "flash of unstyled text" effect that you get
> as the page loads, but it does work quite well and the extension is only
> ~100 lines of code, including the code for the editing box that I created
> so that you can do ajax/live edits.   If anyone wants to check out a demo
> of that, I can send a link to my devbox...
>
> Owen@wikia
>
>

If vexflow is simple, capable and safe, could it also be converted to 
run server-side as an image renderer, using something like node-canvas? 
If so, then that's potentially a solution for everyone.

- Neil



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

Re: [Wikitech-l] Bug 189

[Owen Davis]

Neil Harris  tonal.clara.co.uk> writes:

> 
> If vexflow is simple, capable and safe, could it also be converted to 
> run server-side as an image renderer, using something like node-
canvas? 
> If so, then that's potentially a solution for everyone.
> 
> - Neil
> 

Oh, that's an interesting idea.  I haven't tried but I would expect that it 
can run with node-canvas.  Shouldn't take too much effort to test it out.  
I'll try to do that and report back.

Owen@wikia


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

Re: [Wikitech-l] Bug 189: "Add a music wikimodule" resolved/fixed

[gnosygnu]

Wow! Congrats indeed. That's really great! I really hope this gets used a
lot; I'd love to see full classical music scores on Wikipedia / Wikisource
(especially since these are the least likely to be copyright-encumbered)

Regarding a lilypond code generation tool:

Last time I used lilypond, I used jEdit (http://en.wikipedia.org/wiki/jEdit).
It's not web-based, but it is open-source (GPLv2) and multi-platform (I run
it on Windows and Linux). Its LilyPond plugin has a number of features (pdf
generation; midi generation) and also a "virtual piano" to generate markup.
See http://i.imgur.com/57wQ5op.png

If you're interested, here are some basic steps:
- Download / install jedit from here: http://www.jedit.org/
- Select Plugins -> Plugin Manager
- Select the Install Tab. Select and download the LilyPondTool
- Depending on platform, you may have to configure the LilyPond binary
path. Go to Plugins -> Plugin Options -> LilyPondTool -> Commands

Hope this is useful...

On Mon, Apr 22, 2013 at 10:27 PM, MZMcBride  wrote:

> Hi.
>
> https://bugzilla.wikimedia.org/show_bug.cgi?id=189
>
> Congrats to all involved in getting bug 189 resolved! :-)
>
> Bug 189 was one of the oldest unresolved and one of the better known bugs
> in Bugzilla involving a request to add a music module to Wikimedia wikis.
> Quick stats about the bug:
>
> * Opened: 2004-08-22
> * Votes: 48
> * Comments: 123
>
> The bug filer is still around and left a nice note on the bug
> ():
>
> ---
> Congratulations to all !
>
> It makes my dream comes true today !
>
> Thanks million times!
> ---
>
>  seemed like an easy target for
> demoing the newly deployed Score extension
> () on a production site,
> if anyone's interested. I tried looking around for a point and click
> lilypond or ABC code generation tool (preferably Web-based), but a lot of
> these tools quickly went over my head.
>
> MZMcBride
>
>
>
> ___
> 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] Bug 189: "Add a music wikimodule" resolved/fixed

[James Forrester]

On 22 April 2013 19:27, MZMcBride  wrote:
> Hi.
>
> https://bugzilla.wikimedia.org/show_bug.cgi?id=189
>
> Congrats to all involved in getting bug 189 resolved! :-)

Yes, brilliant, isn't it? :-) Congratulations to all involved.

[Snip]

> I tried looking around for a point and click
> lilypond or ABC code generation tool (preferably Web-based), but a lot of
> these tools quickly went over my head.

And of course, anyone who feels like taking on a major (but
unbelievably cool) project could lash an existing JS Lilypond editor
into VisualEditor (or, to be even more impressive, write one
themselves) - it could be wonderful!

https://bugzilla.wikimedia.org/show_bug.cgi?id=47528

J.
--
James D. Forrester
Product Manager, VisualEditor
Wikimedia Foundation, Inc.

jforres...@wikimedia.org | @jdforrester

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

Re: [Wikitech-l] Bug 189: "Add a music wikimodule" resolved/fixed

[Tim Starling]

On 23/04/13 12:27, MZMcBride wrote:
> Hi.
> 
> https://bugzilla.wikimedia.org/show_bug.cgi?id=189
> 
> Congrats to all involved in getting bug 189 resolved! :-)
> 
> Bug 189 was one of the oldest unresolved and one of the better known bugs
> in Bugzilla involving a request to add a music module to Wikimedia wikis.
> Quick stats about the bug:
> 
> * Opened: 2004-08-22
> * Votes: 48
> * Comments: 123

So, what should be next ancient body dredged up from Bugzilla and
resurrected by Platform Engineering?

Bugs by number of votes: http://ln-s.net/-3_c

Bug 708 has the most votes, but I'm not sure if a text list in the
sidebar would be prominent enough in cases where the sister project is
truly relevant, for example Wikinews links on current events, or
Wikivoyage links on cities. It would be a very small step towards
correcting the historical lack of cross-project promotion.

Bugs 2867, 167 and 3311 are in progress in some form, so probably
don't need our help.

Bug 674 then? It would fit in neatly with


-- Tim Starling


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

Re: [Wikitech-l] Bug 189: "Add a music wikimodule" resolved/fixed

[MZMcBride]

Tim Starling wrote:
>So, what should be next ancient body dredged up from Bugzilla and
>resurrected by Platform Engineering?

In many ways, I view these two bugs as similar to the departed bug 189 (in
terms of being old, annoying, and seemingly having had some progress made
toward them, but never having gotten finished):

* https://bugzilla.wikimedia.org/show_bug.cgi?id=9890
  "Reasonably efficient interwiki transclusion"

* https://bugzilla.wikimedia.org/show_bug.cgi?id=3311
  "Automatic category redirects"

While bug 3311 is apparently slated for GSoC 2013, surely we've learned
our lesson here year after year.

And bug 9890 could save thousands of man-hours per year. Given the concern
that wiki editorship is on the decline, maximizing editor time by
minimizing duplicate effort seems like a pretty clear win.

In my mind, I think the winner would be a proper wiki configuration
graphical user interface, though. This would make MediaWiki far more
attractive and robust, it would help with project sovereignty (by allowing
Wikimedia stewards to implement requests for individual Wikimedia wikis
and by allowing local wiki bureaucrats to administer their own wiki
without the possible need for a shell user/FTP access/whatever), and it's
the kind of undertaking that many outsiders are uninterested in pursuing
themselves, but that would benefit both Wikimedia and MediaWiki greatly.

* https://bugzilla.wikimedia.org/show_bug.cgi?id=26992
  "Implement configuration database aka configuration management aka no
  shell excuse (tracking)"
  https://mediawiki.org/wiki/Requests_for_comment/Configuration_database

MZMcBride



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

Re: [Wikitech-l] Bug 189: "Add a music wikimodule" resolved/fixed

[Antoine Musso]

Le 23/04/13 04:27, MZMcBride a écrit :
>  "Add a music wikimodule"
> https://bugzilla.wikimedia.org/show_bug.cgi?id=189
> 
> Congrats to all involved in getting bug 189 resolved! :-)

I think that deserves an official press release by the WMF :-D

Congratulations to everyone involved!

-- 
Antoine "hashar" Musso


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

Re: [Wikitech-l] Bug 189: "Add a music wikimodule" resolved/fixed

[David Cuenca]

This is really amazing! Specially for Wikisource :-)

Is multi-page score transclusion with "Extension:Proofread page" able to
generate a global midi/score file or each page has to be treated as an
independent entity?

Micru

On Tue, Apr 23, 2013 at 4:11 AM, Antoine Musso  wrote:

> Le 23/04/13 04:27, MZMcBride a écrit :
> >  "Add a music wikimodule"
> > https://bugzilla.wikimedia.org/show_bug.cgi?id=189
> >
> > Congrats to all involved in getting bug 189 resolved! :-)
>
> I think that deserves an official press release by the WMF :-D
>
> Congratulations to everyone involved!
>
> --
> Antoine "hashar" Musso
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Bug 189: "Add a music wikimodule" resolved/fixed

[Mathieu Stumpf]

First, thank you, that is indeed a really great step. :)

Was the extension enabled on all wikimedia wikis? Wikiversity and 
wikibooks may also benefit from it. I already red some complaints on 
wikipedia fr about someone having difficulies to render gregorian 
partitions (supported by lilypond), so it really show you how much the 
community was waiting for it.


To me it make me wish even more that we had a dedicated project for 
original works[1].


Anyway, congratulations and thank you :)

[1] see this project I am proposing: 
https://meta.wikimedia.org/wiki/Wikikultur


Le 2013-04-23 17:30, David Cuenca a écrit :

This is really amazing! Specially for Wikisource :-)

Is multi-page score transclusion with "Extension:Proofread page" able 
to
generate a global midi/score file or each page has to be treated as 
an

independent entity?

Micru

On Tue, Apr 23, 2013 at 4:11 AM, Antoine Musso  
wrote:



Le 23/04/13 04:27, MZMcBride a écrit :
>  "Add a music wikimodule"
> https://bugzilla.wikimedia.org/show_bug.cgi?id=189
>
> Congrats to all involved in getting bug 189 resolved! :-)

I think that deserves an official press release by the WMF :-D

Congratulations to everyone involved!

--
Antoine "hashar" Musso


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



--
Association Culture-Libre
http://www.culture-libre.org/

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