LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
DevelopmentPython's Mercurial migrationBig projects switching to a distributed version control system (DVCS) is pretty common occurrence these days, but it is not always easy or straightforward. Guido van Rossum first announced that Python would move to Mercurial (aka Hg) in March 2009, but the project is still using Subversion (aka svn) more than a year later. While the conversion is still in the works, the schedule for the switch is still up in the air. Recent discussions have pushed it back until sometime later this year, or possibly early next year. There appear to be a number of different things that got in the way of adopting Hg, but clearly the biggest has been problems with how it handled end-of-line (EOL) conventions. As described by Brett Cannon, the Python folks were under the impression that Hg had ways to handle EOL conventions that would make it act like Subversion's svn:eol setting. When that turned not to be the case, it set the conversion back. Efforts were made to design a Mercurial extension—which is written in Python after all—that would "do the right thing" for line-endings on Windows, Linux, and Mac OS X, while not making a mess of binary files. That culminated in an EOL Extension that was released as part of Mercurial 1.5.4 in June of this year. Some of the time it took to get from a design to a working, released extension can be blamed on Mercurial hacker Martin Geisler's PhD work, which is something of a recurring theme. Cannon, who did much of the work in evaluating Git, Bazaar, and Mercurial before Python chose a DVCS, was delayed shortly after the decision by work on his PhD. That led Dirkjan Ochtman to step in and write Python Enhancement Proposal (PEP) 385, which describes the migration path from svn to Hg. Now Ochtman is unavailable to work on the transition until some time in August due to work on his Master's thesis. It is a tad amusing to note that projects might be best-served by contributors who either already have advanced degrees or have decided not to pursue them, but that, of course, is a trivialization. There does seem to be a lack of people interested in making the transition, at least in any hurried fashion, or perhaps there is a lack of pressure to make the change from the development community side. In some ways, it would seem that Mercurial has moved into the "nice to have, but not required" bucket, at least for now. The timing of making a change to a different VCS can be tricky. There are lots of dependencies for ongoing release efforts and the like. The unavailability of Cannon and Ochtman led Martin v. Löwis to put out a call for volunteers. "If nobody volunteers, I propose that we release 3.2 from Subversion, and reconsider Mercurial migration next year." The first alpha of 3.2 is scheduled for early August, while the final release is planned for January of next year. Waiting until after 3.2 would likely mean that the Hg transition will have taken Python around two years. Some folks did volunteer, and there was talk of releasing the first 3.2 alpha from svn, with later releases coming out of Hg, but no firm decision seems to have been made. There is also some resistance to phasing out svn. Anatoly Techtonik is concerned about moving away:
I would put [an] accent on keeping [a] mirror of Subversion as [an] easy way to
contribute for those who are not yet ready for DVCS. Subversion also
provides greater interoperability. Assuming that any modern DVCS tool
may act as Subversion client, we will gain more contributors if we
won't try to force people use Python and Mercurial.
But Stephen J. Turnbull disagrees with that assessment. The transition was planned because it would make developers' lives easier:
It also is clearly going to make more effective workflows for many of
the core developers. AFAIK, assuming the issues that have been raised
in PEP 385 and the tracker are resolved, other core developers agree
that the transition will have an acceptably low impact on them.
Turnbull notes that a "new proponent and supporting cast" are actively being sought for the transition. In addition, he is optimistic about the timing:
There is no reason at this point to suppose the transition can't be
complete by the end of summer. However, as always, the devil is in
the details, and one of them may be a showstopper. We'll just have to
see about that.
At this point, it is in the hands of the Python team. Before the completion of the EOL Extension, it was relatively easy to find other things to work on while awaiting the extension. Now that the ball is firmly back in their court, the importance of Mercurial to the Python hackers will likely become more clear. If the team is unable to find the time to make that switch, it is by no means the end of the world, it is just an indicator that many are fairly comfortable with their current workflow. That may be a little surprising to some, but each project has its own way of working and some are more suited to a DVCS development style than others. Python has always been fairly rigorous in its processes, with PEPs for all major—and many minor—decisions, and a pretty conservative development style. Moving unhurriedly to switch to Mercurial may fit in with that just fine.
Brief items Quote of the week
Open source licenses do take part into a trust
relationship -- however it is trust between corporate entities with
too many lawyers who wouldn't trust the open source development
communities otherwise. Their worries are mainly about people
contributing tainted material to open source projects which then later
can be used to place pressure on deep pockets (see the SCO UNIX suit
for example).
-- Guido van Rossum
A secondary reasoning for some open source licenses might be to prevent others from running off with the good stuff and selling it for profit. The GPL is big on that, but it's never motivated me with Python (hence the tenuous relationship at best with the FSF and GPL software).
App Inventor for AndroidGoogle has introduced App Inventor for Android. It's still in closed beta, but you can request access through the website. "To use App Inventor, you do not need to be a developer. App Inventor requires NO programming knowledge. This is because instead of writing code, you visually design the way the app looks and use blocks to specify the app's behavior." (Thanks to Keith Edmunds)
Campsite 3.4Campsite 3.4 has been released. "Campsite, the free, open source, multilingual content management system for news websites has been released in version 3.4 and features over fifty bug fixes and improvements. Building upon the stability and security improvements in June's 3.3.6 release, this latest version includes dramatically improved search options (both internally and for external search engines), a clean up of the graphical interface (new-look icons and admin interface) and easier installation." LWN looked at Campsite in March 2009.
Announcing FOSSology 1.2.0 ReleaseThe FOSSology Project has announced the release of FOSSology 1.2.0. "FOSSology is a Free Open Source Software (FOSS) project built around an open and modular architecture for analyzing software. Existing modules include license analysis, meta data extraction, Copyright/URL/email scanner, RPM and Debian package analysis, and MIME type identification. This open source software tool analyzes a given set of software packages, and reports items such as the software licenses used by these packages."
GNOME 2.31.5 unstable releaseThe GNOME 2.31.5 development release is available. "2.31.5 is out and features a lot of modules ported to GTK+ 3; oh sure there are bugs, and disabled features, but 1) this is temporary, and 2) this should be seen as an opportunity for sleepless nights in The Hague. Isn't it a wonderful world?"
GNOME Shell 2.31.5 releasedGNOME Shell 2.31.5 is now available. "Note: This release changes the GTK+ dependency to the GTK+ 3.0 development series. Mutter must now be built with the --with-gtk=3.0 option to work correctly with GNOME Shell."
GTK+ 2.21.5 releasedGTK+ 2.21.5 is the latest stable release of GTK+. "GTK+ 2.22 is planned to be the last stable GTK+ 2.x release, to be released in parallel with GTK+ 3. It will not receive major feature work beyond API additions that are required to facilitate porting to GTK+ 3."
GTK+ 2.90.5 releasedGTK+ 2.90.5, a development release leading toward 3.0, is now available. "GTK+ 3 will be parallel installable with GTK+ 2.x, and this release has been prepared to test this by renaming all .pc files, libraries, include paths, and so forth, to include a '3.0' component."
KDE SC 4.5 RC2 OutKDE has announced the second release candidate of the upcoming KDE Software Compilation 4.5. "The final version will be available in August 2010 and this RC is intended for testers and early adopters who can help by finding and reporting bugs. It will also interest those who want an early look at what is coming to their desktops and netbooks this summer."
libguestfs 1.4.0libguestfs 1.4.0 is a major new release of libguestfs. "libguestfs is a library and a set of tools for accessing and modifying disk images and virtual machines. You can use this for viewing and editing files inside guests, scripting changes to VMs, monitoring disk used/free statistics, P2V, V2V, performing partial backups, cloning VMs, and much more."
SeaMonkey 2.1 Alpha 2SeaMonkey 2.1 Alpha 2 is available for testing. "Please note that this pre-release version is still intended for developers and testers only. As always, we appreciate any feedback you may have and encourage users to help us by filing bugs."
Newsletters and articles This week's newsletters
Page editor: Rebecca Sobol |
|||||||||||||