I'm going to write this in a Q/A format, mainly because these are commonly asked questions, so I wanted to answer them in a direct way. Q. Who are you? A. My name is Ben Collins. I am a husband of 6 years, and father to 4 year and 6 month old boys. I'm 28 years old and currently working for a company called Winstar Communications (have to see about a bonus for plugging them in this) as a "Directory Services Engineer" (official title, my actual job is much more sparse in nature). I like golf (which I don't get a change to play as much as I would like), bowling, paintball (this is my latest sport, I love paintball, see http://marcus.debian.net/trr/) and spending time with my family. Most of the time on the weekends I am either working on my vehicles, doing yardwork, or playing one of the afore mentioned sports. Q. How did you get started in computers? A. I've been working with computers since I was about 12, with an Apple ][e, programming in BASIC. From there I moved to a Mac+, and went on to doing desktop publishing at 16. Q. How did you get started with Open Source projects? A. Basically I started out trying to learn some things. I was at the time (more than 4 years ago now) a web designer, deeply in love with MacOS, and terribly stuck in a Windows world. I wanted to be a sysadmin (I hate designing web sites). I initially tried a copy of Solaris I got from the office, on my home pentium. It was terrible. Trying to get to a point where all the things I wanted (perl, apache, bash, gcc, etc..) were at my command was a PITA to say the least. I moved on to FreeBSD, but it simply was not what I wanted in a desktop/devel/webserver. I tried three flavors of Linux (Redhat, Slackware and then Debian) before I settled on what was what I felt, the better of the three. So much software in my greedy little hands, and all for free, I felt like I was stealing it! :) I worked a lot on my own time to teach myself this great new stuff, including basic administration, development in the various languages, security concepts, etc.. I was always trying something new and having to reinstall my system because of it :) Now, here I am, in a place where all of the things I like to do can benefit others. Q. What do you do for Debian? A. Right now I work mostly with two things. One being the sparc port. I handle all of the buildd functions (vore.debian.org) and follow up on (if not fix) problems related to the sparc port in general. This includes doing boot-floppies, handling sparc specific bug reports, debugging, and communicating with upstream sparc porters (David Miller, Jakub Jelenik, etc..). This is a day-to-day operation. My second time consuming effort is the GNU C library (glibc). I took over maintainence of this package about 6 months ago and have since worked to fix as many of the bugs as possible and make it as stable as possible. The glibc package is unique in that it requires close contact with all of the port maintainers. Right now I build glibc for i386, powerpc, sparc and (recently) mips. This has helped to keep these ports in close sync with the glibc upstream. The other port maintainers contact me regularly for port specific patches. Almost all of the work I do on glibc is sent upstream. Since taking over the package, over a dozen upstream bugs have been fixed and lots of documentation updates have been merged from Debian bug reports. Outside of these two things I also work on packages such as PAM, Cfengine, shadow (passwd, login), OpenLDAP, SILO (sparc boot loader) and Egcs64 (the sparc64 kernel compiler). Q. What makes you think you can be a good DPL? A. Well, a good DPL is measured in many ways. I don't think one single person can be good in all the ways that everyone expects. I can only hope to be good in the areas that most people consider important. One of these areas is visibility. We all know that the DPL is a figure head for Debian. They get invited to all the neat Linux expos. Quite honestly, being a father/husband, I may not be able to travel as much as recent DPL's, are as much as any of the other candidates (I'm unaware of their specific situation regarding this). I am more than willing to spend as much time as possible, however, keeping contact with outside factions who are interested in Debian workings, and keeping our developers informed of such factions. I will travel to as many Linux related events as humanly possible for a man in my position. The other areas include some leadership skills. I think this breaks down into two areas; reaction and proactive. The DPL needs to handle things in two different ways. It's not very often that we have problems so large in Debian that the DPL needs to step in, but when we do, it's obviously something that needs to be handled quickly and with the least amount of disruption. Being proactive, the DPL needs to forsee issues affecting Debian's growth, and make attempts to initiate policies to handle them. I like to think I am able in both of these respects. Of course, only time will give the answer. Q. What specific things will you do if elected? A. That's hard to respond to. There are lots of things I would like to do. However, just the nature of Debian precludes most of them from being done, either because of time constraints in a volunteer project, or because of lack of real delegation power within Debian (you can delegate, but you can't gurantee anything will actually get done). What I will concentrate on are things I would like to see happen. Whether they get done, is generally based on acceptance by the developers. Let's face it, it would be stupid of me, or any candidate, to suggest that their ideas are the end all solution to anything. No one can force Debian as a whole to do anything they don't want to do, and it would be silly to try, even if that thing might bring peace to the world or end starvation. Now, my specific goals (as specific as they can be, given that I have not discussed them in much detail, and so are not layed in stone) are: 1. More structure to Debian as a whole. This can include many different aspects of the project, one of which is Developer status within the project. I'm a firm believer that we need more layers of what a developer is. Yes, this is similar in spirit to the senior developer flame war, but think about this before deciding to start another one. Now there are a lot of good things about how we are now. We all breathe the same air, we all have the same permissions to upload packages, we all have just as much right to screw up the archive as anyone else. In there lies the problem. Maintainer count is on the rise all the time. It may not seem to be a problem now, but increasing administrative and security work to keep this increase on a good footing is not going to remain easy (well, it isn't easy now). Stopping developer entrance all together is not an alternative either. Some may argue that this makes Debian less "open". Well, I don't think Debian is closed at all, given that we allow anyone to access our BTS, communicate with our developers and test all the latest software that we make via the archive or CVS. We also have one of the most extensive mailing list servers around. Now I know this isn't the same as having ones own packages, and that sponsorship is not turning out to be the godsend that we had hoped. However, allowing more levels of maintainship will likely make it easier for people to contribute. Let's take a look. Right now we rely heavily on the the new maintainer being trustworthy, and reliable. This puts a heavy strain on the people that police this process. They are tasked with making sure no one gets into Debian that may potentially destroy the very thing we have worked so hard on. It would only take one really evil person to turn our archive into a malicious trojan horse. No, they wont go unnoticed for long, but long enough that we could lose a lot of users, and respect. So, my intention is to find a way to allow new maintainers in, with less permissions than we give now, and less hassle ("got a gpg key?", "got a picture?", "ok, you're on the 'new meat' crew"). This means people who want to get their feet wet, can, and without them worrying about breaking things, and without us worrying about them accidentally messing up, or intentionally destroying. The trick here is to make this as easy as possible to administrate, and set enough control in place to actually enforce it. I haven't really gotten all of that hardcoded yet, so I'll eventually look to all of you for suggestions (not flames, suggestions). 2. The rising bug count. So what you say? We have more packages, so we have to expect more bugs you say? We have more users, which means more bugs get uncovered you say? We have stricter policies, so it's harder to make things perfect you say? Bullshit, I say. Bug count is increasing faster than it should. Not because of any of these things, but because the maintainers are either MIA, don't care, or can't fix the issue. We have lots of packages that are no longer maintained by anyone. They serve no other purpose other than to collect dust and cruft the archive. How do we find these packages? How do we get rid of the bugs? Well, my best guess is a more active and powerful QA team. A group of folks that can take on the bugs and packages one at a time. We need an internal initiative to take care of our archive, when individuals are no longer able or willing to do so. 3. Security issues. One thing Debian does not seem to have right now is a proactive security team. Now I know that the security team now is overworked, and they do a great job. I'm thinking more along the lines of lobbying for people to audit programs that may be potential security problems. Other major vendors have this. OpenBSD being one of the best at it. What would be nice is to make sure that the core of the system is audited for any problems. This is a lot of work, but it can be done, and I am quite sure that we have a lot of people out there willing to take on the auditing process, including creating the group and administrating it. (I'm sure I had a 4, but it eludes me at this point. Maybe an update is in order later. :) If you have questions that fall outside of this email, please send them to me seperately so I can keep discussions in order (Cc the list if desired). Ben -- -----------=======-=-======-=========-----------=====------------=-=------ / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` email@example.com -- firstname.lastname@example.org -- email@example.com ' `---=========------=======-------------=-=-----=-===-======-------=--=---'
Description: PGP signature