Date: Thu, 10 Dec 1998 12:05:43 -0500
From: Ben Collins <bmc@it.larc.nasa.gov>
To: debian-devel@lists.debian.org
Subject: Nomination for Project Leader


--Nq2Wo0NMKNjxTN9z
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

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 aquainted 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
a 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 carreer 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 aquired 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 knowledgable 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=20
|
|      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 interpretaion 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 unnaceptable. 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 get's 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 persue 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 recieved very well, but a
variation of some sort would atleast 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 initally 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 tka
responsibility for the bugs, or try to find some one whole 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 creater of the list would have the option of closing it when it's use
was complete.


=46rom 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 focussed 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 effectlively 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) 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, MacOS,
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 immenent 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 any one 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 exageration 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

--=20
-----    -- - -------- --------- ----  -------  -----  - - ---   --------
Ben Collins <b.m.collins@larc.nasa.gov>                  Debian GNU/Linux
UnixGroup Admin - Jordan Systems Inc.                 bcollins@debian.org
------ -- ----- - - -------   ------- -- The Choice of the GNU Generation


--Nq2Wo0NMKNjxTN9z
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia

iQCVAwUBNm//Zio9WkFm9rsJAQEsGgP/b4yL6ADp3eGyoA7E6HKCptkohw00hIlf
qdb+LnINvTOkhJUFylsfxdCpC3ROrr5ukXHxPq9jtV8+LoO1oPl0Tg3YApdOK4M8
WsvLFtEjazqjAipeESVwNmwRycjL7vXLX4mO7M4EjmY7qZA421ts5d3gSX0hM5Yg
NB9OAvdJSfg=
=9HbD
-----END PGP SIGNATURE-----

--Nq2Wo0NMKNjxTN9z--


-- 
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org