<br /> Questions for DPL candidates? – Debian Planet

Welcome to Debian Planet

News for Debian. Stuff that *really* matters

Sponsorship

Debian Planet is hosted by Bluelinux Internet Services Ltd. Offering a special discounted rate for Free and Open Source software community members.

Buy your Debian merchandise at DebianShop.com.

Debian
These are important Debian sites one should not be without!

  • Official Debian site
  • Package search
  • Mailing list archives
  • Bug reports
  • Debian on CD
  • Debian Weekly News — excellent news source!
  • Unofficial APT sources
    (apt-get.org)

  • Developers’ Corner
  • Community
    Need help? You’re not alone on this planet.

  • Planet Debian
  • debianHELP
    (User support site)

  • Debian Administration
    (SysAdmin resources)

  • Debian International
  • DebianForum.de
    (Deutsch)

  • DebianForum.dk
    (Dansk)

  • EsDebian
    (Español)

  • DebianWorld
    (Français)

  • Debian-Fr
    (Français)

  • MaximumDebian
    (Italiano)

  • DebianItalia
    (Italiano)
  • DebianUsers
    (한국어)

  • Debian-BR
    (Português)

  • DebianHOWTO
    (Deutsch)

  • Russian Debian (Русский)
  • Debian-JP
    (日本語)
  • Debian Suisse
    (Suisse)
  • Contribute
    Got that latest or greatest scoop? Perhaps you have some important news for the Debian community? Submit a news item!

    Or perhaps you’ve written a rather ground breaking insight into some aspect of Debian and you feel compelled to share it with others? Knock up a longer editorial article and send it to the editors.

    General feedback should be sent to staff@debianplanet.org

    IRC
    The place to get help on a Debian problem (after reading docs) or to just chat and chill is #debian on irc.oftc.net.

    Many of the Debian Planet staff live there so pop by and say hello.

    Debian Planet also has its own channel on the same network called #debianplanet.

    Syndicate
    XML

    Questions for DPL candidates?
    Submitted by DanielS on Saturday, February 01, 2003 – 02:43
    Manoj Sristava, the Debian Secretary, recently announced the Debian Project Leader election, to be held from Mar 7th-28th. Every year, the process includes a public IRC debate between candidates, with questions largely sent in from the public. Another vital component of the election is the platforms of the various candidates, which outline their position on all the issues facing Debian, and their plans if elected for DPL. Platforms will be published on February the 14th, rebuttals on the 21st, and the debate any time between them and the 7th of March.

    Now it’s your turn: What do you want to see in a DPL? In your comments, you can pose questions to candidates, or merely state your opinion on things. Manoj and others will be reading this thread, so this is your chance to communicate directly. The best questions asked will be merged into a new story, where you will again have your chance to comment on what you think.

    Category: Features

    Control panel

    Comment viewing options:



    Select your prefered way to display the comments and click ‘Update settings’ to activate your changes.

    Subject: Some other questions
    Author: jfs
    Date: Friday, 2003/02/21 – 10:09
    I do have some questions for the DPL candidates, some of them have answered them in their platforms but I would like to gather the viewpoint of all of them in these (IMHO important) issues:

    1.- Do you think that translators, people involved in i18n, and people involved in documentation-only work should be given maintainer status even though they are not going to maintain packages or infrastructure? How should the NM process be modified in order to provide for this?

    2.- Do you believe Debian has to actively look for business partners in order to be “certified” as part of broader IT solutions? What kind of help will major companies get from Debian if you were DPL? (This is not a ‘non-free’ kind of question, BTW, it’s a major caveat for companies to adopt Debian as a distribution of choice when the hardware vendors do not ‘support’ Debian as an operating system in their solutions)

    3.- What do you believe the involvement of the Technical Comitee should be wrt fundamental differents in developers or major issues which hold back the development of the distribution as a whole? Do you view the Technical Comitee work as an active role (i.e. urging for things to be done or asking resources coming from the NM queue to cooperate in things lacking instead of making their pet projects) or as a passive role (i.e. endpoint of discussions between developers in the BTS when no agreement is reached)

    4.- What is the number one thing you will take an active role as DPL to fix in the Debian distribution? (not the project) What actions would you take, if elected, to fix it?

    5.- What is your standpoint in Debian vs. the others? In which areas do you think Debian should cooperate with other distributions? (save the LSB, think about GPLd software which is produced by commercial distributions, documentation…)

    6.- What would you, as a DPL, do to help improve areas in which developers are not that much willing to contribute to and which are usually lacking? (for example: documentation)

    Umm… some might be redundant, but you get the point 🙂

    – Javier Fernández-Sanguino Peña

    [ Please login, or register ]

    Subject: save me from g2
    Author: aj
    Date: Wednesday, 2003/02/05 – 14:40
    Bring Gentoo users like myself back into the fold.

    I love much about Debian, but its workstation performance leaves a lot to be desired. Make a deb subarch field. Then maintainers can submit subarch packages for whatever programs they see fit to.

    No, the birthday package does not need to be optimized, but if apt knew that I prefered i686 packages it would automatically get me the few packages that it makes a difference on. Faster X packages really help.

    [ Please login, or register ]

    Subject: Questions
    Author: zygut
    Date: Wednesday, 2003/02/05 – 02:43
    1. The DPL role seems on the outside to be one in which the DPL doesn’t actually do anything. In your words, what do you think the role of the DPL actually is? Is it anything more than simply a figurehead?

    2. What political ideology does Debian most closely resemble? What political ideology do you see Debian as moving towards, or away from?

    3. Woody was the distribution of choice for many people during potato’s old age as stable, because potato packages were so incredibly out of date. For a long period of time, probably at least a year, most people ran woody, even though potato was “stable”. If you ran potato for anything modern, it was required to build newer versions of packages (either out of woody, or standalone), in order to use them. While most people ran woody, there were no security updates for woody, so people had to manually fix security issues when they arose. I believe that this created a gap in the fluidity of the distributions causing a lot of work no matter which distribution you actually ran. Would you support finding a way to allocate resources for a security team for testing at a later stage, when stable usage is dwindling and testing is becoming the release de jour (as well as the release with no security fixes devoted to it).

    4. Where did you put my cheese?

    [ Please login, or register ]

     

    Subject: Better support of testing
    Author: raj
    Date: Wednesday, 2003/02/05 – 17:26
    All the threads out there seem to say, don’t use stable, use testing instead (except for a narrow range of servers). So will there be better support for the testing distribution in terms of building official CD images for vendors to sell (maybe point releases for the testing distribution), as well as security updates?

    That way those of us with 56K modems (that usually connect at 28.8) can actually use testing. Last I checked, there are many sources of stable CDs, but not much for testing.

    [ Please login, or register ]

     

    Subject: you’d need a subscription service
    Author: JoeBuck
    Date: Wednesday, 2003/02/05 – 18:27
    Testing changes fast enough that you’d need to keep buying CD’s on a regular basis; certainly far faster than stable.

    I suppose that there may be an opportunity for a small business that mails you new apt archives of testing every month or two.

    [ Please login, or register ]

     

    Subject: Testing subscription
    Author: raj
    Date: Monday, 2003/02/10 – 17:45
    This is why I’ve always thought that people who recommend using testing are simply being impractical. There are companies that mail you CD-R discs, they’re expensive, and what if it happened to be a bad day for the testing distribution when they burned it?

    That’s why I’m wondering if the developers and the DPL will consider more direct support for testing, to make it more of a real release as an alternative to stable. Other distributers do this:

    Red Hat standard (like testing but just the 1-CD set)
    Red Hat Advanced Server (like stable, but pricey)
    Red Hat Professional (testing with the full 7-CD set)

    SGI Irix maintenance stream (like stable)
    SGI Irix bleeding-edge stream (like testing)

    Of course these people are for-profit.

    I suppose testing works well enough at a couple of megabits/sec and no hourly charges.

    [ Please login, or register ]

    Subject: LSB stuff (groan…)
    Author: jaycee.uk
    Date: Tuesday, 2003/02/04 – 11:10
    Here’s one that’s been bugging me for a while.

    o How far should Debian go to ensure LSB compliance?

    o Should we adhere to a standard way of doing things, even if it goes against what we believe is best?

    o Ultimately, should we aim for the removal of the “lsb” package because we are LSB compliant by default?

    Please note that I’m not raising these with reference to any specific LSB issue, but merely responding to an increase in the number of “lsb sucks on this point, let’s do it another way” opinions that I’ve seen on @lists.debian.org posts.

    jc


    jc -> jaycee.spam.me.not@jaycee.uklinux.net
    to email me, my address should be in the form a@a.b.c

    [ Please login, or register ]

     

    Subject: APT to RPM?
    Author: Glanz
    Date: Sunday, 2003/02/09 – 00:48
    If complying to the LSB means forsaking APT in any way or form, then I’d have to move to FreeBSD ports rather than endure RPM’s again.
    [ Please login, or register ]

     

    Subject: Erm, no
    Author: robot101
    Date: Sunday, 2003/02/09 – 03:11
    No, it doesn’t mean forsaking apt at all! Our lsb package provides the necessary glue to turn an LSB compliant RPM into a deb, which can be installed natively. This isn’t the only way to do it. We could with a little more work teach dpkg how rpm dependencies work, and add a dpkg-rpm backend for grokking the files.

    Robster is a monkey
    [ Please login, or register ]

     

    Subject: Debian should fit into a larger community
    Author: JoeBuck
    Date: Wednesday, 2003/02/05 – 18:36
    If an aspect of the LSB sucks, it would be better to get this aspect reformed than to just fork. The LSB is going to evolve (next move will probably concern standardizing the C++ ABI), and if Debian doesn’t want to play, Debian will have no influence.

    We’re seeing much more use of apt in the RPM-distro world; maybe some future LSB will wind up specifying apt as a standard, leaving the issue of what lies beneath (RPM files or deb files) unspecified as long as an LSB-compliant RPM can be added. Debian could support that.

    Some complaints I’ve seen about the LSB from Debian developers are spot on, but others just amount to objections to trivial differences between the LSB way and the Debian way that aren’t worth arguing about.

    [ Please login, or register ]

    Subject: What do you say to?
    Author: iambfree
    Date: Monday, 2003/02/03 – 21:05
    The journalist who asks:

    • Would it just be better if everyone used the same software?
    • Wouldn’t everything work better?
    • Shouldn’t Debian just work on Debian GNU/Win?

    Why do I ask? Well as DPL you should be able to devour these oppurtunities to educate the journalist and perhaps not only get a great piece written, but also have a journalist with questions on his minds for everyone else he meets? Debian deserves some serious media coverage, and the only way to get it is to have the right person at the helm, a person TV shows love to have on and newspapers love to interview. I can easily imagine the right person getting frequent calls from the BBC to video conference on topical news programmes!

    [ Please login, or register ]

    Subject: Trying to think up something original…
    Author: x3ja
    Date: Sunday, 2003/02/02 – 02:39
    How about these:

    1. What’s the worst computer-related injury you’ve ever received?
    2. What’s the sinlge most geeky thing you’ve done (apart from standing for DPL)
    3. Supposing you had to get rid of 2 things from your house, which of the following would it be: Computers, TV, Fridge, Cooker, Windows (the glass type), Music?
    4. If you could have any super power, what would it be?
    5. Do you use an electric or manual toothbrush?

    Hmm, or are those not what you wanted? I’m not so good at the serious ones.

    [ Please login, or register ]

    Subject: Just a wish
    Author: SUPERiodico
    Date: Saturday, 2003/02/01 – 23:31
    I’d like new DPL to take care of new maintainers, in order to reduce the latency of new maintainer’s approval time.

    As I say in the subject, just a wish, but I’d like it to become real.

    [ Please login, or register ]

    Subject: Questions to get the ball rolling….
    Author: grolschie
    Date: Saturday, 2003/02/01 – 21:30
    To the candidates:

    1). What can/do you offer the Debian community that that you feel is lacking in the current leadership?

    2). How would things be different for Joe user under your leadership?

    3). Dreams/goals/vision for Debian?

    4). What is the number one issue that you feel needs to be addressed in Debian?

    [ Please login, or register ]

    Subject: freedom and Debian
    Author: comewhatmay
    Date: Saturday, 2003/02/01 – 20:21
    First a minor criticism of this article: there is no pointer for information about the role of Debian Project Leader. How can we ask intelligent questions if we don’t understand the scope of the position?

    The issue I would like to bring up is regarding the freedom we have with components that make up Debian/GNU. There has been talk that the DFSG and the Open Source Definition should once again be unified, but I don’t agree and in fact think that the DFSG should be made more strict (that is, ensure more freedom to users of Debian). Specifically, I believe we should have the freedom to pull anything out of Debian, hack or improve it, and redistribute and sell the result, especially if the result is kept open source. The DFSG is already lax on this issue, allowing licenses such as the Artistic License which forbids “charging a fee for the package itself”. On the way is the Bitstream font license, resulting from the recent GNOME/Bitstream agreement, which also will prohibit sale unless the fonts are part of a bigger package.

    These kind of licensing terms will become more and more popular as businesses try to leverage the popularity that their products gain by being included with free software distributions while locking out competition from derivative works. I believe free software systems compromise themselves by including such components.

    I would like to hear the stance on this issue by anyone running for Debian Project Leader.

    [ Please login, or register ]

     

    Subject: First a minor criticism of
    Author: Integral
    Date: Saturday, 2003/02/01 – 22:41
    First a minor criticism of this article: there is no pointer for information about the role of Debian Project Leader. How can we ask intelligent questions if we don’t understand the scope of the position?

    The obvious place to look is the organizational documents of Debian, specifically the Constitution.

    Basically, the Project Leader has historically done very little since Bruce had the job — most recent project leaders acted in that capacity primarily as spokespeople to the outside world. Some of them also made significant contributions to Debian while they were Project Leader, but those contributions were made in their role as a Debian developer (eg, I believe Wichert started work on dpkg while still DPL, although I may have the timeline wrong there)

    That doesn’t have to be the case, but the constitutional power of the DPL is fairly weak — it’s more of a bully-pulpit position as far as internal affairs go.

    I was only around for some of the history I described, so some old-timer might show up and correct me on a few points.

    Daniel

    [ Please login, or register ]

    Subject: On the size of the project
    Author: fabbe
    Date: Saturday, 2003/02/01 – 10:12
    The sheer mass of the Debian Project, in terms of the amount of packages and thus code to be maintained, is frighteningly large. It has been proposed several times that some kind of modularisation and organisation by importance of packages could help produce Debian releases with more recent versions of software. The Debian Subprojects — Debian Jr., Debian-Med, Debian-Edu and the Debian Desktop Project — are reactions and concrete attempts to divide and organise the development efforts. Hints of this kind of thinking has always been present in the “tasksel” tool.

    I think a critical mission for the DPL this year would be to take the Subprojects division further, and guide Debian towards becoming a distribution where you can choose different sets of package groups and create a system that meets your requirements of security and features, without having to resort to including “testing” or “unstable” in your sources.list.

    A Debian “core”, consisting of a kernel and the most important tools (dpkg and apt included) would also be a more attractive platform to develop for. Having a stable “core”, new releases could simply update a small subset of the thousands of packages that are available.

    [ Please login, or register ]

     

    Subject: On the shape of the project
    Author: aqua
    Date: Wednesday, 2003/02/05 – 01:30
    Similar question asked differently:

    Debian’s organizational structure is very wide and flat — many many developers, very few levels of hierarchy or management. Granted the cats are fairly self-herding, but Debian has trouble with transitions that involve mass participation or cause massive disruption — widespread debconf adoption, e.g. The extremely wide base is one reason cited for the state of debian-nm: that adding more novice DDs makes things worse, not better. What structural arrangements would make the project more effective at dealing with the big, painful or intricate issues? What arrangements would be ideal for a large-scale free software project generally, leaving aside the feasibility in Debian’s own case? Could there be more management without more bureaucracy?

    [ Please login, or register ]

     

    Subject: Huge developer base, second-class citizens
    Author: DanielS
    Date: Saturday, 2003/02/01 – 11:06

    The sheer mass of the Debian Project, in terms of the amount of packages and thus code to be maintained, is frighteningly large. It has been proposed several times that some kind of modularisation and organisation by importance of packages could help produce Debian releases with more recent versions of software. The Debian Subprojects — Debian Jr., Debian-Med, Debian-Edu and the Debian Desktop Project — are reactions and concrete attempts to divide and organise the development efforts. Hints of this kind of thinking has always been present in the “tasksel” tool.

    Well, although Debian might have a staggering amount of packagers, we also have a staggering amount of developers – close on 1000, I believe. This works out to about 10 source packages per developer. So, while the archive might be huge, it’s not like the developers are overloaded.

    My main fear whenever splitting Debian into subprojects is proposed is that it will create a tiered society, where some packages are treated as more important than others. You’ll find some important projects will end up being too large, with a too small development base, to release, so they’ll be in permanent beta. Imagine if this happened to something like GNOME, or KDE. That would suck.

    I think a critical mission for the DPL this year would be to take the Subprojects division further, and guide Debian towards becoming a distribution where you can choose different sets of package groups and create a system that meets your requirements of security and features, without having to resort to including “testing” or “unstable” in your sources.list.

    I don’t see the problem with including “testing” in the sources.list. Everything in stable is guaranteed to be rock-solid – chuck it into production without a worry. This conflicts with the aim of a workable, current desktop, usually. If you want a desktop, use “testing”. If you want a production server, use “stable”. There’s no two ways about it. Also, the subprojects idea probably wouldn’t help this, it would only make it worse – one release of a subproject would depend on one release of another, and things would get out of sync when one subproject took longer to release, and your sources.list would be hell. It’s only going to make this worse.

    A Debian “core”, consisting of a kernel and the most important tools (dpkg and apt included) would also be a more attractive platform to develop for. Having a stable “core”, new releases could simply update a small subset of the thousands of packages that are available.

    What if I run Apache, PHP4, mod_perl, mod_python, mySQL, PostgreSQL, etc, etc, ad nauseum, in production? I still want that release to be rock-solid. And what’s “core”? Does it include X11? Does it include a compiler? You’ll no doubt get freeping creaturism in core.

    All in all, I think the best thing is to keep Debian in one. Subproject fragmentation will only make release spaghetti, generate second-class citizens in Debian, have huge release-sync problems, and more. The best thing is for people to get to know the current release process better, so we can avoid the problems with woody, which was the first release featuring testing.

    [ Please login, or register ]

     

    Subject: Re: Huge developer base, second-class citizens
    Author: fabbe
    Date: Saturday, 2003/02/01 – 17:18
    Well, although Debian might have a staggering amount of packagers, we also have a staggering amount of developers – close on 1000, I believe. This works out to about 10 source packages per developer. So, while the archive might be huge, it’s not like the developers are overloaded.

    The average number of packages per developer is an excellent example of a piece of statistics that tells you nothing useful. Most of Debian has been built, and will continue to be built, by a small number of people (compared to the total number of developers). The development process should take this into account and lighten the burden on those developers while at the same time allowing the remaining ones to continue contributing sporadically. Focusing their limited time on a subproject would be more productive.

    My main fear whenever splitting Debian into subprojects is proposed is that it will create a tiered society, where some packages are treated as more important than others. You’ll find some important projects will end up being too large, with a too small development base, to release, so they’ll be in permanent beta. Imagine if this happened to something like GNOME, or KDE. That would suck.

    I think this is the situation at the moment.

    1. Some packages are [treated as] more important than others.
    2. Some important projects are too large, with a too small development base, and are in beta for too long.

    1. cannot be changed and I can’t think of any reasons why it should be desirable to change this. Democracy is unfair towards those who are in disagreement with the majority. Debian already works this way.

    2. could be changed, and should be changed. In the example of GNOME or KDE, Debian lacks the capacity to keep up with upstream. It is very difficult to release with the latest version of all the software in Debian, since all the upstream projects release at different times. There will always be an inconvenient release “just after” a stable Debian has been released. More efficient splitting into subprojects would require only updating the packages for that piece of software, and a new release could be made with only that piece updated.

    I don’t see the problem with including “testing” in the sources.list. Everything in stable is guaranteed to be rock-solid – chuck it into production without a worry. This conflicts with the aim of a workable, current desktop, usually. If you want a desktop, use “testing”. If you want a production server, use “stable”. There’s no two ways about it.

    Of course there is. Many people use APT pinning to pull in packages from testing or unstable — see http://lists.debian.org/debian-devel/2003/debian-devel-200301/msg01644.html to learn why this is a bad idea.

    If you say “testing” when people ask for “desktop” then “testing” could as well be renamed to “desktop”. But this is not what testing is for. It is an attempt to improve the release process of Debian, a sensible goal that should continue to exist.

    You say that “rock-solid” conflicts with the aim of a workable, current desktop. I agree that this is the status quo. But I think it would be foolish to let it continue to be like that.

    Also, the subprojects idea probably wouldn’t help this, it would only make it worse – one release of a subproject would depend on one release of another, and things would get out of sync when one subproject took longer to release, and your sources.list would be hell. It’s only going to make this worse.

    Of course, APT would probably not even have to be changed, and neither would your sources.list. The subprojects would not depend on each other, but packages would depend on each other as usual. If a subproject took longer to release, then the previous versions of that subproject’s packages would be released. But these are all details.

    What if I run Apache, PHP4, mod_perl, mod_python, mySQL, PostgreSQL, etc, etc, ad nauseum, in production? I still want that release to be rock-solid. And what’s “core”? Does it include X11? Does it include a compiler? You’ll no doubt get freeping creaturism in core.

    I trust the debian developers that would work on “core” would be competent enough to avoid such things.

    This is not a question of changing or cancelling any of the excellent ideas that have already been tried in practise. It is simply a way to divide the large project that is Debian into smaller, more manageable pieces. This is nothing new; software engineering has used such techniques for a long time. Why shouldn’t Debian use these techniques?

    [ Please login, or register ]

     

    Subject: Setting priorities
    Author: Zomb
    Date: Saturday, 2003/02/01 – 13:12
    Daniel, please, look at how Debian is beeing developed now. Divide and conquer is the natural way of managing things. “The first ones” developers already began to create a structure (Priority, Section). But what currently happens, is degrading this to a flat structure, more and more. We have 10000 packages and this meand LOTS of metadata maintained by apt and dpkg. And it confuses new users. Why do they need to know about 30 editors, when they do not need the half of them in LINU-X-Windows (X11 for them)? Why do they need 5 DNS daemons when they do not need a single one?

    Another thing are our 11 arches – in addition with 10000 packages, this means LOTS of synchronisation problems. Why should some (mature!) package wait for others, that are broken? This does not help ANYONE, but makes Debian reputation of the outdate-distro even worse.

    I see your worries and understand them, but I fail to agree with them completely. If you think we should not create a sub-socieaty, then we should create multiple distros with different cores – a network server distro, a science distro, and a desktop/workstation distro. With no binary dependencies (you know, this joke called testing), but a sane Sid->Pre-Working(*)->Working(**)->Stable release cycle.

    (*) Freshly recompiled for Working, similar to Testing but without binary dependencies on Sid.
    (**) See buxy’s papers from the last DPL election.

    [ Please login, or register ]

    Search articles



    Category
    ·News (405)
    ·Features (5)
    ·Site News (16)
    ·HOWTOs (78)
    ·Tips (21)
    ·Opinion (29)
    ·Q & A (34)
    ·Sponsorship (1)
    ·Press Releases (5)

    Log in
    Username:

    Password:

    Remember me

    » Register
    » New password

    Debian Security Announcements
    DSA-943 perl
    DSA-942 albatross
    DSA-903 unzip
    DSA-941 tuxpaint
    DSA-940 gpdf
    DSA-939 fetchmail
    DSA-938 koffice
    DSA-937 tetex-bin
    DSA-936 libextractor
    DSA-935 libapache2-mod-auth-pgsql

    Planet Debian
    Wouter Verhelst: On flames.
    Joachim Breitner: Fixing my planet.debian.org subscription
    Steve Kemp: She has the blood of reptile just underneath her skin
    Pierre Habouzit: Married …
    Pierre Habouzit: whitelister 0.4 (SPF) and aaege ….
    Pierre Habouzit: kde 3.4.1 upload
    Holger Levsen: In case you are running OpenWRT
    Michael Janssen: Shiny roofs are good for the environment!
    Matthew Palmer: Work it out yourself, dammit!
    Axel Beckert: Tell me which music you like and I tell who you are

    Debian Administration
    How do I prevent rebuilt packages from being upgraded?
    Disabling the print-screen key inside X?
    Monitoring your bandwidth usage with vnstat
    Ruby on Rails on Debian
    Choice for Virtual Private Servers?
    Monitoring your hardware’s temperature
    Sending mail with Exim from ‘dialup’ IP
    How to recover GRUB Debian Sarge after reinstalling Windows
    Getting a GUI
    Spam filtering with Pyzor and SpamBayes

    Latest poll: Which release scheme should Debian follow?
    Continue this way (release when ready)
    48%
     
    Give up on releasing
    8%
       
    Split the release up
    8%
       
    Speed the release up
    32%
       
    Crank the workload up (see DebianWiki ReleaseProposals for details on these)
    4%
       

    Total votes: 372
    0 comments · older polls

    home · archives · news feeds · about · polls · search · sections · user account

    Powered by the amazing Drupal

    Debian Planet is not officially related to the Debian Project.
    Debian and the Debian logo are trademarks of Software in the Public Interest, Inc.