Hi folks,
To help accelerate code review, we (WMF) have recently made efforts to
expand the +2 merge right on Git/Gerrit, consistent with the idea that
+2 is an expression of trust and confidence in someone's judgment
rather than an indicator of universal technical competence.
For example, you might have +2 on core, but specialize in front-end
code, or documentation fixes, or test changes. That means you would be
expected to only merge changes relevant to those areas, and we trust
you to exercise good judgment to do so.
Our intent is therefore to grant +2 more broadly than we have in the
past, but to also establish clear parameters under which we would
revoke it.
So we've:
- expanded +2 to all full-time WMF engineers by adding them to a 'wmf'
group which has +2 rights on the following repos: apps, glam,
integration, mediawiki, qa, search, translatewiki, webplatform.org
- been more open in handing out +2 to MediaWiki core. Sumana has been
actively nominating trusted volunteers to ensure that they get merge
rights. Five volunteers have gained maintainership rights in the past
week, and we're encouraging you to apply:
https://www.mediawiki.org/wiki/Git/Gerrit_project_ownership
- posted a draft policy for owners of the +2 permission here:
https://www.mediawiki.org/wiki/%2B2
This last bit is the critical part -- as we expand +2, these are the
terms under which reviewers would be expected to operate. Please leave
comments on the talk page if anything strikes you as onerous or
unreasonable, or missing.
Hopefully this will reduce friction introduced with the Git/Gerrit
permissions model and review-related blockers.
All best,
Erik
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
Hey,
After a brief discussion on #wikimedia-tech I was recomended to point this
out at the mailing list.
We have had requests waiting for this for quite some time. Most notably
Chinese projects which have been on hold since December 2006 (bug #8217
[1]) and many others[2] since. The task involves a number of steps for
which a documentation was created[3] but never tested as far as I know.
I feel this issue needs a higher priority particularly because the problem
becomes more difficult as wikis grow in size with time making the process
of a rename more difficult.
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=8217
[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=19986
[3] https://wikitech.wikimedia.org/view/Rename_a_wiki
-- とある白い猫 (To Aru Shiroi Neko)
Hi!
When designing the ContentHandler, I asked around about whether JS and CSS pages
should be parsed as wikitext, so categories etc would work. The gist of the
responses I got was "naw, lets get rid of that". So I did (though PST is still
applied - Tim asked for that at the Berlin Hackathon).
Sure enough, people are complaining now, see
<https://bugzilla.wikimedia.org/show_bug.cgi?id=41155>. Also note that an older
request for disablingt parsing of script pages was closed as WONTFIX:
<https://bugzilla.wikimedia.org/show_bug.cgi?id=32858>.
I'm inclined to (at least optionally) enable the parsing of script pages, but
I'd like to get some feedback first.
-- daniel
While going through the bugs that were marked as 1.20 tarball blockers
today, most seemed to have been left to rot -- that is, they didn't
really deserve the tag since people were not motivated to fix them and
the people who marked them 1.20 tarball blockers didn't put in the
effort to find someone to fix them.
Sometimes, that person was me, so this shouldn't be seen as overly harsh
criticism.
I did see a couple of exceptions:
* https://bugzilla.wikimedia.org/38273 -- Tidy occasionally isn't
executed
Seems to be happening somewhat regularly since July on different WMF
sites. Some effort to track it down has been made, but no solution has
been found yet. I've a feeling this bug would bite third-party users of
MW if we released a tarball with it.
* https://bugzilla.wikimedia.org/35894 -- Reports of secret key
generation "hanging" on windows`
This is a bug that will really affect only new tarball users on Windows.
While this probably isn't a lot of people, I would still like to see it
fixed before a tarball is released. MaxSem had some ideas and I'll talk
to him about how feasibly he can implement them.
Otherwise, there are several patches mostly by Krinkle that need to be
merged for a 1.20 tarball:
https://bugzilla.wikimedia.org/31676 - ResourceLoader should work
around IE stylesheet limit
https://bugzilla.wikimedia.org/38158 - jquery.byteLimit sometimes
causes an unexpected 0 maxLength being enforced
https://bugzilla.wikimedia.org/40448 - Replace
mediawiki.legacy.mwsuggest with SimpleSearch.
https://bugzilla.wikimedia.org/40500 - ResourceLoader should not ignore
media-type for urls in debug mode
https://bugzilla.wikimedia.org/35923 - Followup to bug 11374 - tweaks
to mediawiki.action.history.diff.css
https://bugzilla.wikimedia.org/40498 - ResourceLoader should not output
an empty "@media print { }" block.
I still plan on being in #wikimedia-dev at UTC1100 on Tuesday, October 2
(See [0] for timezone conversion) for the triage, but I'll probably be
spending that time putting in merge requests for the above issues
(unless someone beats me to it).
Also Tuesday, I'll make a new tarball with the code merged as my final
release candidate for 1.20. Sam has said that because we're doing a
review-first model with Gerrit people should feel more liberty to put
merge requests in, so have at it! [1]
Mark.
[0-short] <http://hexm.de/lr>
[0-long]
<http://www.timeanddate.com/worldclock/meetingdetails.html?year=2012&month=1…>
[1-short] <http://hexm.de/lw>
[1-long]
<https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/core+branc…>
--
http://hexmode.com/
Necessitous men are not, truly speaking, free men.
-- Vernon v Bethell (1762), quoted by FDR's Second Bill of Rights
Hey,
Is there currently a way for extensions to register additional info they
gather during the parsing process to the parser output? Right now Semantic
MediaWiki is doing this by assigning to the non-defined field $mSMWData
which causes notices when strict is on with PHP 5.4, so I am looking for a
good way to fix this.
If there is no way to currently do this I propose this very simple
addition: https://gerrit.wikimedia.org/r/#/c/28767/
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
Chad wrote:
> I rather prefer this format, to be honest. And actually, Gerrit
> has a feature (we're not making use of, but we easily could
> if people are interested) where you can track those bug footer
> notes. We could easily add regexes for Bugzilla and RT (gerrit
> calls them "tracking ids") if that's something people would use.
>
> -Chad
This would be great, particularly if we can surface them in the
release notes, where having a bug number attached turns out to be a
really good heuristic for "this is an important change you should take
a look at".
Harry
--
Harry Burt (User:Jarry1250)
On 10/16/2012 05:33 PM, Platonides wrote:
> Basically, removal of config files which are there just for development.
Right. And this is part of https://gerrit.wikimedia.org/r/#/c/23919/
> PS: Note that REL1_20 got a new fix for bug 40780. I would delay the
> release and try to get the listed bugs with patches merged for 1.20.
> As those are changes from rc1, IMHO we should also ship a rc2 before
> going final.
I'll put out RC2 tonight or tomorrow. But I would like to get 1.20 out
today or tomorrow.
Mark.
--
http://hexmode.com/
Any time you have "one overriding idea", and push your idea as a
superior ideology, you're going to be wrong. ... The fact is,
reality is complicated -- Linus Torvalds <http://hexm.de/mc>
Dear all,
today I did some changes to simplify the math plug in a little bit and
as a preparation to the LaTeXML integration:
Please review and comment at:
https://gerrit.wikimedia.org/r/#/c/28824/
Best regards
Moritz
PS: I had some problems with the commit messages. They were not
accepted so the text is lost.
What I basically did that I separated the code of the divers ways of
rendering into separate classes that extend a common base class.
On Mon, Oct 15, 2012 at 12:13 AM, Moritz Schubotz
<physik(a)physikerwelt.de> wrote:
> HI DJ,
>
> first of all thanks a lot for your helpful comments.
>
> On Sun, Oct 14, 2012 at 10:31 PM, Derk-Jan Hartman
> <d.j.hartman+wmf_ml(a)gmail.com> wrote:
>> On 14 okt. 2012, at 17:45, Moritz Schubotz <physik(a)physikerwelt.de> wrote:
>>
>>> Summary: I'm looking for people to discuss about the parsing of math.
>>
>> The last person who really did some work on the extension was Brion Vibber. Almost all of the (limited) work that has gone into the extension over the last 1,5 year was actually based on the efforts of User:Nageh on the English wikipedia and his MathJax userscript. Beyond these MathJax changes, the extension has not seen much developer involvement for quite some while.
>>
>>> I came up with a proposal for a new version of the rendering of the
>>> <math> tag. I proposed to use LaTeXML to convert the LaTeX expressions
>>> in the math tag to MathML. If the browser is not capable of displaying
>>> MathML I use MathJaX to display the MathML output in the browser.
>>> My implementation (the LaTeXML branch) has only a few very little
>>> differences in contrast to the master branch. I have the feeling that
>>> the php code of the math extensions could be improved. For example I'd
>>> suggest to put all the texvc related stuff to another class.
>>> Furthermore I was thinking about an asynchronous rendering of the
>>> formula, which would speed up page loading time especially for major
>>> edits.
>>> At
>>> http://wiki.physikerwelt.de/images/text_math_search.pdf
>>> you find the draft of a paper where I describe in detail what
>>> I changed and why it is an improvement. The paper will appear soon in
>>> the postconference proceedings of CICM2012.
>>> Now I want to figure out, who is working on the development of the
>>> math extension, and who wants to discuss with me about our ideas.
>>> I'm open to any kind of suggestions and questions.
>>
>> Discussion is always welcomed and in this case probably best on the mailinglist.
>>
>> You seem to propose switching our current texvc -> image converter (by some users extended by using MathJax) with a LaTeX -> MathML presentational renderer that would use MathJax as a backup. The renderer would also output Content MathML to make the content easier to index and search. In general I would support this, definitely morally.
>
> I see MathJaX rather as a renering engine that supports browsers that
> do not such a good job in displaying MathML, rather than a fall back
> alternative.
>
>>
>> There are however some problems here as well.
>> - If a browser does not support MathML and not support (have enabled) Javascript, you would see nothing reading the article.
>>
>
> MathML is also capable of producing images. However this feature is
> more designed for the rendering of whole documents rather than for
> small latex snippets. So this would require a little customization.
>
>> - Browser support for MathML is still spotty. It would be nice if we can gather some actual numbers on this. There are apparently also significant bugs in rendering implementations. I believe this is one of the reasons that the default of MathJax is HTML+CSS now, and not MathML.
>>
>> - You are determining support serverside right now ? This would require fragmenting the cache when we move forward.
>
> I'm nor sure if I understand, what you mean by that. The math table
> becomes much larger as it is if you use texvc, since the matml column
> contains all the mathml code which is not really optimized with regard
> to space.
>
>>
>> - I think that currently a large group of users would fall into your MathJax group. Especially those with older browsers. However, we don't particularly like MathJax for that usergroup. It is incredibly slow on the client side and this greatly affects the userbase with less capable computers (of which we have quite a lot). This is one of the main reasons why we are not particularly pushing for this solution as a default right now (let alone as the primary backup method). I would seriously consider just skipping MathJax (at least by default) and just show images for the fallback option.
>
> MathJaX is slow if you want to display LateX stuff. If you want to
> display MathML with the help of MathJaX- that's what I propose-
> MathJaX is reasonably fast.
>>
>> - In order to provide proper MathML support, a proper font is required. Many Operating Systems do not yet have this font support. This is something that possibly could be solved with WebFonts, but will require a bit of work.
>>
>> - MathML does not, I believe, provide everything that is possible with texvc. This is another issue that we are currently seeing with MathJax, though we (Nagheh actually) has added most of them to MathJax by now. For MathML the solution seems not so simple however. This probably means we either need to phase out part of what we currently support (always complicated) or fragment the implementation for these particular situations.
>
> This would be really interesting to see which are those things, that
> can not be displayed with MathML.
>
>>
>> - I'm not aware of the current quality of LaTexML. Is there some information about the 'completeness' of the capabilities and quality of the implementation? Comparisons with other implementations ? That would be useful information.
>
> I'll provide some information soon.
>>
>> - Outputting both Presentational and Content MathML into the HTML will significantly increase the page size.
>
> This is true. I saw that in my experiments.
>
>>
>> - LaTeXML will have to be reviewed by one of the developers of the security team.
>>
>
> Yes. I think the major advantage of LaTeXML in contrast to texvc is
> that it can be run on a separate machine, with very restricted rights.
>
>> These would be the issues that I think would require assessment and solving at some point before a full solution can be deployed on Wikipedia. But of course, we can just start and expose the functionality at a later time.
>>
>> DJ
>>
>>
>> P.S. Seems that MathJax 2.1 will be released soon: http://www.mathjax.org/2012/10/01/news/mathjax-v2-1-beta-now-available-on-t…
>> _______________________________________________
>> MediaWiki-l mailing list
>> MediaWiki-l(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>
> Thanks again for the feedback.
>
> Best regards
> Moritz
>
> --
> Mit freundlichen Grüßen
> Moritz Schubotz
>
> Telefon (Büro): +49 30 314 22784
> Telefon (Privat):+49 30 488 27330
> E-Mail: schubotz(a)itp.physik.tu-berlin.de
> Web: http://www.physikerwelt.de
> Skype: Schubi87
> ICQ: 200302764
> Msn: Moritz(a)Schubotz.de
--
Mit freundlichen Grüßen
Moritz Schubotz
Telefon (Büro): +49 30 314 22784
Telefon (Privat):+49 30 488 27330
E-Mail: schubotz(a)itp.physik.tu-berlin.de
Web: http://www.physikerwelt.de
Skype: Schubi87
ICQ: 200302764
Msn: Moritz(a)Schubotz.de