Archive for June, 2006

On Ubuntu and g-s-t

Friday, June 9th, 2006

After reading several comments on the Umbrella project, and talking with Michael Vogt and Daniel Holbach I had to drop my feelings about the whole thing:

As a developer

Pros: Perl “sucks”, it doesn’t suck per se, but not getting contributions *sucks* [1]. Python on the other hand is hype, currently there’s much more people willing to contribute coding in Python than coding in Perl, but that’s not news.

If there’s a Python replacement for the backends, I bet that there will be much more people willing to look at that code, and that can easily translate to more contributions, so if a framework to add support for other distributions is done too, that will make many people happy [2].

I strongly believe that s-t-b concept and structure is the right way, but experience forced me to think that it was in the wrong language.

Cons: Maybe most of the concepts would be reused, but there would be heaps of code that wouldn’t, the project status would be almost resetted to 0, it would go from supporting tenths of distros to supporting 1.

The big plan behind s-t-b, dbus, liboobs and g-s-t wasn’t just ditching the XML interface, it was to split things down to make contributions as painless as possible at any level (DBus also allows to do things that were nearly impossible with the XML interface, but that’s a different issue), For example the codebase in the backends has been shaved to 11KLOC (according to sloccount, much of it is common boilerplate, specific code for one distro must not reach more than 300-500 LOC). I’d like people to have a look at the code modifications before willing to replace parts of it (the new g-s-t structure also allows that quite more easily)

Replacing the frontends with python scripts is a different horse, reusing just the g-s-t glade interfaces reminds me what my beloved mentor Chema (RIP) told me once about RedHat doing the same a long time ago

Personally

I’ve failed, I once thought that s-t-b would be an excellent collaboration framework for distributions, the reality is that the only big distro using it now plans to switch, some other distros ship g-s-t as a curiosity and others don’t do that at all. The patches from distros, although very appreciated, have been very few, so s-t-b is miles away from where it could be (Maybe it’s just my lack of leadership, or that I’m a poor unemployed guy and don’t represent any big FS company, who knows)

In the case that Umbrella tries to do a multidistro framework (I bet it will success over s-t-b with time, people love Python after all), I don’t think I will collaborate regularly with code, I’ve been struggling with g-s-t for more than 4 years, and I’m not willing to start the very same thing from scratch. However, I’m fully available to give advice, after all I think I earned enough know-how on the subject.

I really hope that people won’t think I’m pissed off, Michael and Daniel are quite happy with their decision, if they are happy and take this to the end, I’m happy too. It’s just that I’m a practical guy, and I should focus on other parts of the desktop where my code would be more appreciated.

And now, off to my guitar lesson…

[1] Really, I think I could count contributors to s-t-b in the last year with the fingers of one hand. even my last post got no response at all
[2] You wouldn’t believe the ammount of people that tried to convince me to rewrite s-t-b in Python

A plea for help

Tuesday, June 6th, 2006

After some months of apparent inactivity in gnome-system-tools, during the last couple of weeks I’ve been moving to HEAD the changes done in the experimental branches and closing heaps of bugs. Finally today I’ve been able to make releases for system-tools-backends 1.9.0, liboobs 0.1.0 and gnome-system-tools 2.15.0.

These releases mean a significant step forward, s-t-b now features a DBus interface (Thanks to Net::DBus, courtesy of Dan Berrange, thanks!), liboobs provides a GObject interface totally abstracted of the communication layer, and g-s-t takes advantage of it.

This also means that lots of code have been refactored/deleted, this specially concerns me in the backends. Given the wide range of distros it supports [1], and my impossibility to test them all [2], I’d thank if anyone could test the tools in their favorite distro. For the record, I’ve already tested them in Debian/Ubuntu and everything worked as expected :). If you want to help, I’ve setup a wiki page explaining how to compile & test g-s-t HEAD, so please if you find something that doesn’t work as expected in your distro, file a bug or send me a mail (carlosg at gnome dot org), I’ll take care of fixing it.

[1] Really, lots. But testing with latest Ubuntu/Debian, SuSE, FreeBSD, Gentoo, Fedora, … should cover 99% of the code paths

[2] Liboobs eases the creation of automated tests, but I’m also lacking enough HDD space