Cedric Gustin’s windows installer is a wonderful example of gtkmm‘s cross-platform ability. It installs the demo so you can see it working straight away, and it installs the documentation prominently so you can see how hard we’ve worked on it.
I have been trying to process bugs and patches this week without actually being able to apply anything. Ole Larson helped me out by applying some of them when they were ready. Hopefully more people will help me with this administrivia in the future. I really want to do more coding/designing instead of just tending bugzilla and mailing lists.
Martin Schulze released a first version of libsigc++ 2. It’s very different to the libsigc++ 1.2 that we use for gtkmm 2, and I suspect that it’s going to have some major API changes. I’m trying not to get too involved, but as far as I can tell it is more STL-like and <proj>boost-like, attempting to reuse as much as possible from both. The differences between boost’s signals and libsigc++ are not that clear to me yet, though there are some clues scattered throughout the archives.
GNOME 2.4 new modules
We really need more proposals/discussion of GEP 11 so that the release-team knows what people want.
There is some controversy over Galeon v. epiphany. I don’t use either at the moment, though I’m trying out epiphany from jhbuild. As I understand it they are both based on much the same base, so I can’t see how the decision for one or the other will make a huge difference, as long as the one that’s chosen fits in nicely with the release process.
I think the next round of new modules will find us discussing whether we need to define what is appropriate for the GNOME desktop release, rather than just whether its ready for inclusion. And if we decide to draw a line then we might need to define where that line is. I don’t think it’s good enough to just say we need to include equivalents of everything that’s bundled with Windows, because Windows is not driven by user’s needs, but by the wish to create and maintain monopolies. I don’t even see much need for a separate release set – the equivalent Windows Office release set (=”bundle”) only exists to maintain the monopoly.
But I’m not worried that new modules take effort away from incremental improvements in core desktop functionality, because new modules are mostly maintained and developed by new people.
My loathing of ClearCase increases daily. In addition to the points I made eariler, here are a couple more big disadvantages:
- Instead of working with temporary local copies and showing each other patches, each developer creates temporary branches for their work.
These branches tend to be used by more than one developer, and tend to contain more than one new feature or bugfix. These branches need to be merged later, which is difficult because their changes are not tightly focused.
Imagine GNOME’s CVS with 50 branches at any one time. Sometimes simpler really is easier.
- Branching is per-file, not per module or per project or per directory, and only already-changed files are branched.
So, every time you edit a file you need to issue a branch command. There are ways to do that automatically, but, because there are so many branches, that system can’t be trusted to figure things out properly.
Instead of just getting a branch of a module, people tend to get the latest stuff plus a few specified branched files from the module. Imagine the stable GNOME branch getting the latest wacky changes from the unstable branch just because nobody needed to change those files in the stable branch yet. Yes, that would be an unbuildable stable branch at the least.
This branching system is clearly a performance optimisation with awful effects on user functionality. I’d rather have a slower system (though CVS isn’t) that was actually usable.
I suspect that people believe the salesmen who tell them that ClearCase is a solution for complex branching situations. But in fact, ClearCase forces complex branching on simple systems, attempting to justify its own existence. I’m sure everyone would be far better of without it.