Steve Kemp writes about security issues with C programs . It seems obvious that if you are going to do something that is overly tricky (such as anything related to setuid programs) then you should have a good knowledge of what you are doing. Steve goes a little further and suggests that anyone who doesn’t know C should not package a C program.
In this debate I have more sympathy for Steve’s position. Security is one of the most important things in software that we develop, if you can’t develop secure software then IMHO you shouldn’t distribute any software. Although it should be noted that the two posts in question don’t directly conflict. Steve’s main point (your should know the code well to do something relevant to security) does not directly conflict with Andrew’s main point that a non-C coder can maintain the Debian packaging files and forward bug reports related to C code upstream.
In the more general case it’s often impossible to know all languages used in a project. It’s not uncommon for a single project to have core code written in C, a configuration file format (which is a programming language), a Makefile (GNU Make is a fairly complex interpreter), Autoconf/Automake (even more complex tools for creating complex Makefiles, and then some Perl or Python to manipulate input or output data. The SE Linux project has code in all those languages plus the M4 macro language. It seems obvious that in a large project the number of people who are capable of understanding all languages which are used is going to be a small sub-set of all Debian Developers. It also seems likely that someone who knows some of the languages really well may be capable of doing a better job than someone who has a passable knowledge of all of them.
For the vast majority of my work in Debian I have been a member of the upstream project in question (for Bonnie++, Postal, Portslave, Maildir-bulletin, and logtools I’m the sole upstream developer). Often I start maintaining a package with the intent of doing the minimum needed to keep it maintained in Debian but then end up doing upstream work, for example I briefly had write access to the CVS repository for pppd when I was maintaining it and I had write access to the KDE CVS repository when I was working on KDE packages (which incidentally was before I became an official DD).
When I first started working on the SE Linux project I aimed to merely package the code in question for Debian. I was not planning on spending seven years doing upstream work!
When I’m working on a project I spend my time working on the things that most need attention. That often means that I get diverted from Debian packaging bugs (which are often minor issues) to work on upstream bugs. In many ways my work practices make me a Debian user and upstream developer who also does Debian packaging rather than a dedicated DD. This of course does have a detrimental affect on the quality of my Debian packaging work – but overall I believe that it’s best for the users!
As an upstream developer who is focussed on Debian there are significant advantages in being a DD. I can immediately upload a new package to Unstable without any delay, and there is the potential to take over a related package (either be given the package or NMU) if it’s the best way to get around a roadblock. Another benefit is that in certain limited situations I can speak on behalf of Debian (in terms of packages I “own”). When it comes to upstream development of SE Linux I can make decisions about how things will be done in Debian and work with other upstream developers to ensure that cross-distribution compatibility works reasonably well.
It seems to me that a fairly ideal process for managing Debian development would have the people who are capable of the hard coding doing so and some people who haven’t got specific coding skills working on the packaging. I would be very interested in receiving patches related to the Debian packaging of the packages I “own” (in Debian it’s widely regarded that a man’s package is his castle) so that I can spend more of my time on the C coding. I’m not bothered about NMUs (a Non-Maintainer Upload – is when someone else uploads a new version of one of my packages to fix a bug). If anyone would like to NMU one of my packages they are welcome to do so as long as there is a suitable combination of bug urgency, simplicity of the fix, and lack of response from me. If someone wants to start NMUing my packages to fix bugs reported by the latest version of Lintian in Unstable (Lintian is the Debian tool to automatically check for packaging bugs) then that’s OK.
Of course there are a variety of other situations that DDs sometimes find themselves in. There have been situations of overtly hostile upstream developers. I try and avoid associating with people who have certain difficulties in interacting with others. If someone is going to change their license and try to back-date the change or create a license that makes it difficult to distribute modified versions of the code then I’m inclined to avoid even using the software, let alone being involved in developing it. This means that the software that I use in any serious way has reasonable people doing upstream development who welcome new people to join their work.