my platform
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Here is a text copy of my platform from
http://www.debian.org/vote/2002/platforms/bdale
Bdale
Introduction / Biography
My name is Bdale Garbee, and I ask you to elect me as your next Debian
Project Leader. For those of you new to the project in the last year
who are curious, Bdale is a contraction of Barksdale, and I pronounce
it "Bee-Dale".
My platform posting from [1] last year's DPL campaign is full of
biographical information about me. One significant thing has changed
since then...
In May of 2001 I accepted an offer to re-join Hewlett-Packard, this
time as an Engineer/Scientist in the Linux Systems Operation (LSO). HP
supports multiple Linux distributions on multiple processor
architectures in a wide variety of product forms. That translates into
lots of interesting work, and I'm enjoying the challenges.
Debian is our development platform in LSO for the kernel and related
work required to enable Linux support on HP's hardware. That means I
get to spend part of my time working on Debian, particularly the IA-64
port. But my job also includes:
* helping make sure HP participates as a good citizen in the Debian
and larger Open Source communities
* architecting solutions that enable multi-architecture,
multi-distribution Linux installation and support on HP hardware
* leading technical development of HP's Linux Enablement Kit
products
* helping form HP Linux strategy
One neat consequence of this job change is that I am now more able to
attend and speak at Linux and related technical conferences than
before. I attended ALS for the first time in Oakland last autumn, and
recently returned from Brisbane where I spoke at Linux Conference
Australia 2002 and in the Debian mini-conference that preceded it.
The Debian community is full of interesting people, and I really enjoy
meeting many of you in person, putting faces to names, and gaining
some personal context to improve the quality and effectiveness of our
online discussions.
My Goals
The "L" in DPL stand for "Leader", and the reason you should elect me
is that I am the right person to provide Debian with clear and
effective leadership .
Effective leadership requires several things. The group must have
shared values, must agree on a vision of what the future might hold if
all goes well, and must develop and follow plans for moving from the
current state towards the vision state. The primary role of the leader
is facilitation, which comes in many forms.
Values
I believe the Debian community already shares strong core values,
though we may have differences of opinion on peripheral issues. One of
our real successes, aided in recent times by our new maintainer
process, is that people joining our project share a strong belief in
Free Software and the Community Development Model.
As I have talked to other groups about Debian in recent months, our
strongly held core values come up over and over again as a key reason
for the success Debian has enjoyed. Other groups envy our ability to
attract attention, motivate so many developers, maintain so many
packages across so many architectures, and remain viable despite major
organization and infrastructure changes over the years.
These key values are in no immediate danger. They are strongly held,
and rightfully so. But nurturing them, acting in adherence with them,
and continuing to communicate them as key elements of what is special
about Debian are clearly things we should expect of our DPL.
Vision
Debian has achieved some wonderful results, but whether we will
continue to improve is largely a function of how motivated we are. My
experience leading volunteer efforts suggests to me that the best
motivators are a strong shared vision which each participant can feel
connected to, and processes that allow contributors to see results
from their efforts.
Unfortunately, I think it has been a long time since Debian had a
clearly articulated vision. It's time to fix that.
Back before we selected the swirl logo for Debian, our web pages
sported a graphic composed of colored puzzle pieces, and the text
"Debian: The Universal Operating System". Whenever I think about
Debian, that idea is what comes first to my mind.
Every once in a while, someone on our mailing lists tries to assert
that Debian can't or shouldn't be everything to everybody. It usually
doesn't take long for someone else to reply "why not?". Why not,
indeed? The Debian community is now large enough and diverse enough to
support as many sub-projects catering to different user communities as
we can imagine. There is no reason that we can't eventually be a truly
universal operating system! I can't imagine a more compelling vision
for our future.
But, if we are going to make Debian a truly universal operating
system, we face a number of continuing challenges.
Quality
When Ian Murdock wrote his Debian Manifesto early in the project's
history, he made it clear that one of Debian's primary objectives
would be to achieve and maintain the highest quality standards. After
maintaining several dozen packages, and working on 5 ports of Debian
over the years (Alpha, Sparc, ARM, PARISC, and IA-64), it is clear to
me that the most important thing we can do is continue pushing to
improve Debian's code quality. Our users expect and deserve to receive
software from us that "just works".
I believe the biggest improvements we've made in code quality over the
years have come as a result of our porting efforts, and as a result of
regularizing tools and processes for building quality into our
packages. Achieving our vision will mean continuing those efforts, and
finding ways to do more.
Our packaging policies recommend the use of -Wall when compiling, and
most of our packages comply. What many maintainers may not realize,
however, is that what is "just a warning" on one platform may be a
fatal error on another. Now that the logs from our package
auto-builders are available online, anyone can audit packages for
potential problems, and we should encourage more people to help!
I'm a big fan of helper packages like debhelper, but not as a way for
maintainers to avoid having to learn how to build correct packages...
any more than calculators are an excuse for children to not learn how
to add and subtract. Rather, I think reasonable use of helper packages
does a lot to improve consistency of packaging and avoid silly
mistakes.
I'm also a big fan of tools like lintian, which help us catch more
silly mistakes that otherwise would reduce our archive quality. The
tools we have today are not a panacea. I've done my share of ranting
about checks in lintian that are just plain wrong, or overly
simplistic. But I still run a lintian check on every one of my
packages before I upload it, and I wish everyone else would too.
Recent efforts to start measuring quality in our archive by asking
questions like "how many of our packages can be built from source
today?" are commendable. I hope to see those activities continue and
expand. At the conference I attended in Australia recently, I was
approached by a graduate student interested in the prospect of using
Debian's package pool as input for various software quality efforts.
That's pretty neat, and I did my best to encourage the idea, in the
hope that eventually something useful to Debian might come of it.
Release Predictability
There are lots of reasons that going so long between major releases
isn't a good idea for Debian. The two I care most about right now are
that many of us have a hard time retaining focus and motivation when
our work never gets released, and that it's hard for Debian to be
taken seriously as an alternative to commercial distributions when our
last stable release is years old.
If we want to be a universal operating system, we need to be more
predictable about releases.
The work done since potato released to rework our archive is really
important. Implementing package pools, and the work Anthony Towns put
into implementing the logic for promoting packages into our testing
distribution, are key to getting control over our release process in
the future. We have all been frustrated by the amount of time it has
taken to make the transition. It hasn't helped that we've had parallel
projects to do things like allow crypto into US main that have taken
much longer to implement than any of us initially hoped. However, I'm
pretty confident that the tools and processes now in place give us the
opportunity to be much more predictable about our release schedules in
the future.
I completely agree with the assertion that we need to remember that
Debian is a mostly-volunteer project and that volunteers really can't
be coerced into doing things they don't want to do. However, my
experience is that volunteers rally behind clear statements of vision
and purpose... and in many cases will work harder when they're excited
about being part of something good than they would ever work when
being coerced. So, I don't see a conflict. We should be able to
establish tentative release schedules and have some idea what new
features will be available when those release times come. Doing so
will give us all goals to aspire to, and the real sense of
accomplishment that comes from a successful release on a regular
basis.
User First Impression
We've all heard for years that Debian is wonderful once you get it
installed, but hard to install. I actually like Debian's current
installer, but then I also like dselect... probably because I've been
around the project since before either of them were invented, and know
how to drive them almost in my sleep. But that doesn't make them good
for everyone.
As part of my new job, I've spent time loading and studying various
commercial Linux distributions. There are some things Debian's current
installation tool set does amazingly well, but there are also things
about it that are really confusing and frustrating for newcomers to
Debian, much less to Linux. We can and should do better if we want to
be a universal operating system.
The consensus among those working on it appears to be that
boot-floppies as we know it today should end with woody, and be
replaced by something better for our next major release. We have many
of the components of the proposed next-generation Debian installer
already in the works.
At the same time, other interesting things have happened. Without much
fanfare, the graphical installation tools developed by Progeny for
their Debian-derived distribution have been enhanced, packaged, and
are now part of Debian main. Others have pointed out that commercial
Linux distribution installers have some excellent features, and most
are Open Source so we can borrow from them at will.
We have also seen in recent months an increase in the diversity of
installation media, including the installer-only CD images made
available for the PARISC and IA-64 ports, and in various flavors for
i386 systems. Several groups are working on tools to support
unattended installs, with at least two tool suites I know of already
packaged and in our archive. And I and others are working on ways for
users to avoid much of the complexity of our current installation
process by delivering mostly-configured OS images that prompt the user
for final configuration choices on first power up.
I almost feel that we have an embarrassment of riches available to us
for our installation tool set(s) beyond woody. We just need to figure
out which pieces to apply in various combinations to optimally meet
the needs of our different user communities.
Infrastructure
I don't know how many are aware of just how big Debian's
infrastructure requirements really are. As the number of registered
developers and the packages they maintain continue to grow
approximately linearly, the disk space required to store the archive,
the network bandwidth required to mirror the archive, and the
computational resources required to keep all the packages auto-built
for all of our supported architectures keeps climbing.
We are fortunate that the value we deliver, and our strong reputation,
have led to so many donations of various resources to meet these
needs.
As the person who put the first master.debian.org together oh so long
ago, I've been thinking about and paying attention to Debian's
infrastructure issues for a long time. I chat fairly frequently with
the people who do much of the work of maintaining our archive and
mirror network, and I hear about many of the problems they encounter.
Talking with our Australian counterparts recently in Brisbane, where
bandwidth cost is much higher than in the US, helped me to remember
that we need to be pro-active about managing the cost and complexity
of the infrastructure supporting our operations.
We should talk up the benefits of implementing caching proxy servers
instead of mirrors for many users, and provide either packages or
cookbook instructions on how to implement resource-efficient
solutions. We should continue to look at ways to reduce the bandwidth
requirements both for our mirror network, and for individual users
updating over the network... and be willing to implement good
solutions when we find them.
Security
To be a universal operating system, we need to avoid having to
apologize to our users. Several complementary proposals for improving
the ability to verify the authenticity of our work are in various
states of deployment. I hope to see these continued.
I think we could also do a better job of helping our users be secure
in the things they do with Debian, by enabling crypto support in more
of the applications we ship. Having to build and support both crypto
and non-crypto versions of some of our key applications has taken a
lot of energy that could have gone to better use. That's why I'm such
a strong supporter of the effort to move Open Source crypto into US
main, and thrilled that we're on the verge of implementing the change
as I write this text.
Linux Standard Base
In our Social Contract, we commit to serving users of Debian even when
they need to run non-free software. We could do more to help
enterprise customers use Debian than we do today, with some
potentially very positive results.
Enterprise customers want to be able to buy big third-party,
binary-only application suites with support contracts, and run them on
our operating system. It would be easy to dismiss these folks as
peripheral to our primary goals, since we share such a strong value on
Free Software. However, these folks often really want to run Debian on
their systems, but can't because the application vendor only certifies
their application on some other distribution. If we can manage to meet
enterprise needs and thereby help out our friends in industry without
compromising our system or our values, we should do it.
The LSB is the solution to this problem. If successful, the interfaces
defined by the LSB will become the target platform for big application
developers to deliver to. It won't matter whether the system is
Debian, RedHat, SuSE, or something completely different... as long as
the system is LSB compliant. This will remove a substantial barrier to
the acceptance of Debian in corporate computing environments that
currently exists, taking us one step closer to being a universal
operating system.
A lot of fear and confusion surrounds the LSB. It doesn't require that
we abandon our package format, or make onerous changes in our system
to be compliant. The LSB as it stands today is not perfect. Early
versions of the specification have serious issues that need to be
resolved before the LSB becomes truly viable. These are all solvable
problems.
Many major commercial distributions are now on record as supporting
the LSB, and I think it's important that Debian does too. We have no
vested interest in maintaining the status quo, and could reap strong
benefits from being the best LSB-compliant distribution available. We
shouldn't be at all passive about this. We should be willing to do the
work, and fight the fights that are required to ensure that the LSB
specification evolves into a truly useful standard that we can support
with enthusiasm.
Summary
I have been a developer of and advocate for Free Software since before
we knew what we were supposed to call it. I joined the Debian
community in early 1995, and have been steadily and substantially
contributing to our success in a variety of ways ever since.
Working on Debian is my way of expressing my most strongly held
beliefs about freedom, choice, quality, and utility. I have a vision
for what Debian can be, and the skills and experience as a leader to
nurture and communicate that vision. I ask you to elect me as your
project leader so that together, we can make our vision a reality.
Thank you for your time, and your vote!
______________________________________________________________________
References
1. http://lists.debian.org/debian-vote/2001/debian-vote-200102/msg00038.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.6 <http://mailcrypt.sourceforge.net/>
iD8DBQE8g7ZEZKfAp/LPAagRAnlNAJ4yuWIiBzC0g1Xs6ySQ5phv/oP1xwCggS6X
hhSsSMxR0KnvbrrZBHZVrts=
=1Ki6
-----END PGP SIGNATURE-----
Reply to: