Tag Archives: .NET

An adventure in Open Source contribution

Posted by

2

I’m now officially a contributor to Banshee.

While I have done a lot of advocacy work and packaging, this is my first ever proper code contribution to Open Source. Coding as such never really excited me and as a result it has been some 5 or 6 years since I last sat down to understand and work on significant code. Even then I never really got deep into programming as specification and design always was more fun to me than implementation.

It all started when a friend buzzed me a presentation by Anders Hejlsberg titled The Future of C#. While I haven’t done much with .NET I have always been impressed by it as technology and I was eager to learn of what new tools would come in the future. Naturally the talk was also attractive to me because one of the features Anders demos (Compiler as a Service) as a coming post 4.0 release feature is in Mono today, something I always like to think about when people say that Mono forever will be “chasing the dragon”. Regardless, the talk got me excited about coding and was extremely entertaining to boot. So I wanted to try something, anything, and since I like Banshee but also see it crashing and being slow a lot as a daily stress tester and bug filer I decided to subject it to experimentation.

In comes the magic of .NET, Mono, and Ubuntu. In Ubuntu I found all the tools I needed, namely MonoDevelop, mono-tools and finally Gendarme. Gendarme is a really cool project that can inspect assemblies and executables according to a set of rules for such things as security, performance and even bad practices. So I decided to run Gendarme on then content of /usr/lib/banshee-1 expecting to see a few hits and probably a lot of false positives. However Gendarme returned more than 8800 issues even on medium settings, so I limited my focus to just the performance rules set.

Gendarmes issue reports have excellent documentation with examples of bad and good code as well as careful explanations, making it easy to pick a simple problem such as the one addressed with my patch. In this case we now determine these variables at compile time rather than at link time which is faster. It is safe to do and doesn’t break external assemblies as the fields are not shown outside. All of which was explained by Gendarme and confirmed on the Banshee IRC channel. Gendarme even explained how to fix the issue, it could not be easier. Bertrand Lorentz was kind enough to sign off the patch and commit it within minutes. As an example the Gendarme article on the issue type my fix addresses can be found here.

Regardless, that was yesterday. Today my Banshee is once again back to being a git build by hand which with the excellent Banshee daily repo hasn’t been required since I stopped contributing to Fedora. The reason is simple, I needed to compile test some more changes as I was reading the Banshee source code and learning. With friendly hints from the existing developer base also growing some basic understanding of what is going on.

Contribution is easy, zero to sixty even, with Mono and Banshee.

Mono SIG full stream ahead

Posted by

0

Lots of energy expended on Mono the past few days, attempts to violate bodhi in ways unspeakable and abominable to humanity turned up a bug. Not quite the progress imagined but now our users should have a nearly warning free Mono experience starting up Banshee, I say nearly since Boo has yet to be fixed up. I am unwilling to start deeply tinkering with this to bring Boo 0.9 into Fedora as this is not my package and it is rather complex, also the existing Boo package no longer compiles on F10 for some reason.

Most importantly we now have our own mailing list, to which I shall soon send out a proposed action plan. There is a lot of ground to cover to make Mono all it can be for Fedora users. E.g. our packaging guidelines have not been touched in years and definitely need some reviews and updates. Additionally there is work to do to bring a complete stack to our users and developers. Much excitement ahead.

Jeremy Katz kindly informed me that he has a patch to allow splitting out the debuginfo packages correctly for Mono which will bring much needed size reduction to our packages.

Also I am writing up documentation on how to correctly invoke Monodoc and having generating documentation where available be a required step for the packages covered by the SIG. This will require a full review of all our packages, and would make for great work for a beginning packager to get involved with. I am hoping to be able to setup tasks all the way from willing testers to experienced packagers, in the hope that everyone can contribute to the best of their ability and time. I find it important to be welcoming to any new talent however small, just something like having a group of people to turn to to do test installs of packages and confirm that bugs are closed or still valid is extremely helpful.

Finally Debian and Ubuntu are doing some interesting work patching Mono to reduce size and increase performance by forcing a full transition to Mono 2.0 which we definitely need to examine more closely.

Congratulations Mono team on shipping 2.0

Posted by

0

Mono 2.0 lands today, thank you all for 1559 days of making Linux better by bringing us all this wonderful technology.

All possible congratulations to you fine gentlemen (and ladies) working on Mono on this excellent release.

As a bonus Paul Johnson the Fedora maintainer has announced that he plans to push 2.0 to F9 once it has proven itself in rawhide for a bit. Hopefully giving us a policy in the future of having the same superior up to date version available to all of our users.