Distributions

Maintainerless Debian?

The maintainer model is deeply ingrained into the culture of the free-software community; for any bit of code, there is usually a developer (or a small group of developers) charged with that code's maintenance. Good maintainers can help a project run smoothly, while poor maintainers can run things into the ground. What is to be done to save a project with the latter type of maintainer? Forking can be an option in some cases but, in many others, it's not a practical alternative. The Debian project is currently discussing its approach to bad maintainers — a discussion which has taken a surprising turn.

A maintainer of a package within the Debian project cannot be circumvented by forking — unless one wishes to fork the entire distribution, an enterprise which tends not to end well. So, when maintainer problems arise, they must be solved in some other way. A recent problem of this type, involving the GNU GLOBAL package, came to a head in October, and is still, as of this writing, unresolved. The slow progress of this case, which played out for years before being referred to Debian's technical committee (TC) in October, has led longtime Debian contributor Ian Jackson to start pushing for changes.

Jackson noted that the Debian constitution only provides one practical method for the removal of a nonperforming maintainer: the technical committee. But, he said, the committee has never, in the entire history of the Debian project, actually forced a maintainer out of their position. That, he said, indicates a problem:

Jackson expressed mystification as to why the TC — an institution he designed and served on for years — has proved unable to deal with maintainership problems. He went on to propose a couple of methods for improving the situation.

Making it easier to depose maintainers

His first proposal was to create a new mechanism, separate from the technical committee, to handle maintainership disputes. After an initial mediation step failed, a "jury" of ten randomly chosen Debian developers would hear the arguments and, with a majority vote, decide whether the package should be given to a new maintainer or not. The jury idea comes from a desire to get away from an appointed panel like the TC; as prominent members of the project, committee members, he said, are more likely to side with maintainers than with those who are complaining about them.

He quickly moved away from this idea, though, toward a scheme that, he hoped, would make it easier for the TC to make maintainership decisions. He posted a draft for a general resolution that would, if adopted, offer "advice" to the TC. That advice says that, in disputes over a package, the maintainer's position should be given no more weight than that of any other project contributor. Each opinion should be considered on its own merits, regardless of the "authority" of the person expressing any given opinion.

This draft resolution has not been all that well received. It was simultaneously seen as a no-op resolution that made no changes to how the TC was supposed to operate and a statement of a lack of confidence in the current committee's judgment. Two TC members (Philip Hands and Didier Raboud) said that they would be likely to resign from the committee if the resolution were to pass. Those TC members also seemed to feel that, by pursuing this initiative at this time, Jackson was trying to force the committee's hand in the GLOBAL dispute. As of this writing the discussion is ongoing, but it seems unlikely that Jackson's proposal will make it to a vote in anything resembling its current form.

No more maintainers?

Back at the beginning, Jackson proposed another option, seemingly as an exercise in extremes: abolish the concept of package maintainership entirely. He quickly dismissed that option, saying that it would lead to developers being "expected to play core wars in the archive" when they disagree over changes to a package. But some other developers took the idea more seriously.

Former project leader Stefano Zacchiroli remarked that abolishing maintainership was "the obviously right solution". The maintainer model, he said, gets in the way of effective collaborative development and should be done away with. He proposed moving to a "weak code ownership" model (without describing how that would work) along with tools that would make it easier to integrate changes made by multiple developers.

Russ Allbery agreed that the maintainership model is a part of the problem, partly because involuntary changes in maintainership will be, by their nature, confrontational events. Rather than codify how those changes should be done, he said, it would be better to just weaken the notion of maintainership in general. Again, though, he didn't get into the details of how a weaker maintainer model might work.

Jackson disagreed with this conclusion; he does not believe that things can work well in the absence of a maintainer who can make decisions. Others felt the same way; Adam Borowski suggested that, as a thought experiment, one could consider what would happen if the init-system choice were open to modification by any interested party. Rather than abolish the maintainer role, Jackson said, it would be better to just make maintainership changes easier and more routine. Some developers clearly see some appeal in the no-maintainer idea, though. Lars Wirzenius suggested the creation of a list that maintainers could join if they were amenable to having their packages taken over if they weren't keeping up with them. That list was subsequently created by Laura Arjona Reina and now had a handful of names on it.

Jackson, meanwhile, has moved on to a new idea: require group maintainership for all packages. The worst problems, he said, have always involved single-maintainer packages. If a formal team does not exist for a Debian package, then, perhaps, the entire project should be seen as the team and empowered to make changes. Like some other projects (the kernel, for example), Debian has encouraged more group maintainership of packages, but has not required it. Perhaps strengthening that encouragement is all the change that is really needed.

The Debian maintainer model has endured since the beginning of the project with few changes. It is too early to tell but, just maybe, this discussion will lead to larger changes in how Debian packages are maintained, with a subsequent reduction in maintainer-related problems. One should remember that this is Debian, though, so there is certain to be a fair amount of further discussion to get through first.

Comments (81 posted)

Distribution quotes of the week

— Ciaran McCreesh

— Guillem Jover (Thanks to Paul Wise)

Comments (3 posted)

Qubes 4.0 development status update

Marek Marczykowski-Górecki covers the status of Qubes 4.0 development. Topics include the rewrite of Qubes core management scripts, moving away from paravirtualization, Qubes Manager, a virtual machine administration API, and more.

Full Story (comments: none)

FESCo and Council elections - December 2016/January 2017

Nominations are open for Fedora Council and FESCo (Fedora Engineering Steering Committee). There are five seats open for FESCo and one seat open for the Council. Nominations close December 12.

Full Story (comments: none)

Distribution newsletters

• DistroWatch Weekly, Issue 690 (December 5)
• Lunar Linux weekly news (December 2)
• openSUSE news (December 1)
• openSUSE news (December 5)
• openSUSE Tumbleweed – Review of the Week (December 2)
• Ubuntu Weekly Newsletter (December 4)

Comments (none posted)

What's new in OpenStack in 2016: A look at the Newton release (Opensource.com)

Over at Opensource.com, Rich Bowen gives an overview of the changes in the OpenStack Newton release that was made in October. In it, he looks at each of sub-projects and highlights some of the changes for them that were in the release, which is also useful as a kind high-level guide to some of the various sub-projects and their roles. "With a product as large as OpenStack, summarizing what's new in a particular release is challenging. (See the full release notes for more details.) Each deployment of OpenStack might use a different combination of services and projects, and so will care about different updates. Added to that, the release notes for the various projects tend to be extremely technical in nature, and often don't do a great job of calling out the changes that will actually be noticed by either operators or users."

Comments (none posted)

Parrot Security Could Be Your Next Security Tool (Linux.com)

Linux.com takes a look at Parrot Security, a distribution that includes software for cryptography, cloud, anonymity, digital forensics, and programming. "Beyond the testing, auditing, and programming tools, what you’ll find in the Parrot distribution is a rock solid system. Parrot is based on Debian 9 and includes a custom hardened Linux 4.6 kernel. This is a rolling release upgrade distribution that uses the MATE desktop and the Lightdm display manager...all presented with custom icons and wallpapers. It’s pretty and it’s powerful."

Comments (none posted)