David Welton: Developer > Project, or Project > Developer(s)?
I've been fooling around with "git" lately - it's useful for local projects where I don't want to have to set up a remote server, and it also seems to be "the way the wind is blowing" - lots of open source projects are starting to use it, so I might as well familiarize myself with how it works.
The github service seems to be very popular at the moment, and it's not hard to see why. They've created a very useful service, and give it away completely free for open source use. That's a pretty good deal! It's also an easy to use site that's well integrated with git, so you can see lots of stuff graphically instead of fooling around with command line tools.
However, I have a nagging doubt. Github apparently bases everything around the developer. In other words, projects hosted there are mostly attached to a developer who 'owns' the project, rather than existing on their own. There are a few exceptions - there seems to be a 'rails' role account to manage Rails, rather than having it belong to, say, DHH, so it's not impossible to do something in a project-centric fashion, but it doesn't seem to be very common either.
What I'm wondering is what sort of effects this might have in the long term. Github, and git itself, make it very easy to 'fork' projects. Could, or will this lead to a situation where people don't try so hard to get their code in the 'official' branch? What happens when someone loses interest in their project? Sure, someone else can fork their repository, but if all the links were pointing to the first guy, because he was the main hacker on a project for X years, they're not going to switch overnight even if guy B takes over maintanance. And in the meantime, casual searchers might turn up the 'dead' branch, or simply be confused as to who's doing what. This could make things confusing for someone who just wants to check out some code and start using it.... trying to sort out various revisions and ancestry of a project could be quite discouraging.
At the Apache Software Foundation, on the other hand, people are obviously very important, but projects are the organizational unit that people get involved with, and a lot of emphasis is placed on not having one big benevolent dictator, but on having a group of people who make decisions and act as arbiters of what goes into the project. People can come and go as they please, but the project, and, importantly, the links to it, remain the same over time (barring any big, unforeseen blowups).
As far as I can tell, this is not a git problem, but something related to how github organizes their site. And, of course, it's possible that I have simply missed something due to my lack of knowledge of git, and not being more than superficially familiar with github. Even if I'm right, it shouldn't take that much effort for github to create a system where it's possible for multiple people to 'own' a project.
of Nova Scotia.
My past and future colleague Trevor Smedley just lost his appeal to the Supreme Court of Nova Scotia of his criminal conviction for having pet chickens. As the Supreme Court noted in Trevor J. Smedley and Her Majesty the Queen:
In June of 2005, I finished reading
*.myopenid.com - page security information.
Suppose you have a free software package that includes an OpenID login
form. Such forms are supposed to include a little OpenID logo
.
But as hard as you look, you can't find a license for the OpenID logo.
Though there seem to be
. It's freely licensed for use in
whatever.
Putting the little OpenID logo in the login form is a nice touch, it helps
spread awareness about OpenID and users learn to look for it. The fact that
free software packages can't include it weakens that. Having an alternative
logo that evokes the "real" logo and the concept of a login is better than
no logo at all. But it is also needlessly confusing.
I encourage the new OpenID board to reconsider plans for logo licensing,
and bear in mind that many free software packages can have native OpenID
support, and should be able to include a copy of the logo, without worrying
about it conflicting with their license, or not being free enough to be
included in a free software distribution.
For various reasons (which in the end boil down to lack of manpower), we are quite late in the process of packaging GNOME 2.24. (This is almost finished now, I ll keep you informed.) Which is why I may sound coming a bit late on noticing this one, but I was really speechless.
The problem: session management has flaws
Currently, a session manager uses XSMP (the X Session Management Protocol) to talk to applications. What it means is that for applications supporting this protocol, it is able to do more than simply starting and killing them: it will also remember their state, and offer them a way to shut down gracefully. However, XSMP is really a shitty protocol I won t explain why here, you will find tons of better explanations on the intarweb.
The gnome-session developers, being quite aware of this issue, did what anyone interested enough would have done: they designed a new protocol, based on D-Bus, and implemented it. The new protocol is not considered stable yet, but it is simple, efficient and above all, reliable that s a giant leap forward. For this reason, I was very excited to see what gnome-session 2.24 would look like, since it brings major cleanups in the code.
The solution: remove session management!
When I first started it, it did not restore my saved session. I simply supposed that the format of the saved session had changed, and that writing a conversion tool would be in order. Wrong. Let s bring the session preferences:


The Debian Python Modules Team is 
Opensync updates
Some time ago, Opensync-0.38 got