There is currently a discussion on LWN about distributions and their handling of WordPress (currently subscribers only, ask if you need a link). MediaWiki is likely to start releasing tarballs a lot more quickly, so we're obviously interested in this discussion.
Are there any thoughts here?
On Thu, 17 May 2012, Mark A. Hershberger wrote:
There is currently a discussion on LWN about distributions and their handling of WordPress (currently subscribers only, ask if you need a link). MediaWiki is likely to start releasing tarballs a lot more quickly, so we're obviously interested in this discussion.
Hello,
Do you have a link to this discussion on LWN ?
On 05/17/2012 01:19 PM, Mark A. Hershberger wrote:
There is currently a discussion on LWN about distributions and their handling of WordPress (currently subscribers only, ask if you need a link).
This should be public in a couple of days, but if you want to look now:
https://lwn.net/SubscriberLink/497344/661debc44b7d7b81/
(Someone pointed me to a FAQ about sharing these that indicated it was ok.)
On Tue, 22 May 2012, Mark A. Hershberger wrote:
This should be public in a couple of days, but if you want to look now:
Ah, thanks. Still waiting for my DD subscription.
How _does_ Mediawiki want to handle this? Personally, if I’m a packager of something, and that something has an identified security issue, I’d be glad if there were some sort of issue tracker with a reference to the CVE number, the commit(s) fixing it, and possible versions affected and commit(s) with a backported fix to versions currently supported by upstream, for adding to the packaged version. Tim Starling has referred me to the commits for the one bug I was unable to look at (and I was added to Cc for that bug in the meantime), thanks for that, so I could backport that to the MW we have in Debian.
Is there any interest from MW side to support a specific version (which would have to be released within the next two to three weeks) for a long(er) time? We’re probably talking three+ years here: a year until the release, plus two to three years until the next release. Of course, if we can do our share to backport fixes, sure, but help from actual developers would be better. I’m not very familiar with the code as is.
(Of course pending the mediawiki-math is missing issue; Roland is working on the FF upgrade and has asked for input in case you didn’t see the mail, but it appears that this is handled or will be handled soon, so one of the two reason for me to try to veto an MW upgrade is already gone. – On the other hand, I don’t really want to keep backporting to 1.15 for 3+ years either… so, Jonathan, what’s up with mediawiki-math?)
bye, //mirabilos
On 05/22/2012 11:29 AM, Thorsten Glaser wrote:
How _does_ Mediawiki want to handle this? Personally, if I’m a packager of something, and that something has an identified security issue, I’d be glad if there were some sort of issue tracker with a reference to the CVE number, the commit(s) fixing it, and possible versions affected and commit(s) with a backported fix to versions currently supported by upstream, for adding to the packaged version.
Sam Reed has been supporting versions back to 1.17 lately, but there is no official policy.
I'm looking at what to do going forward. Rob Laphnier, as Platform Director for MediaWiki, has said he thinks WMF shouldn't be in the tarball publishing business.
Since I'm leaving Wikimedia and I've developed some good relationships with WMF's developers as well as the MediaWiki community, I've been talking to Sam and Rob (mostly Sam) about what how to handle this *without* forking MediaWiki.
Is there any interest from MW side to support a specific version (which would have to be released within the next two to three weeks) for a long(er) time?
If I do end up taking over the tarball distribution, I plan on working with a team of volunteers to manage this. This team may include WMF employees like Sam, Chad Horohoe and Tim, to help the transition.
Sam has said that handling multiple versions is problematic and time consuming, but if we have people interested in supporting older versions (like Debian Stable's 1.15), then I think it makes sense to include those in the "official" updates. If we can find someone (you, Thorsten?) to support 1.15 then adding support for 1.16 seems straightforward.
Of course, if we can do our share to backport fixes, sure, but help from actual developers would be better.
The great thing about the WMF's move to git is that we can easily maintain a branch for 1.15 and 1.16. With Gerrit, you can contribute patches or review other volunteer's patches. As the old adage says: "Many hands make light work."
Of course pending the mediawiki-math is missing issue
I've seen the discussion, but not followed it closely. I'll try to look in today and figure out what the issues are and if I can help.
On Tue, 22 May 2012, Mark A. Hershberger wrote:
Sam Reed has been supporting versions back to 1.17 lately, but there is no official policy.
OK.
Is there any interest from MW side to support a specific version (which would have to be released within the next two to three weeks) for a long(er) time?
If I do end up taking over the tarball distribution, I plan on working with a team of volunteers to manage this. This team may include WMF employees like Sam, Chad Horohoe and Tim, to help the transition.
Sam has said that handling multiple versions is problematic and time consuming, but if we have people interested in supporting older versions (like Debian Stable's 1.15), then I think it makes sense to include those in the "official" updates.
Well, we’re 2-3 weeks short of the freeze for the *next* Debian stable. If you pick a version *now* that’ll have had a stable, supportable formal release by then, and will put “Long Term Support” on it, that’s really all a distributor needs. (I’m not really looking toward Debian squeeze. In my totally private and personal opinion, it was not a good release anyway. Our production Debian servers are mostly running lenny still, and migrated to wheezy peu à peu.)
If we can find someone (you, Thorsten?) to support 1.15 then adding support for 1.16 seems straightforward.
I don’t really want to support 1.15 if we get the things done before wheezy is frozen. Also, I cannot commit to anything, maintenance-wise, as I’m doing this during my dayjob (got way too many commitments in my private time already) and cannot always promise things (in fact, I’m seriously behind working on Mailman, which is the other big M FusionForge uses).
My intent was more about getting a supported MW for the *next* Debian.
"Many hands make light work."
True.
Of course pending the mediawiki-math is missing issue
I've seen the discussion, but not followed it closely. I'll try to look in today and figure out what the issues are and if I can help.
Ah, ok. From what I’ve seen, Jonathan has packaged 1.18 for Debian experimental, but it lacks mediawiki-math which is provided by 1.15 and used by our in-house FusionForge deployment (evolvis.org).
bye, //mirabilos
On 05/22/2012 12:10 PM, Thorsten Glaser wrote:
Well, we’re 2-3 weeks short of the freeze for the *next* Debian stable. If you pick a version *now* that’ll have had a stable, supportable formal release by then, and will put “Long Term Support” on it, that’s really all a distributor needs.
So, 1.19 is out now. Can we use that one for our first LTS?
FWIW, MediaWiki is probably going to be moving to a quarterly release cycle. This is because it has always been based off of the release cycle WMF uses and WMF has moved to rolling out new code to Wikipedia and its sister sites every other week with some discussion of going weekly.
Ah, ok. From what I’ve seen, Jonathan has packaged 1.18 for Debian experimental, but it lacks mediawiki-math which is provided by 1.15 and used by our in-house FusionForge deployment
The Math extension on English Wikipedia (and others) now has experimental support for MathJax. But I did look at the Math extension previously. I'll poke at it today.
On Tue, 22 May 2012, Mark A. Hershberger wrote:
On 05/22/2012 12:10 PM, Thorsten Glaser wrote:
Well, we’re 2-3 weeks short of the freeze for the *next* Debian stable. If you pick a version *now* that’ll have had a stable, supportable formal release by then, and will put “Long Term Support” on it, that’s really all a distributor needs.
So, 1.19 is out now. Can we use that one for our first LTS?
Sure. I was asking you to pick, and I’m glad you’re liking the idea at all ;_) as maintaining things is work for you.
Ah, ok. From what I’ve seen, Jonathan has packaged 1.18 for Debian experimental, but it lacks mediawiki-math which is provided by 1.15 and used by our in-house FusionForge deployment
The Math extension on English Wikipedia (and others) now has experimental support for MathJax. But I did look at the Math extension previously. I'll poke at it today.
Hrm. Well, the beast as shipped pulled in a whole LaTeχ horde and did a lot of magic to support that… we don’t want to lose that.
bye, //mirabilos
On 05/22/2012 01:05 PM, Thorsten Glaser wrote:
Hrm. Well, the beast as shipped pulled in a whole LaTeχ horde and did a lot of magic to support that… we don’t want to lose that.
I tried to do it: http://mah.everbody.org/math.tgz
Who should I get to review this?
On Tue, 22 May 2012, Mark A. Hershberger wrote:
On 05/22/2012 01:05 PM, Thorsten Glaser wrote:
Hrm. Well, the beast as shipped pulled in a whole LaTeχ horde and did a lot of magic to support that… we don’t want to lose that.
I tried to do it: http://mah.everbody.org/math.tgz
Who should I get to review this?
No idea ;-)
@pkg-mediawiki: any of you got time to hack on this? Roland’s made a first cut at the upgrade code, so if I get it in .deb form (if not, I’ll try myself) I can test both the upgrade scenario and the new mediawiki and mediawiki-math. Jonathan, did you look at 1.19 for experimental?
Thanks, //mirabilos
Sorry I haven't had chance to join this discussion yet. Real life is currently highly demanding :(
On 2012-05-22 18:05, Thorsten Glaser wrote:
On Tue, 22 May 2012, Mark A. Hershberger wrote:
On 05/22/2012 12:10 PM, Thorsten Glaser wrote:
Well, we’re 2-3 weeks short of the freeze for the *next* Debian stable. If you pick a version *now* that’ll have had a stable, supportable formal release by then, and will put “Long Term
Support”
on it, that’s really all a distributor needs.
So, 1.19 is out now. Can we use that one for our first LTS?
Sure. I was asking you to pick, and I’m glad you’re liking the idea at all ;_) as maintaining things is work for you.
I would like to 1.19 to be the version we ship in Wheezy. However, with the freeze so close we need to consider carefully whether there's enough time. Maybe it would be wise to get 1.18 tested and into unstable first so we at least have a recent version in, and then see if we get 1.19 in its place in time (should be quicker to achieve that second part if the first is done)?
Either way it does make me nervous that upstream would move to quarterly releases without a long-term branch. We've already seen from the 1.15 tree that backporting fixes over that long a time frame gets progressively harder. If upstream releases more often they are presumably also only going to backport fixes for a shorter time.
If you're prepared to support 1.19 as an LTS then I suggest we try our hardest to make that the version we ship in Debian. I didn't get any response to my call for testing of 1.18 though, so I guess we could shove it into unstable and see who complains (when the math replacement is ready).
(For upstream readers: we're talking about a practical period of three years Debian security support here, give or take - plus the six months or so of frozen time yet to come, during which we're not supposed to put anything but targetted fixes in.)
Ah, ok. From what I’ve seen, Jonathan has packaged 1.18 for Debian experimental, but it lacks mediawiki-math which is provided by
1.15
and used by our in-house FusionForge deployment
The Math extension on English Wikipedia (and others) now has experimental support for MathJax. But I did look at the Math extension previously. I'll poke at it today.
I am working on a new source for mediawiki-math which will take the place of the currently bundled extension. That should remove some of the barrier to getting 1.18 into unstable. Thorsten, are there any other major obstacles for you and Roland with your FF hats on?
I plan to ship mediawiki-math as an empty transitional package, mediawiki-extensions-math to replace it (this is consistent with other extensions then) and contain the arch:all parts, and mediawiki-math-texvc or something with the arch:any parts. Please object now if you forsee any problem with that.
Hrm. Well, the beast as shipped pulled in a whole LaTeχ horde and did a lot of magic to support that… we don’t want to lose that.
On Wed, 30 May 2012, Jonathan Wiltshire wrote:
time. Maybe it would be wise to get 1.18 tested and into unstable first
I don’t think having an intermediate 1.18 would be wise if we want to ship 1.19 – rather, I think it would have the reverse effect.
If you're prepared to support 1.19 as an LTS then I suggest we try our hardest to make that the version we ship in Debian. I didn't get any
With the work by Roland Mas on FusionForge side, I’m fully prepared to test the combination of mediawiki=1:1.19* and mediawiki-math from experimental, once the former’s uploaded to experimental and the latter passes NEW queue.
That should remove some of the barrier to getting 1.18 into unstable. Thorsten, are there any other major obstacles for you and Roland with your FF hats on?
Not from FF side, but please spare us testing with 1.18 and then 1.19, time is precious enough already, and it’s easier concentrating on things that really matter.
I plan to ship mediawiki-math as an empty transitional package, mediawiki-extensions-math to replace it (this is consistent with other extensions then) and contain the arch:all parts, and mediawiki-math-texvc or something with the arch:any parts. Please object now if you forsee any problem with that.
Works for me. The dep is on mediawiki-math, for now.
bye, //mirabilos
mediawiki-distributors@lists.wikimedia.org