LWN.net Weekly Edition for June 18, 2009

FreedomHEC Taipei 2009

FreedomHEC (Freedom Hardware Engineer's Conference) Taipei was held June 10 and 11 in, unsurprisingly, Taipei, Taiwan. The event, sponsored by the governmental Institute for Information Industry, followed the huge Computex conference in the hope of attracting hardware developers who are interested in supporting Linux. Your editor, who had the honor of being invited to speak at FreedomHEC Taipei, would assert that the goal was achieved; over 200 developers showed up for two days of technical talk about the Linux kernel and the best ways to contribute to it.

Your editor arrived prepared with the talks which have become his stock in trade in recent years. Of the two talks, the most fun was certainly had on the second day, when the topic was how to work with the kernel development process. Anybody who has given talks in eastern Asia knows that getting audience members to participate and ask questions is not an easy task. But the FreedomHEC audience was (after just a bit of encouragement) full of questions and interested in having a discussion which could have extended far beyond the allotted time. There was, beyond doubt, a great deal of interest in working more closely with the wider development community. Your editor offers his apologies to Greg Kroah-Hartman, who had to wait rather longer than was proper for the lectern to become free.

Greg's talks were quite well received; his 2.5-hour tutorial on writing a device driver had the undivided attention of the full audience at the end of a long day. Peter Stuge gave a talk on CoreBoot (once known as LinuxBIOS). Harald Welte's talk on GPL compliance was also well received; the audience seemed much more interested in how to work with the GPL than how to get around it.

FreedomHEC was not dominated by outside speakers, though. Developers Jim Huang and Matt Hsu from 0xlab, who were clearly having a great time, discussed their work with the Qi bootloader. Fred Chien covered a number of hacks ("dirty" and otherwise) to make Linux boot more quickly. Joseph Chan of VIA discussed the various challenges he encountered while working to merge a driver into the mainline. They all appeared to be interesting talks; unfortunately for LWN readers, they were also all in Chinese, so your editor's reporting is necessarily spotty.

The Chinese-language talk which looked like the most fun was a high-energy session led by Chen Ing Hau, perhaps best known as the (since repentant) author of the Chernobyl worm. CIH (as he was referred to there) went deeply into the process of reverse engineering the appropriate register settings to drive a wireless network adapter. The talk proceeded with all the ups and downs of a good detective story, with the culprit, naturally, being caught at the end.

There is a certain missionary aspect to attending this kind of event. Harald Welte described it this way:

The group of industries often referred to as "Taiwan, Inc." has often shown a lack of understanding of how our community operates and, seemingly, a lack of interest in being a part of it. So FreedomHEC looks like an attempt to bring the Good Word to that part of the world. Certainly some people need to hear it. But your editor is not sure that those people were at this conference. What went down at FreedomHEC was hackers talking to other hackers, and they were having quite a good time in the process. It looked an awful lot like a Linux-oriented development conference.

Your editor has spoken in parts of the world where people seem to view software development as just another job, and not a particularly inspiring one at that. But Taiwan was not one of them. There are a lot of people working on interesting projects, and they show that excited, creative spark that suggests good things are on the way. They look like they want to be a bigger part of our community.

To that end, events which present information on how to work with the global community are helpful. But one thing is worth pondering on. When asked if they felt that their managers understood the importance of and value in working with the free software community, very few members of the audience raised their hands. Taiwanese developers, it seems, don't need much help in this area, but their bosses do. This is natural; why should Taiwanese managers be more enlightened than their counterparts elsewhere in the world? To solve this problem, we are going to have to engage in education at higher corporate levels. Management can be won over with sufficient persistence and energy - most of the time.

Events like FreedomHEC are helpful in this regard; they can give the local development community encouragement and the tools needed to carry the message to their companies. And there is always value in gatherings where developers can meet and talk about things over beer. FreedomHEC Taipei 2009 was an exemplary event of its kind; its organizers (led by Chao Lung Huang) deserve strong congratulations. Your jet-lagged editor is happy to have gone.

Comments (6 posted)

Python and ipaddr.py

On June 4th, the Python developers removed a recently-added module, ipaddr.py, from the upcoming Python 3.1 release. At the time 3.1 was still in release candidate status — rc1 had been released on May 30th — and the usual policy for Python's release candidates is that only bug fixes are permitted. Adding or removing an entire feature is normally forbidden. Why did the Python developers change their minds? The story behind the decision shows a possible communication problem as projects grow and the number of available channels increases.

The story begins in September 2008 with Issue 3959 being filed in Python's bug tracker by Guido van Rossum, recording a suggestion that ipaddr.py be added to the standard library. After the issue was created a few messages were exchanged discussing the authors' willingness to move the master copy into Python's SVN repository, and then the issue fell silent. (The Python developers were probably distracted by preparations for the final release of Python 2.6 that occurred a week later.)

ipaddr.py parses IPv4 numeric addresses such as 172.16.40.35 and address ranges such as 192.168.0.0/16, as well as the corresponding IPv6 formats. Users can create IPv4 and IPv6 address ranges, remove a subset of addresses from a range, check whether a given address is included in a range, and compare addresses and networks for equivalence. The module had been used internally at Google for some time and bears a copyright statement dated 2007; the first open-source release was in September 2008 as the ipaddr-py project on Google Code.

After the initial messages, it was some months before discussion revived. Some commenters noted similar libraries such as netaddr and IPy. After some further discussion, in February 2009 Martin von Löwis wrote "Yes, I think it can be integrated now.". There was another delay of a few months before the code was actually committed, but on May 1st Gregory P. Smith committed ipaddr.py to the Python 2.7 branch in SVN revision 72173, also merging the change to the Python 3.1 branch.

But, in June Clay McClure argued against the inclusion of ipaddr.py on the bug tracker:

McClure's objection stems from ipaddr.py using the same class to represent both individual IP addresses and network address ranges. Network ranges are usually represented as a starting address and the number of bits that are the fixed portion of addresses within the range. 192.168.0.0/16 is an IPv4 range, for example; the first 16 bits of the address (the 192.168. portion) are fixed and the remaining bits can vary. ipaddr.py represents a IPv4 host's address, which is a specific 32-bit value, as the address plus a /32 value. Treating addresses in this way lets a single class be used to represent either a single address or a range. (IPv6 uses 128-bit addresses and hex notation, but the principles are the same.) The debate is about whether this representation is reasonable.

    >>> from ipaddr import *
    >>> a1 = IPv4('127.0.0.1')
    >>> a1  
    IPv4('127.0.0.1/32')
    >>> a2 = IPv4('127.0.0.1/32')
    >>> a1 == a2  
    True

Core contributor Raymond Hettinger brought the discussion to the attention of the python-dev mailing list:

van Rossum initially thought the reported flaws were not so significant:

The resulting discussion thread received dozens of messages, and a consensus formed that the module's interface needed some reworking. Eventually van Rossum agreed it should just be removed from 3.1:

To a first approximation, this is just business as usual for any project: a feature was proposed, the code got committed, but later the developers collectively changed their minds and backed out the change from the 3.1 branch. The impact is minimal, because the code was only in one release tarball, a short-lived 3.1rc1 release candidate that was replaced two weeks later by 3.1rc2. The module remains in the 2.7 branch for now, but 2.7's release is months away, leaving plenty of time to remove the module or to rework the module's API and include it in Python 3.2. A Python Enhancement Proposal may be written defining an IP-address module.

However, the incident brought some process issues to attention, and the discussion divided into three major strands.

Mailing list vs. bug tracker

Part of the reason for the late reversal was that objections were being made through commenting on a particular issue in the bug tracker. A January thread on python-dev didn't cause much discussion, and the disagreement on the issue wasn't noticed by 3.1 release manager Benjamin Peterson.

Glyph Lefkowitz of the Twisted project detailed the procedures for the Twisted project, where all discussions are in the bug tracker:

Bug trackers encourage focused conversations between people with an interest in a bug or patch, preventing an unmanageably busy mailing list. But there's a cost; this increased focus makes it harder to obtain a general view, or to notice that one issue is particularly serious or important. One suggested improvement was adding the python-dev mailing list to the Roundup bug tracker as a user. Roundup creates a 'nosy list' for each issue; users on the nosy list receive e-mail notifications of new comments or modifications to the issue. If python-dev existed as a Roundup user, adding python-dev to the nosy list for an issue would send a clear signal to other core developers.

Unclear decision-making

The developers of Apache have a formal voting process that's specified in careful detail. Python follows some of Apache's conventions, such as using +1 and -1 to indicate support or opposition, but these aren't votes, merely polls showing general opinions. For example, under Apache's rules a -1 vote is a veto and must be accompanied by a technical justification, but many changes to Python have received -1 votes and still been accepted.

In Lefkowitz's posting cited earlier, he also noted that there is a vocabulary for describing the next action to take on a patch:

Selecting additions to the standard library

A number of different modules for representing IP addresses have been written, including ipaddr.py. David P. D. Moss, author of the netaddr module, drew up a list of IP-address modules that contains 12 projects, the oldest dating back to 2000. ipaddr.py is comparatively new, having been publicly released in September 2008; so why was it chosen?

To some degree it's just a question of luck and timing: the suggestion to add ipaddr.py was just the first one to be recorded in the bug tracker, but a policy of "whoever asks first" does not ensure that the best module is chosen for addition.

What selection process would work better? Barry Warsaw thought usage information from the package index could be helpful, suggesting "It would be really nice if say the Cheeseshop had a voting feature". The Cheeseshop is another name for Python's package index. Neil Schemenauer further noted Debian's popularity-contest script, which reports the packages installed on a system to a central server.

van Rossum didn't like the idea at all, saying "Whoa. Are you all suddenly trying to turn Python into a democracy? I'm outta here if that ever happens (even if I were voted BDFL by a majority :-).".

But van Rossum had previously noted that he wasn't a likely user of the module and could not really assess the suitability of the module's interface. In the absence of a strong opinion based on technical grounds, how should such decisions be made? Going by popularity seems to be as reasonable a way to choose as any other. Of course, the sheer number of modules may imply that this is an area where people are finicky about the approach taken, and perhaps the standard library needn't take a position on it.

Conclusion

In order to make progress, open-source projects, like people, must continuously decide which action to take next. Much has been written about personal time management, including books such as Stephen R. Covey's 7 Habits of Effective People and David Allen's Getting Things Done. Often the key to improvement is taking a careful inventory of tasks and organizing this inventory to minimize effort spent figuring out what to do and maximize effort spent actually implementing or fixing.

As free software projects spread out across multiple communication channels — a set of mailing lists, the bug tracker, SourceForge forums, personal weblogs, IRC conversations, Twitter, and soon enough new technologies such as Google Wave — their developers will face many of the same issues at a collective level. Taking inventory is relatively easy because there are many tools for doing so: version-control systems, bug trackers, and mailing list archives. But how do you ensure that the right people are paying attention?

Comments (10 posted)

openSUSE readies for community contributions

In the past, only Novell employees could contribute code to Factory, the development version of openSUSE. However, this policy has started to change in the last few weeks, ever since openSUSE board member Henne Vogelsang announced sweeping changes to how Factory operates. These changes include a reorganization of Factory into specialized teams, and permitting community members to contribute code directly — a move that has the distribution rethinking its security measures as well.

The opening of the distribution to community contributions is only one of the changes to the distribution in recent years to make it more open (and, perhaps, to silence accusations that openSUSE is controlled entirely by Novell). These changes have included the appointment of a community manager, the transition to an elected board, and increasing access to the project through such features as openFATE, the feature-tracking service, and the openSUSE Build Service.

Joe "Zonker" Brockmeier, openSUSE community manager, explained that the changes were made "to continue enabling the contributor community outside of Novell and make it easier for people who are doing work on openSUSE to participate directly. We want to enable and encourage contributions from outside of Novell, and continue to make openSUSE a more independent project."

Similarly, Vogelsang said that most of the requirements for open contribution have been gradually coming into place over the last year or so, but "What we did not have was the possibility to take responsibility. That's why we changed our policies now so people can not only contribute but also take responsibility."

Vogelsang is referring to the division of Factory into working teams for patches and packaging. To a limited extent, this division already exists. Informally, teams for major areas such as GNOME, KDE, and Education already have their own web pages and ways of working, and exist semi-autonomously within openSUSE.

The difference now, as Vogelsang said in his initial announcement is that "What we want now is to use this model for every aspect of the distribution, not only the big parts where this comes naturally."

To this end, Vogelsang and the current package maintainers have developed a preliminary list of over 85 possible teams. These teams are listed as having responsibility for maintaining packages and reviewing contributions for as few as three or four packages, or for dozens, depending on the area that they cover.

In the announcement, Vogelsang wrote that, "As our goal is to make it possible for everybody to work on the distribution, we will simply allow the topic groups to organize themselves. We think that there is not the one and only way such a group of maintainers can work together, but it depends on the involved people and also on the topic . . . . So to transition we will throw together the people that are currently maintainers of packages and help them work out how to best collaborate with each other and [with] new people."

What is not immediately clear (at least, not without a lot of web searches) is which of the proposed teams are active and which are still largely hypothetical. But, for now, the distribution will be working with existing maintainers, and adding Novell employees to fill in where volunteers are lacking.

Policy vs. procedure

A particular area of concern is security, as Marcus Meissner pointed out. As Meissner explained, "Every single package can disturb / destroy the integrity of the whole openSUSE distribution (As in 'install trojans, rootkits, etc.')." Even if a package is not installed by default, Meissner warned, it could still be installed by the automatic resolution of dependencies.

Under these circumstances, Meissner stresses that the role of packagers needs to change along with openSUSE's policies. In particular, packagers will need to review all submissions with extreme caution, checking for malicious code and maintaining a workable set of project and package submission. They will need to decide how much they trust each contributor, and, at the same time, watch for email addresses that spoof those of trusted contributors, or cracked openSUSE accounts.

"Always keep such a thing in the back of your head and watch for behavioural changes", Meissner advised. "Trust your gut feeling and check twice if in doubt!"

Meissner's warning sparked a brief discussion on how the submission process could be made more secure. Karsten König suggested that the use of MD5 of SHA-1 hashes become mandatory in all submitted tarballs and within package scripts, so that reviewing the integrity of submissions would become easier. König also proposed that all hashes for packages be available on a web interface. Such changes in procedure would probably be resisted by some maintainers, but Vincent Untz wrote that they might be accepted more easily if they were made voluntary for one release cycle, then mandatory for the next.

Allowing community changes is a reversal of existing policy that can only add to the credibility of openSUSE as a free software project. However, as the security issue shows, changes in policy can require rethinking of procedures as well. While no final decision has been announced about how to handle the security issues created by the policy change, the need for some guidelines is inevitable. Nor are policies for acceptable structures or standards likely to be far behind, as other community distributions have discovered in the past. The devil, openSUSE is finding out, is not in the policies so much as in thrashing out the details.

Comments (none posted)