Present Perfect

Somehow I always end up delaying releases of mach until a few weeks after a new Fedora Core release, even though I always add the relevant files before the release. This time was no exception. One of the main reasons is because I don't have a smooth release process as I have for GStreamer, and that always annoys me enough to not properly do a release.

Anyway, using the prototype tools I cobbled together over the weekend I sent out the release announcement mail and updated the freshmeat record.

As for mach itself, features in this release include:
- added DOAP file (Thomas)
- added Fedora Core 5 (Thomas)
- fix build ordering when building multiple packages (Thomas)
- always evaluate spec file inside the root (Thomas)
- add an option for md5summing of results (Matthias)
- pass 'buildopts' from a root config to rpmbuild (Thomas)
- add 'excludearch' property to root config,
fixes yum's semi-random behaviour on x86_64 (Thomas)
- store yum cache data per-dist, shared for flavors (Thomas)
- clean up yum metadata for local repositories (Thomas)

Enjoy, and let me know if you run into anyissues.

Meanwhile, the mach3 rewrite is getting functionality added step by step as I have some days off to work on them. I added a bunch more stuff the past weekend, and I now have a working mach binary that can go through all the setup steps. That's probably going to stimulate me more than anything else to go back to hacking on it - even though developing the classes correctly and writing unit tests for them on its own is fun as well, as long as there isn't a mach binary to play with it still feels as if it's years away from completion.

Somehow I always end up delaying releases of mach until a few weeks after a new Fedora Core release, even though I always add the relevant files before the release....

GStreamer 0.9.6 is out. For those not in the know, a new stable release is less than two weeks away ! This release incorporates all the API changes we had queued up over the last month. It was a bit of a commit- and bug-closing frenzy, so it was two days late, but it's out now.

If you've written an application using GStreamer, better late than never to try and port your application and point out any possible problems we might have forgotten about...

I'm looking forward (though with a little anxiety) to the stable release - I'm very happy with all the love the core has gotten, and we've been able to layer lots of quality all over - automatic build testing, unit tests, automatic valgrinding, ... Edward is working on a media test suite which will be out soon as well. Seems #gstreamer has really caught on to what it takes to produce and improve quality, which makes me happy.

I remember a few weeks ago when someone proposed a port of the matroska muxer to 0.9 and I said "well, your patch is missing a unit test". I was expecting him to tell me to take a hike. But no - he wrote a unit test, submitted it, and added "writing this unit test I found a few bugs in my muxer." G-r-r-r-r-r-r-r-eat !

Anyway, I'm sure all other libs out there were already doing this, and this is nothing new - but it makes me happy we've come this far.

Now, on to cleaning up more of our tree and moving some stuff around...

GStreamer 0.9.6 is out. For those not in the know, a new stable release is less than two weeks away ! This release incorporates all the API changes we had...

Rolling both a GStreamer prerelease and a Flumotion release.

I'm pretty damn happy with the new Flumotion release - it has some very nice improvements. The important one is the bundling of UI code which gets sent over the network, so that the admin client really is just a light shell that works everywhere.

We already has a basic concept of sending over UI, but now it's been cleaned up and it works a lot better.

Basically, the manager on a machine has a registry that tells it how a bunch of files in the local tree are to be "partitioned" into a set of "bundles". Each bundle is just a group of files that belong together (like, say, icons, glade files, and PyGTK code for changing colorbalance). Bundles can depend on each other (since, say, the tv card UI code depends on the colorbalance ui code). The union of all bundles represents the whole set of files that can be sent over the network.

The interesting part is that when the UI wants to show a page for a component, it asks the manager "I want to do this import. Give me everything I need". The manager replies with the list of bundle names it needs, as well as md5sums for the .zip files for these bundles. The admin checks locally for which zip files it doesn't have yet (or are outdated -hence the md5sum), and then requests all bundles it needs.

When it has them, it extracts them locally in a cache directory, *in a unique dir based on bundle name and md5sum*. Then some python magic is done so that you can import from the bundle namespace directly. So even if a file is extracted locally as "bttv-ui/a589fec...f3f/flumotion/component/producers/bttv/admin_gtk.py", you can just run "import flumotion.component.producers.bttv.admin_gtk" and it works.

Now, why all this caching ? Because you can run the same admin client against different versions of managers. So instead of having to download all code each time, you just cache all downloaded instances, and regularly clean up old ones.

One of the nice things here is that just clicking on the component ui again automatically runs the newest code. Very handy for testing.

Anyway, new flumotion came out today. Give it a spin.

Rolling both a GStreamer prerelease and a Flumotion release. I'm pretty damn happy with the new Flumotion release - it has some very nice improvements. The important one is the...

Finally. Our 0.1.0 release has arrived. There are bugs, but there are even more cool features. Today we used four machines to create a stream, everything from the GUI wizard. So after some French floating point fixing, we tagged the release and threw out packages.

Here's the tarball. Knock yourself out and start filing issues.

Now excuse me while I go home and have some quality time with my overly neglected girlfriend who I dearly miss.

Finally. Our 0.1.0 release has arrived. There are bugs, but there are even more cool features. Today we used four machines to create a stream, everything from the GUI wizard....

I *hate* doing multiple releases in short succession.

Did a GStreamer 0.8.6 release yesterday, finally, after being stalled by unresponsiveness to revert threats, internet loss at work, and internet loss at home. Ronald pushed me for a new plugins release as well, which is supposed to go into FC3. And then Wim did two simple great fixes to the core, prompting me to release a new core. It's not brown paper bag, it's just that good a fix. But still. I was trying to get some actual WORK done today. Sigh.

In unrelated news, I was happy to make this screenshot this morning. I fixed the code to display "1 week" instead of "1 weeks" after the server was started, and added regression tests for it. In any case, having the server stream rock stable from an SMP machine using threads inside GStreamer to an average of 2500+ clients for over seven days is a pretty big milestone.

There are very few streams that actually manage to attain that number of clients anyway.
We found some "indenpendent" Microsoft-funded studies comparing Windows Media Server and RealServer, and on the same hardware for the same bitrate they manage 900 streams, and Real a few less. Ours is pulling a peak of 3700 at the moment, pushing over 40 Mbit/sec, using 5% CPU and some 5% of 1GB of memory. Pretty good, I'd say.

Of course, after making the screenshot I had to restart the streaming component, since I had made it log to a file through stdout with lots of debugging enabled, and about 98% of the 16 GB disk was taken up. And I couldn't find a way to close stdout for that process, so I was forced to stop the process to actually reclaim the diskspace. You live, you learn.

I *hate* doing multiple releases in short succession. Did a GStreamer 0.8.6 release yesterday, finally, after being stalled by unresponsiveness to revert threats, internet loss at work, and internet loss...