[ Please send replies to -devel, Cc's to me encouraged ]
When I originally stated my interest in running for Debian project leader, I
was unsure if I really would be a good candidate or not, so I offered to run
if others believed I should.
I am confident that I can be a good leader for Debian, and I'm pleased that
others who have commented seem to agree. With this message I announce my
intention to run for Debian project leader.
The obvious requirement for the job is time for the project and lots of it
at that. But I also believe the project leader should take an active role
in leading the project, but not to the point that they start pushing instead
of leading. The ability to listen to people you don't agree with is also
very important, as is the ability to say what you're trying to say clearly.
I believe I have these qualities.
I think it's important that those who are planning to support me in this
election be aware of my position on a few issues. One of the most prominent
issues I see affecting the project right now is IWJ's proposal to rewrite
the DFSG. I am opposed to this and believe we should focus on correcting
the problems with the current DFSG rather than trying to totally replace it.
I also am opposed to some of the changes made in Ian's proposal, namely
placing a time limit on use of the BSD Advertising clause and disallowing
licenses which require modifications to source code be made as patches. I
can agree that both of these things are not desirable even if they are at
the moment allowed by the DFSG. I can agree that we might make it known in
a revision of the DFSG that both of these are depreciated because they are
difficult to work with, but removing them outright seems like a bad plan to
me, as does applying a time limit to their acceptance or grandfathering
well-known applications or licenses.
As for the future, there are a number of things I can envision. The short
of it is that Debian is currently working towards these things now. These
include unattended and multiple machine installations, a better package
front-end, smoother installation on more hardware, that sort of thing. I
support making things user friendly, but I think other distributions are
making a few mistakes I hope Debian does not make.
Under some distributions, there are really nice and pretty high-level
configuration tools which automate tasks, but many of them don't work unless
you stick with the standard configuration. Debian's tools seem to have this
problem much less often, but as a consequence they are more mid-level tools
and require more reading on the part of a new Linux user. I believe this is
the Right Way to do things, and many of you agree with me. However I also
support high-level tools which work with these mid-level tools. Often times
this makes the high-level tools easier to write, and when that isn't the
case, the added difficulty in writing the tool is rewarded with seamless
integration with the current system. This is good.
An example of a high-level tool which could be designed to work with an
existing mid-level tool might be a configuration utility for sendmail.
Instead of trying to build sendmail.cf, it would build sendmail.mc which is
much easier for a number of reasons. Just about everything that can be done
with sendmail.cf and be done with sendmail.mc, the program could read the mc
file which would mean that changes made manually would not be lost, and all
around everything is more smooth.
I realize we have kicked the idea of release goals in favor of project
goals, but I believe it is important that we prioritize our goals together
and figure out what we want to do in the short term. Some goals I think we
can accomplish with potato are 2.2.x kernel, glibc2.1, a better package
front-end, and more streamlining of the installation. I think PAM is
possible too, but this largely depends on coordination of effort. I believe
we should start moving in the direction of FHS compliance too, we'll see how
that pans out.
Of course we shouldn't limit ourselves to these things. If something else
comes up that can be done, I believe it would be foolish not to do it
because we decided beforehand to focus on something else. Certainly we
shouldn't hold up a release for changes like the above unless of course
something really requires it. The best we can do is work around them.
Another issue that has come up a few times is restructuring of the archives
in one manner or another. I am not sure everyone suggesting it realizes
what a big job this would be. I can see that some changes are beneficial,
but I think I would object to a gratuitous change. If the change is needed,
we should discuss it and make the changes we need to make. However change
for the sake of change will only frustrate users and developers alike.
I know some (read: most) of you are worried about bureaucracy creeping into
Debian. I'm as concerned about this as many of you are and I hope that we
can work together to keep reasonable amounts of process down to just that:
Reasonable amounts. Controversial topics come up and sometimes it is
difficult to know where everyone stands and to reach a group decision.
Other projects like Debian's policy document are really almost too big for
one person to maintain effectively without much frustration for everyone.
I don't think we should complicate day-to-day matters with politics and
needless processes for every single thing that comes up. I really want to
avoid it as much as possible.
If anyone has any other questions or comments, please feel free to say
something. => I do read my mail and do answer it.. Also a msg on irc will
usially get my attention. I can be found on the Openprojects almost always
as Knghtbrd.
--
"I may be a craven little coward, but I'm a _greedy_ craven little coward!"
-- Daffy Duck
Attachment:
pgp6AAaCdvFit.pgp
Description: PGP signature