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 \
` bcollins@debian.org -- bcollins@openldap.org -- bcollins@linux.com '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
Attachment:
pgp7CzzT2GogL.pgp
Description: PGP signature