I said I would lay out my thoughts regarding MW releases this weekend,
so here goes.
First: I want to provide a regular schedule so users know what to
expect, but something that a volunteer (me, for now) can achieve.
Second: I want to provide something that Linux distributors can
incorporate into their distributions.
To fulfill the first point, I think a release twice a year -- like
Ubuntu releases -- makes a lot of sense. This schedule also works for
Linux distributors like Ubuntu, Fedora, and OpenSuSE
Since I started out using Debian (which has now adopted a 2 year freeze
cycle), I think it also makes sense to provide LTS support. Platonides
and I (but mostly Platonides) have been working with the Debian
developers to get 1.19 into Wheezy which was frozen in June.
With that in mind, here is what I propose:
1.18.0 | Security updates till 1.20
1.19.x | April 2012 (LTS)
1.20.0 | October 2012
1.21.0 | April 2013 (Start in May)
1.22.0 | October 2013 (Start in September)
1.23.0 | April 2014 (LTS)
1.24.0 | October 2014
1.25.0 | April 2015
1.26.0 | October 2015
1.27.0 | April 2016 (LTS)
LTS releases will updates until (at least) the next LTS release. This
means security updates, but other updates that don't require schema
changes if people are interested in providing them. Since a couple of
people have put the 1.20.0 milestone on a handful of bugs, I'm assuming
now that they think those are worth merging to the 1.20 series. I'd
like to get the fixes backported to 1.19 as well, if possible.
Well, that's pretty much it what I was thinking. How does this sound to
you guys?
--
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>
Summary: I'm looking for people to discuss about the parsing of math.
Dear all,
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.
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
https://www.mediawiki.org/wiki/Manual:File_cache
Enabled this on rationalwiki.org and the results are amazing. The site
is just ridiculously fast to browse logged-out, and I'm almost looking
forward to our next Reddit-dotting.
Is there any reason this is not enabled by default? (Is the
possibility of dynamic templates not being re-rendered enough reason?)
- d.
rationalwiki.org was foolish enough to start using the experimental
LQT2. So of course the project was abandoned and we're stuck with a
pile of content in LQT, and it broke in subtle and awful ways when we
upgraded from 1.16 to 1.19.
Symptoms we're seeing:
* The loader gif for the toolbar keeps spinning. (The request actually
completes successfully.)
* CSS and JS load late. (Page looks awful until then.)
* Takes *ages* to load (could be browser, could be server-side) -
enough so that people avoid using it.
One thing I notice is it's quite fat on memory - PHP max_memory was
64MB, LQT was regularly running out of it (is happier at 96MB)
Server: MW 1.19.1 tarball, PHP 5.3.2-1ubuntu4.18 (apache2handler),
MySQL 5.1.63-0ubuntu0.10.04.1, Ubuntu 10.04 on amd64 Linode. Default
skin is Vector.
I realise that LQT2 is unmaintained, LQT3 isn't finished either and
basically we get to keep both pieces. But has anyone beaten LQT2 into
usable condition on 1.19?
Failing that, is there any tool to convert LQT2 discussions into a
format that can be parsed by something that's maintained?
- d.
I've been pretty busy with other work all week and, as a result, I
haven't had time to look at the 1.20 release. On September 30 (2 weeks
ago) I sent out a message with what I saw as the blocker bugs at that point.
Only one of those bugs does not yet have any sort of resolution on it.
> * https://bugzilla.wikimedia.org/35894 -- Reports of secret key
> generation "hanging" on windows`
At this point, I think we should add a "known issues" section to the
release notes and plan to have a 1.20.1 release with this so that I can
put together an RC1 tarball tomorrow for you guys to test.
That said, some bugs have been added to the 1.20.0 milestone, but unless
there is a major objection, I'd like to target those to the 1.20.1
release so that we don't hold up the 1.20.0 release any longer. These
bugs could be listed in the "known issues" section of the release notes
with a statement that we're planning a 1.20.1 release.
And, speaking of plans, I will have time to write up my ideas for a
release schedule tomorrow. This will mean plans for future releases as
well as support for 1.19 and 1.18.
Mark.
Hello everyone,
Im need some way of making recomendations in my wiki, so that, I could
point a user to a particular page, according to some criteria.
I was thinking about keeping track of all the navigated pages, so I could
use this data for recomendations, or something like that.
Is there any extension to do something like this?
Thanks in advance,
Marcelo.
Hello,
I am running Mediawiki 1.19.2 on a CentOS 6.3 box, and have installed
the ClamAV 0.97.6 package (using yum). I have also set $wgAntivirus to
'clamav' in my LocalSettings.php file.
However, when trying to upload an image this gave me an error code of
127. (Checking the image locally it passes clamav with no problem.)
I then modified $wgAntivirusSetup to use the absolute pathname to
'clamscan'. This now gives me a 126 error code.
I am now a bit stuck. Not too sure what the problem is. The debug log
shows:
==============
UploadBase::detectVirus: running virus scan: /usr/bin/clamscan
--no-summary '/tmp/phpa5rFd7'
wfShellExec: /bin/bash '/var/www/html/mediawiki/bin/ulimit4.sh' 180
102400 102400 '/usr/bin/clamscan --no-summary '\''/tmp/phpa5rFd7'\''
2>&1'
UploadBase::detectVirus: failed to scan /tmp/phpa5rFd7 (code 126).
==============
So 'clamscan' seems to run okay via mediawiki, but fails for some
reason. Anyone any ideas? I have been trying to find what the 126 error
code actually means, but ClamAV doesn't seem to provide a list of error
codes anywhere.
Thanks,
John.
--
John Horne Tel: +44 (0)1752 587287
Plymouth University, UK Fax: +44 (0)1752 587001
Does watching a category page mean that
one will be notified if 12 becomes 13?
|Pages in category "DCS 132"
|The following 12 pages are in this category, out of 12 total.
Or only if the category page is actually edited?
Maybe a note about this should pop up when the user is about the click
the watch button.
Hey,
> Nice!!!! Looking forward to demos at SMWCon :)
There will indeed be demo's, see
http://www.semantic-mediawiki.org/wiki/SMWCon_Fall_2012/New_features_in_Map…
> BTW, is Semantic Bundle going to be updated with the latest maps soon?
This depends, we've not seen a new Semantic Bundle for a while due to the
git migration, and no one seems to be willing to update the build scripts.
That should be rather simple though, so if any developers wants to help out
here...
> If not, are there any dependencies that will break if I upgrade to Maps
2.0?
Maps 2.0 requires Validator 0.5. So if you have any extensions that use
Validator, I'd recommend you get their latest version. There is a
compatibility layer that should prevent breakage, but updating is still
advisable. In particular Semantic MediaWiki and Semantic Result Formats.
Both these extensions have not seen a new release yet using this version of
Validator, but they are close to seeing a release, and should be pretty
stable at this point. If you don't want to run beta versions you'll be
better off waiting another month or so with upgrading your extensions.
I'd recommend the same for anyone using OpenLayers and wants high
stability, there are some non-trivial open issues which are also present in
the 2.0 release.
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--