Ben Collins' Leadership Platform
This is my official announcement to nominate myself for the position of Debian Project Leader. I will go into some detail so that those that don't know me can get acquainted with my beliefs and insights as to how I would handle the Debian Project Leader Position if elected to do so. First off since most people want some personal information on nominees, I will start off with that. I can't agree more that for a position of this magnitude that the developers should know everything they can about the nominees. Name: Ben Collins Age: 26 Marital status: Married, one 2 year old (and yes, i do spend ample time with my family :) Current Position: UnixGroup Admin for the NASA Langley Research Center. Our group deals mainly with the administration and support of the Unix systems being used by the general users. I personally handle most of the development for this group and some higher end administration tasks. There are a few relevant projects that I am pursuing here (relevant to my abilities as they pertain to being the Debian Project Leader) that I will go into later in the email. My career in computers started at 16 with my first job, working as a desktop publisher in a house using Xerox 6085's (they sucked, took 15 minutes to boot and crashed more often than windows, wonder why they never made into the mass market?). From there I started building on the very basic programming skills I had acquired at home. By basic I really mean BASIC, on an Apple2e with a cassette tape and 2 - 5 1/4 drives. From there I have sought increasingly challenging positions, from ISP's to private shops. I will be forward and honest, I have no college education to speak of, outside of a few course I took while in the apprenticeship at Norfolk Naval Shipyard. The private reasons for this I wont go into. Everything I know has been self-taught, and while not degrading a good education, I will say that I believe a true wealth of knowledge is bread by a desire to learn, not by a quest to simply put a degree on the wall. I have a deep respect for any one that has the time and resources to achieve a higher level of education and expand their knowledge base and skills, no matter how they did it. My personal opinions on the current Debian Project: I have kept rather quiet during some of the heated discussions of a few key issues that are affecting Debian right now. There are several reasons for this. The main being that I was not versed well enough in all the aspects involved until recently. I am not one to make judgement and speak out about something that I don't feel I am knowledgeable enough to discuss. The other reason I will go into a little further down. Before I get into addressing my point of view on these issues I want to briefly expand on what I believe are the problems affecting the Debian project as it stands now. Mostly since I think they are far more important than what everyone is actually discussing. It seems to me that the group as a hole has lost sight of our main goals, and while everyone knows what they are, they are not being given the time and energy they need. These goals are stated in our Social Contract, and I think the most important one is #4 below |4.Our Priorities are Our Users and Free Software | | We will be guided by the needs of our users and the free-software |community. We will place their interests first in our priorities. We will |support the needs of our users for operation in many different kinds of |computing environment. We won't object to commercial software that is |intended to run on Debian systems, and we'll allow others to create |value-added distributions containing both Debian and commercial software, |without any fee from us. To support these goals, we will provide an |integrated system of high-quality, 100% free software, with no legal |restrictions that would prevent these kinds of use. My interpretation of this is the need to focus on providing a distribution that not only is free by definition of the DFSG, but also something that the users will use. Meaning it is as stable and bug free as possible. Right now, we have bugs in our packages that are very old, and our lack of attention to these is not being viewed very well. I took over one such package that was released into hamm with a grave bug that corrupted the super block on occasion. This to me is unacceptable. We have dozens of feature requests and policy proposals that are all very good ideas, but some how keep getting pushed to the side by discussions and topics that are actually outside of our scope as a group. I'm not trying to say that we the developers, nor the Debian Project as a whole should not involve ourselves in these outside topics, yet focus more on our original goals. My goal as Project Leader would be to refocus the Debian Project on these goals 1. Create a stable and bug free distribution for our users 2. Ensure that we follow our own guidelines concerning the "freeness" of the distribution I have several ideas on how to achieve these goals. First a slight restructure of the distribution handling. Our current setup is to always have a stable and unstable. Once unstable gets settled it becomes frozen and unstable forks off from that. This to me has shown to be slightly overwhelming as for as staying focused. Since there is now a new unstable, developers find themselves keeping up with the latest upstream releases and packaging new software while there remains a great deal of bugs in the frozen distribution. The debian-devel topics range way from license issues for software that currently has nothing to do with debian to a new proposal for DFSG. All of this, although important, is rather off topic from the immediate issues we have, "Get the product done". That product being the current distribution. Several proposals I would seek to pursue as Project Leader would be: 1) When unstable becomes frozen there would not be an unstable fork until deep freeze. This would help speed up the process of getting the "work in progress" out the door. I'm not at all saying would should make any short cuts, but the longer we sit in frozen the older the packages upstream version becomes, and the sooner it's out of date. With no unstable to immediately be concerned with, focus can remain on fixing any remaining bugs in frozen. 2) This is a possible idea, one which may not be received very well, but a variation of some sort would at least be helpful. Once there is a deep freeze, a group should be assigned to assess the bugs affecting the current frozen dist. There should be a set number in the group chosen at random from the general maintainers with one person that serves as the group leader (The Bug Group :). This group would initially contact the maintainers whose packages are affected by release critical bugs. The maintainer would have one week to respond with what he/she is currently doing to resolve the bug(s). If the maintainer does not respond, states that they are not working on the bugs, or does not have the ability to fix them, then the group would either take responsibility for the bugs, or try to find someone who will. This would ensure that all bugs are accounted for and taken care of in some sort of organised manner. Currently the only means in which to handle this same situation is by NMU, which has sometimes cause some riffs between the actual maintainer and a maintainer who thought they were helping. 2) Make dynamic lists available for very important discussions. This would allow important discussions, such as a major license issue or policy changes to be sectioned off from the general -devel discussion which so often brings focus away from pressing details that need to be taken care of first. The creator of the list would have the option of closing it when it's use was complete. From this I hope you have gathered that I am very much into details. While the big topics are important to each of us, as a group we need to stay more focused on our main goals and addressing these details that have a more direct impact on Debian. We can't very well be a respected organization in the free software community if we can't manage our internal affairs more effectively and with better resolution. Now on to some of my current projects. These mainly have to do with projects where I work: Solaris/Dpkg: I am currently developing a replacement package for our Cicero (in house proprietary system). Dpkg/dselect has been very optimal for handling this. I plan on pursuing a distribution of this (whether or not it is under Debian depends on a general consensus from others) ported version of dpkg including binaries/sources for use on Solaris with it. The entire system (obviously) revolves around dpkg/dselect for maintaining systems. Full use of the ftp/nfs methods are being utilized as well as autobuild of some packages. This is still under evaluation/development Linux at NASA: Myself and a few other Linux advocates here at NASA are pushing for the evaluation of Linux as a replacement for Windows, Mac OS, and Solaris as a desktop environment. We have just recently been given some recognition by upper management as to the feasibility of this. A pilot project is immanent in the near future. vMac: vMac, the Macintosh emulator. I am only slightly involved in helping with this project. I would be more active but CPU emulation is not my major coding experience. There are a few other private projects that I am working on, including some work with a small local group to help port DCE/DFS to Linux. This would be a more broad based project if not for OSF's strict license to not distribute source or binaries (source is available, but only they have the right to distribute it from their ftp). We plan to pursue OSF in making this source available under a more Open Source license. The Issues: I know most of you really want to now the nominees position on the two hottest issues right now. Qt/KDE: I don't use KDE, not because I don't like it or have anything against either KDE or Qt, but simply because I'm a console person, not much into X. Give me 10 vc's and I'm happy. My opinion on this is very simple, it is not Debian's responsibility to decide how good the QPL is or how the license needs to change, that's OSI and or SPI's (that's a whole other issue) concern. Our only concern over this as a group should be limited to "Does it meet our _current_ guidelines?", and if so who is going to package it. If not, then can it go into non-free/contrib. Said, done, that's it. I strongly encourage anyone who wants to push for a more compatible license, and as proponents of the free software ideals, I would hope everyone would. Just stay focused on the job at hand and keep those things in a more appropriate forum. DFSG2: I only briefly looked this over before I decided that after all the hoopla it needs to be dropped. I am more for a policy that is only specific on a few key points and more general on the less important ones. By key points I mean the ones we know are always going to be the same: "Is the source available?" "Are source and binaries distributable?" "Can we modify it and provide modified binaries and source?" I know the last one is a touchy point. I believe that source+patches is as good as patched source. As long as they can be distributed together. I don't think the policy should be very specific on trivial or controversial points such as the patch clause and BSD style advertising clauses. It has been my experience that the more specific you try to get about things in this manner, the more people will do to try and find loop holes. So if we make it more strict on the key points and general on the less important ones, then our work on deciding whether the packages meet the requirements will be easier and less prone to outside influences. I personally dislike the view that Debian is the central point for deciding whether a package is free or not. Our goals as a group do not encompass being opensource police. This has given us an image as being the bad guys who hold the fate of developer's software in their hands. We need to lose this image. While this may be a slight exaggeration on my part, we still need to lose this image. Closing: I hope my views are taken with some seriousness. Even if I am not elected as Project Leader, I think the points I have made will go along way to making Debian better. Thanks