Have you wanted to play around with bzr but had nowhere to share your branches? You can now publish them through Launchpad. David Allouche provides the details.
In short, you can upload branches to sftp://bazaar.launchpad.net/, and they will be published on http://bazaar.launchpad.net/.
Recently one of the Gnome Foundation directors quit, and there has been a proposal to expand the board by 2 members. In both cases, the proposed new members have been taken from the list of candidates who did not get seats in the last election from highest vote getter down.
While at first this sounds sensible, the voting system we use doesn’t provide a way of finding out who would have been selected for the board if a particular candidate was removed from the ballot.
The current voting system gives each foundation member N votes to assign to N candidates (where N is the number of seats on the board). The votes are then tallied for each candidate, and the N candidates with the most votes get the seats.
If we look at last year’s results, there were 119 people who voted for Luis. If Luis had not been a candidate, then those 119 people would have used that vote to pick other candidates. The difference in the number of votes received by Vincent (the board member receiving the least votes) and Quim (the unsuccessful candidate with the most votes) was just 16, so those extra 119 votes could easily have affected the ordering of the remaining candidates.
Furthermore, if the election was for nine seats rather than seven then each foundation member would have had an additional two votes to cast.
This particular problem would not be an issue with a preferential voting system where each foundation member lists all the candidates in their order of preference. If a board member drops out, it is trivial to recalculate the results with that candidate removed: the relative orderings of the other candidates on the ballot are preserved. It is also possible to calculate the results for a larger number of seats.
Of course, all the candidates from the last election would make great board members so it isn’t so much of an issue in this case, but it might be worth considering for next time.
The progress on JHBuild has continued (although I haven’t done much in the last week or so). Frederic Peters of JhAutobuild fame now has a CVS account to maintain the client portion of that project in tree.
Perl Modules (#342638)
One of the other things that Frederic has been working on is support for building Perl modules (which use a Makefile.PL instead of a configure script). His initial patchworked fine for tarballs, but by switching over to the new generic version control code in jhbuild it was possible to support Perl modules maintained in any of the supported version control systems without extra effort.
Speed Up Builds (#313997)
One of the other suggestions for jhbuild that came up a while ago was to make it “eleventy billion times faster”. In essence, adding a mode where it would only rebuild modules that had changed. While the idea has merrit, the proposed implementation had some problems (it used the output of “cvs update” to decide whether things had changed).
I’d like to get something like this implemented, preferably with three possible behaviours:
The second option is obviously the fastest, and is a useful option for collections of modules that should be API stable. The third option is essentially an optimisation of the first option. For both the second and third option, it is necessary to be able to tell if the code in a module has been updated. The easiest way to do this is to record an identifier for the tree state, and the identifier is different after an update.
The identifier should be cheap to calculate too, so will probably be dependent on the underlying version control system:
On a successful build, the ID for the tree would be recorded. On subsequent builds, the ID gets recalculated after updating the tree. The new and old IDs are then used to decide on whether to build the module or not, according to the chosen policy.