Mass infection vector
As part of the great plans for Monobuntu, Canonical Ltd. are sponsoring my attendance at the Ubuntu Developer Summit in Barcelona in May. This will give me a chance to discuss the Desktop team’s needs and wants for Mono, bounce suggestions around for how to further shrink the installation footprint, and fling spitballs at the Java and Python teams. I’m really looking forward to some productive discussions, to help make Ubuntu 9.10’s Mono even more awesome than 9.04’s.
April 2nd, 2009 at 4:45 pm
My advice is to ship Mono bits that are more up to date. It will be September before I can use Mono 2.4, which was released in March.
[reply]
April 2nd, 2009 at 4:54 pm
There are a few factors at play here.
Firstly there’s the new upstream release schedule, which means a new major version every 3 months. It’s guaranteed that there’ll be 2 new versions of Mono during an Ubuntu release cycle, with one Mono release just before or just after the Ubuntu release (we look bad either way)
Secondly, there’s 2.2. Preliminary testing within the pkg-mono team showed that 2.2 would require a fair number of fixes from Mono SVN (or to apps) to be stable enough to use. That’s why Jaunty is shipping with 2.0.1
Karmic will definitely ship with 2.4 at least – if not 2.6. However, 2.8 will be released just at the same time as Karmic, so you’ll complain anyway ;)
[reply]
April 2nd, 2009 at 6:17 pm
The place for an updated Mono stack might be in a PPA, akin to what the Banshee PPA team does. Alternatively one could go the route Fedora and Foresight takes, shipping the latest and it Fedora’ case aggressively shipping svn snapshots during the development cycle which makes it easier to preemptively file bugs against Mono and Mono using apps due to the changes.
No approach is perfect, for my money Ubuntu has a very nice Mono stack, I know Jo works tirelessly to bring the very best to his people and improving Mono for everyone. I am greatly impressed with the extensive guidelines that pkg-mono have been working out. I fully plan to ste.. borrow them as inspiration when I rewrite the Fedora guidelines as my fun little Easter project.
[reply]
April 2nd, 2009 at 7:08 pm
A PPA is fine – it wasn’t possible this time around due to the packaging changes between 1.9.1 and 2.0. I’ve offered 1.9.1 for Hardy (1.2.6) for a while.
As for snapshots etc… if someone else volunteers, then that’s up to them. I’m uneasy about pushing things onto the main archive which are unsupportable (and possibly broken). The main Ubuntu developers like to freeze versions of “core” software pretty early in the release cycle, and Mono is core in Ubuntu – the last thing we want is for default apps like F-Spot or Tomboy to be busted. Sometimes development releases take the “might break from time to time” thing a bit far – https://bugzilla.redhat.com/show_bug.cgi?id=492947
[reply]
April 2nd, 2009 at 7:20 pm
The good news is that Jaunty has MonoDevelop 2.0 which is brand new. Let’s just hope that it works reliably with Mono 2.0. I’m sure not many Mono programmers use this combination.
I think you should try to grab the release that is closest to your ship date and plan on using it. That is what happens with Gnome.
It is also better for Mono for Ubuntu to be using the latest code. And if there is a bug, it can be fixed before or after the release. That is what the betas and repos are for.
Note, this problem isn’t just confined to Mono, here is a further list of the ways Ubuntu is behind the curve: http://subbisays.blogspot.com/2009/03/ubuntu-904-vs-fedora-11-lot-can-change.html
It feels weird to go to the trouble to upgrade Ubuntu every 6 months only to be installing a bunch of 6 month old code. If I want to see what the free software world is up to now, Ubuntu seems like it is no longer the choice. That is also a shame because it means that Ubuntu isn’t helping the rest of the community find bugs.
I realize there are tradeoffs here, but in general free software evolves and gets richer, faster, more stable, and in general better every day so using the latest is generally best.
[reply]