[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

my platform

Hash: SHA1

Here is a text copy of my platform from 



                        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
     * 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.


   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.


   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.


   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

   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

  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.


   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

   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.


   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

   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.


   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!



  1. http://lists.debian.org/debian-vote/2001/debian-vote-200102/msg00038.html

Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.6 <http://mailcrypt.sourceforge.net/>


Reply to: