<br /> Suggestions for Improving Packaging Efficiency? – Debian Planet

Welcome to Debian Planet

News for Debian. Stuff that *really* matters

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

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

  • debianHELP
    (User support site)

  • Debian International
  • DebianForum.de

  • DebianForum.dk

  • EsDebian

  • DebianWorld

  • Debian-Fr

  • MaximumDebian

  • DebianUsers

  • Debian-BR

  • DebianHOWTO (Deutsch)
  • 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

    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.


    DP is sponsored by Xinit Systems.

    Domains paid for and hosted by uklinux.net.

    Buy your Debian merchandise at DebianShop.com.

    Support Debian through Bytemark Hosting. At least £7 will be given for each new account


    Suggestions for Improving Packaging Efficiency?
    Submitted by hackel on Saturday, April 20, 2002 – 23:19
    In light of the rather nasty debate in the KDE story below, I thought it would be a good idea to solicit suggestions for a solution to the issue of large packaging projects getting hung up on one person’s limited availability and/or abilities. Both sides present a valid case — developers volunteering their time do not deserve to be put down for their mistakes or a lack of time, yet if they are unable to do a job, especially when others are willing and able to do it, then those people should be given that chance. What do you think is a good solution to this problem?
    By the way, I’m not a Debian developer, just an avid user who knows what it’s like when many people are in need of my time. The idea that seems most natural to me is to setup some official CVS servers for the development of large packages, and ensure that no one person ever has ultimate control over the archive, kind of a Debian-centric Sourceforge. But again, I’ve not been there, so I’m more interested in what you all think. Please be friendly and give constructive comments. 🙂

    Robot101: People interested in seeing Openoffice in Debian have done just that, and have recently announced that they were using a CVS archive to co-ordinate their work. I expect we’ll see more of this kind of thing for large packages such as this. Even though it may not be obvious, many large packages such as X, glibc, dpkg, apache2 and gcc do already recieve significant help from groups of regular contributors, and anyone can help with any package by posting a patch to the BTS.

    However it will be much harder to disperse the idea that developers have ‘ultimate control’ over their packages – whether this is a good thing or not. Theoretically the technical comittee can override them if they reach consensus, but it never has and currently has difficulty responding to issues raised, let alone reaching a consensus.

    Control panel

    Comment viewing options:

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

    Subject: Re: Suggestions for Improving Packaging Efficiency?
    Author: Anonymous
    Date: Monday, 2002/04/22 – 03:17
    What you’re basically arguing for (if i understand you correctly) is the use of the “testing” distribution for desktop users. I totally agree. I use sid personally, and the breakage is rare. The breakage in woody should be significantly less.

    The only problem I see, is that the word “testing” may scare people off. Maybe even more the “beta”, or “alpha” even. Simply put, I believe one of the biggest things to help people realise that testing may be the place for them is a better euphimism.

    However, that doesn’t change the fact that even sid doesn’t have KDE 3, X 4.2, etc. Once we tackle the problem of getting them into sid, they’ll get into testing quickly, and then the desktop users can be happy again.

    [ return ]


    Subject: Naming conventions
    Author: d8A90n
    Date: Monday, 2002/04/22 – 04:03
    Names don’t have to be made scary :o)

    What I’m arguing for is a different split of the tree. The stable/testing/unstable scheme is unweildy for developers, and annoying for users because they don’t get software they want in a timely fashion because the developers are overworked.

    I’m proposing a split into base/servers/desktop. Base should be as stable as stable is now. Servers should see a maybe 6 months release cycle with constant security updates. Desktop should have constant updates, like sid/unstable at the moment. To make things a bit more stable to the desktop tree maybe have an unstable desktop (like unstable) and stable desktop (like testing) where apps migrate from unstable to stable after a few weeks of testing.

    Hence, packages in `stable’ won’t need much more attention (except for security updates) than once every 2 years or so. Packages in `server’ will get their major update every six month (except for security updates) and packages in desktop will get updated constantly.

    Therefore you keep a stable and secure OS for servers, which usually don’t update that often to keep the up time, and you keep an up to date OS for those most vocal users by having desktop apps out in a few days/weeks and not months.

    Because packages in desktop won’t need any more attention than they’d always get, when things get close to the `stable’ or `server’ release, large packages don’t lag behind because developers of those apps don’t have to work their asses off to work on 3 packages at a time.

    My main argument against the current system is that *EVERY* package needs three versions of it. This scheme results in too many packages needing attention and is an uneeded strain on developers.

    [ Please login, or register ]

    Search articles

    ·News (182)
    ·Features (4)
    ·Site News (8)
    ·HOWTOs (38)
    ·Tips (5)
    ·Opinion (12)
    ·Q & A (19)
    ·Sponsorship (1)

    Log in


    Remember me

    » Register
    » New password

    Debian Security Announcements
    DSA-321 radiusd-cistron
    DSA-320 mikmod
    DSA-319 webmin
    DSA-318 lyskom-server
    DSA-317 cupsys
    DSA-316 nethack
    DSA-315 gnocatan
    DSA-314 atftp
    DSA-313 ethereal
    DSA-312 kernel-patch-2.4.18-powerpc

    Latest poll: My Favorite Woody Backport Repository
    KDE 3
    GNOME 2
    Mozilla 1.3
    No backports on my Woody

    Total votes: 412
    11 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.