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

Welcome to Debian Planet

News for Debian. Stuff that *really* matters

Sponsorship

DP is sponsored by Xinit Systems.

Domains paid for and hosted by uklinux.net.

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.

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

    Syndicate
    XML

    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: Should one person be responsible for such a huge package?
    Author: Anonymous
    Date: Thursday, 2002/04/25 – 01:26
    Should one person be responsible for sucha huge pacakge? I mean many people laugh at Debian because of lack of uptodate KDE and XFree86. Isn’t it just 2 people? One packaging KDE, and the other packaging XFree? Should the reputation of Debian hinge on two people? I think that large pacakges should get priority treatment at Debian, and packagers should team up. They could have a packaging party, where they all get together to compile KDE3 or XFree86 4.2.

    Just my 2.0001 cents.

    [ Please login, or register ]

    Subject: Re: Suggestions for Improving Packaging Efficiency?
    Author: d8A90n
    Date: Tuesday, 2002/04/23 – 22:36
    I was just wondering, are any of the suggestions put forth in this discussion will actually be implemented? I mean it’s nice to discuss it and all, but if it doesn’t even make it to -devel or higher up then it’s fairly pointless.

    I think the current packaging system could use improvements. Some of the ideas expressed here are excellent and I think would be great to make Debian even better for both the developers and the users.

    [ Please login, or register ]

    Subject: Re: Suggestions for Improving Packaging Efficiency?
    Author: Anonymous
    Date: Monday, 2002/04/22 – 12:12
    ok i have a question about the packaging process. I can’t really see much difference between x 4.2 and x 4.1 besides the extra drivers that some people are apparently really excited about. Do the maintainers really have to package the whole thing from scratch? Can’t the same package framework work? I mean should it take so long for something that really didn’t change drastically? Going from, x 3 to x 4 i can see there where some big changes, but x 4.1 to x 4.2 is just a couple extra drivers. Do they really have to start over from scratch? Can’t you just kinda plop the new binaries into the same packaging?

    One more thing, can branden just skip x 4.2 all together, i mean the xfree86 cvs shows the latest dev version is 4.2.99.1 so it looks like 4.3 is not going to be that far off. When woody comes out next month and x is getting packaged again i hope branden just skips x 4.2 if x 4.3 is out, why package it just to have it be obsolete before the package is even started?

    [ Please login, or register ]

     

    Subject: Re: Suggestions for Improving Packaging Efficiency?
    Author: robot101
    Date: Monday, 2002/04/22 – 16:49
    For most packages, you can apply the old diffs to the new version with little or no changes. But X isn’t most packages. A glance at the X changelog shows you that Branden has tens if not hundreds of patches to X to correct behaviour, change defaults, make Debian policy apply, and to make the damn thing work on all 10 architectures we’re planning to release Woody with. These patches have to be either merged, replaced or discarded, and in any case tested with the new version.

    That aside, the reason we don’t have 4.2 is that it was decided that we were too near to a release to have a new X version, so Branden has been concentrating on squashing the last bugs in 4.1 before release.

    If X 4.3 comes out after woody, I’m sure Branden will decide, depending how far he has got with X 4.2, whether to finish that up, or just switch efforts to 4.3.

    [ Please login, or register ]

     

    Subject: Re: Suggestions for Improving Packaging Efficiency?
    Author: Anonymous
    Date: Tuesday, 2002/04/23 – 01:03
    What kind of policy conflicts occur between X and debian?

    I get a little uncomfortable when debian ends up correcting behavior on the part of 3rd parties. If there are really blatent bugs & platform independance issues that are bad enough to prevent the software from being released under debian’s “unstable” distribution, shouldn’t upstream be that much more anxious to be fixing those problems as well? What could be done to synchronize the effort of debian developers with upstream more closely, taking advantage of the original developers’ man-hours, while contributing a user-base and quality bug reporting history?

    [ Please login, or register ]

     

    Subject: Re: Suggestions for Improving Packaging Efficiency?
    Author: chewie
    Date: Tuesday, 2002/04/23 – 15:41
    To upstream, Debian may not be “the standard”. Yes, Debian is the closest thing to LSH and LSB out there, and we’re quite anal about policy. Take lintian for example.

    It’s sometimes stifling to the upstream. No one likes to be told “HOWTO”, especially if you’re a “developer-type”. Debian turns out to be one of the largest, most ported test-bed for most software projects. This translates to a bit of respect and “clout” when things need to be changed, but it’s still not a baseball bat we can use to beat upstream into submission.

    Regardless of Debian’s infrastructure and distribution, upstream sometimes retains atomicity. The typical procedure for packaging, then, is to patch the source code into submission and send the patches upstream for integration at a later date/time. It’s really the only “polite” way of doing things.

    [ Please login, or register ]

     

    Subject: Re: Suggestions for Improving Packaging Efficiency?
    Author: Anonymous
    Date: Tuesday, 2002/04/23 – 16:06
    Well it’s not like linux is the only unix clone in the world, if you don’t even use linux you probably aren’t going to be thrilled to change your whole project just becuase of one low market share distro whining to you.

    I think following the LSB is excellent, i’m not defending the upstream behavior, but i can understand where they could be coming from on it though.

    [ Please login, or register ]

    Subject: Re: Suggestions for Improving Packaging Efficiency?
    Author: skaldrom
    Date: Monday, 2002/04/22 – 07:28
    I had a little idea lately and I wonder what the debian community thinks about: I am not a maintainer and I do not think I would not have the time to be a good one. But I could fix a bug every now and then. I think, several friends of mine may be in the same situation.
    How about a “bug fixing group”. Maybe just a central website with exact description how a bug shall be fixed and who should be contacted. Also a general description on how to get to the bug reporting system. In short: all the information needed so that the people can concentrate on working and do not have to do the “paperwork”….
    [ Please login, or register ]

     

    Subject: Re: Suggestions for Improving Packaging Efficiency?
    Author: robot101
    Date: Monday, 2002/04/22 – 16:52
    Every bug has it’s own e-mail address to which anyone can mail suggestions, sucessful or failed reproductions, patches, whatever. The system is, by the very nature of the project, totally available and open for anyone to contribute.
    [ Please login, or register ]

     

    Subject: Re: Suggestions for Improving Packaging Efficiency?
    Author: Anonymous
    Date: Monday, 2002/04/22 – 09:30
    following http://bugs.debian.org// is not too hard…
    [ Please login, or register ]

    Subject: Re: Suggestions for Improving Packaging Efficiency?
    Author: Anonymous
    Date: Monday, 2002/04/22 – 05:01
    I think we are seeing the difference between server/console type apps and gui applications. With the skill level and complexity in opposing curves. If a new, say iptables, or even a single app, I can either wait or easily download the source and compile. KDE is so large that most won’t download and compile. Add to that the skill level of gui users generally, you end up with a bad mix.

    Krusty did a fantastic job, maybe too good, and couldn’t maintain. Now we have someone who has less time to devote to it, other packages, etc.

    And KDE moves very fast. This is the fourth release in what, two years. For a huge and complex package.

    And stable just about to be released.

    I think the complainers should shut their mouths. If they want to use kde3, compile it yourself.

    We will see kde3 in a little while and this fuss will be forgotton. Unless we all piss the packagers off so much they quit.

    Remember everybody. If you intend to harass a maintainer and he quits, are you responsible?

    Derek

    [ Please login, or register ]

    Subject: Some more suggestions
    Author: d8A90n
    Date: Sunday, 2002/04/21 – 22:54
    Something else that I’ve thought of. I don’t know because I’m not a developer, but I’ve run into issues of having to compile a large program.

    Correct me if I’m wrong but for large packages like X, Gnome, OpenOffice, KDE, etc. doesn’t it take a quite a bit of time to make the package actually work? I mean: “develop, compile (several hours), install, test (broken), fix, compile (several hours), install, test (broken). This can take A LOT of time to do for a developer. The longer the build process is, the more time it takes to the developer because it takes time to get back into it after 5-6h, or a couple of days depending on their computing power and their availability when the building is finished.

    Maybe having some kind of distributed.net kinda scheme where developers keep their source on a central server and add it to a build queue which has it compiled by thousands of computers in no time, so they can test it more quickly and cut down on packaging time. I don’t know how easy it would be to set up a client like this for users but I’d willingly give my spare CPU cycles to debian.

    Another idea would be to refine the packaging tools. I don’t know how they work because I’m not a developer myself, but I’m sure there’s a way to automate some things better, or make the tools easier to use or more complete. Again, I know the user tools (apt-get/dpkg) are awesome and practically can’t get any better but maybe the dev tools need some refinement.

    [ Please login, or register ]

     

    Subject: Re: Some more suggestions
    Author: Anonymous
    Date: Monday, 2002/04/22 – 16:46
    Personally I think its a very interesting idea. I have a P4 here thats on pretty much all the time and is wasting a *lot* of its power. I would be *happy* to allow debian package maintainers to use its spare power…

    Is this possible though? I’m not sure as to the mechanics of compiling, but is it possible to split it up like that?

    Does someone know?

    [ Please login, or register ]

     

    Subject: Re: Some more suggestions
    Author: Integral
    Date: Monday, 2002/04/22 – 17:11
    Is this possible though? I’m not sure as to the mechanics of compiling, but is it possible to split it up like that?

    It certainly is, but with no disrespect intended, the security implications are…uh…horrifying, to say the least.

    Daniel

    [ Please login, or register ]

     

    Subject: Re: Some more suggestions
    Author: Anonymous
    Date: Tuesday, 2002/04/23 – 05:50
    MOSIX, man, MOSIX
    [ Please login, or register ]

    Subject: Suggestions for Improving Packaging Efficiency?
    Author: d8A90n
    Date: Sunday, 2002/04/21 – 22:14
    I have an idea about how to improve packages efficiency, give a break to the developpers and make users happier.

    The current system of stable/testing/unstable is great for pretty much only servers. I’ve been running unstable for about 2 years now and it’s been seriously broke (can’t log in) only twice in that time.

    My point is that maybe it’s not as useful as we may think to have ALL the packages in stable, ALL the packages in testing and ALL the pacakges in unstable. Maybe the trees should be split differently.

    Having for example server critical apps (all the required base packages, ftp, proxy, http, whatever packages are used by servers) make the Stable Debian GNU/Linux. Because X, KDE, Gnome, etc. aren’t often used on servers and therefore don’t need the SUPER DUPER EXTRA security and stability, then maybe it’s not worth the effort to put all in this time and maintaining three versions.

    What I’m coming down to is maybe it would be more practical to have some packages which need the extra security and stability to require more care and hence be part of a timely Debian new release. And then all the other packages could simply be extras which are updated all the time.

    [ Please login, or register ]

     

    Subject: Re: Suggestions for Improving Packaging Efficiency?
    Author: Anonymous
    Date: Wednesday, 2002/04/24 – 03:31
    I dont even think it is great for servers , over the last year and especially in the last 6 months we have increasingly been installing or switching servers to Woody (we are a large NZ isp running debian on ~50 boxes) to take advantage of features in it.

    I think a year between realises for servers is desireble ..

    I dont know what should happen but one idea I had was for us to have *.0 realises every year or so aimed at servers and *.5 etc realises in between the server realises for desktop users

    [ Please login, or register ]

     

    Subject: Re: Suggestions for Improving Packaging Efficiency?
    Author: Anonymous
    Date: Monday, 2002/04/22 – 06:24
    I use Potato on my laptop, which certainly isn’t a server. I want it to just work, and be secure, and I don’t want to have to do any fussing with it to make it so. Seriously broken twice in two years is too much for me. Has unstable been less seriously broken too? Potato has given me the ability to forget about my os and get some work done. I haven’t had to waste time on administration since I got this going. Every time I go on line, I su and type apt-get update;apt-get -u upgrade and my chores are done. Nothing breaks, and that’s what I need. Since this is a workstation, I do need X for reading postscript and dvi files.I really think that it would be a bad idea to lower Debian’s standards to match Mandrake’s. Mandrake is nice, but has more hassles than I needed. I’m happy to wait for the maintainers to file the rough edges off, and I haven’t really felt hampered by not having bleeding edge stuff.
    [ Please login, or register ]

     

    Subject: Need to update? I don’t think so…
    Author: d8A90n
    Date: Monday, 2002/04/22 – 15:16
    Let me clear some things up for you.

    By seriously broken, I mean packages which are vital to the distro (like ldap for log-in). In my idea of packaging scheme, these kinds of packages which would be vital to the OS would only update about every one or two years or for security updates.

    As for updating, if you’re using potato I don’t see why you bother for anything but security updates… which brings the point that people using Debian’s “desktop” apps shouldn’t update every package all the time. They should only update when they need it (like radeon 8/7500 drivers in x4.2, etc…) or when they want a new app (like kde3, etc.). This way, if a package is broken you won’t notice because you didn’t update it and the one you have works (unless you’re unfortunate enough to update a package that is broken… which doesn’t happen often anyways — probably much less often than Mandrake or RedHate)

    In this sheme of things, having two trees (“stable desktop” and “unstable desktop”) would be great. “Stable desktop” wouldn’t require any work. The way I see things, packages in “unstable desktop” would be transfered automatically into “stable desktop” after two weeks if the package has no bugs reported for that version of the software. In this way, developers can concentrate more on releasing quality packages for unstable, and the overall quality of bleeding edge packages will increase tremendously.

    Having “stable/unstable” desktop scheme also allows to easily downgrade to stable if an unstable app breaks. Stable would break maybe once every 3 years or so. In which case when something breaks in stable developers would also have the possibility of fixing the unstable version and flushing it to stable right away. Again, they’d only need to keep track of one version.

    Archive could also keep track of some of the most stable versions, or things like x3.3.6 which is important for some people with old video cards.

    If you remove the strain of having to keep 3 different packages, developers will be happier, will have more free time, will release faster and release better quality packages.

    What do you think now?

    [ Please login, or register ]

     

    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.

    [ Please login, or register ]

     

    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 ]

    Subject: Re: Suggestions for Improving Packaging Efficiency?
    Author: Anonymous
    Date: Sunday, 2002/04/21 – 14:57
    Ask Kitame. That guy is a bad ass packager. You never hear people bitching about his packages being late. And you never see him flame anyone. Kitame is an awesome maintainer.
    [ Please login, or register ]

     

    Subject: Re: Suggestions for Improving Packaging Efficiency?
    Author: Anonymous
    Date: Monday, 2002/04/22 – 06:34
    hear hear on kitame’s packages! that guy is a machine!
    [ Please login, or register ]

     

    Subject: While we are on the subject
    Author: Anonymous
    Date: Sunday, 2002/04/21 – 18:17
    Chris Halls too. He developes the apt-proxy package. I don’t think he’s official yet but he certainly rules it. He personally took about an hour+ of his time to help me work thru some package building/compiling problems… and it had nothing to do with his package!

    Not to mention all of the quick responses I get via email from maintainers (exim, mysql, qpopper, mozilla).

    Thanks guys!

    simon lewis

    ps- Maybe we can improve communication between developers/maintainers and or packagers to the community on a guestimated timeline of when new packages will be delt with etc. This really seems to be a communication issue, doesn’t it?

    [ Please login, or register ]

    Subject: Re: Suggestions for Improving Packaging Efficiency?
    Author: jw
    Date: Sunday, 2002/04/21 – 12:30
    After reading through quite a few of the replies to the original KDE post, it seems that one of the biggest issues is the lack of information provided for user on package release plans.

    Surely it would be easy to set up a section on debian.org which gives the current packaging progress on the big package groups (and possibly others).

    Such information as:

    • current version in sid
    • current upstream version
    • current packaging issues
    • proposed release date
    • beta versions available (if any)

    I don’t mind waiting to get a quality package, but like everyone I’d like to know what is going on. I think this is a way that debian can provide more for the users, and maybe cut down the attacks on maintains so that they can get on with their job.

    Jeff

    [ Please login, or register ]

     

    Subject: Re: Suggestions for Improving Packaging Efficiency?
    Author: Anonymous
    Date: Sunday, 2002/04/21 – 18:19
    Usually you can just do a search the packages on debian.org to find out what version of which package is which tree.

    cheers,
    simon

    [ Please login, or register ]

     

    Subject: Re: Suggestions for Improving Packaging Efficiency?
    Author: jw
    Date: Monday, 2002/04/22 – 19:35
    Yes, I know that you can find out the current versions in the trees, that wasn’t really my point. Having the sid version there was just for convenience really.

    The important pieces were current version being packaged, packaging issues and a proposed release date – that is information you can’t find on debian.org currenly, at least not without some deal of effort.

    [ Please login, or register ]

     

    Subject: Pointless
    Author: d8A90n
    Date: Sunday, 2002/04/21 – 22:41
    That’s pointless. They can also do `apt-get update; apt-get install package; dpkg -l | grep pacakge` to see what’s the latest available version.

    I doubt that’s what the users want. The users I think want more open communication from the developper’s part. Know what’s going on, what’s keeping them from releasing packages if that happens, or where they are in the process of packaging a new version (ie. just started and will be finished in 2 months or almost finished and it should only be a couple of days)

    [ Please login, or register ]

     

    Subject: Re: Pointless
    Author: jw
    Date: Monday, 2002/04/22 – 19:43
    Did you read my comment? I didn’t propose a method for users to know the latest version in the archive, but rather a formal method for the maintainer to communicate packaging process.

    So your ideas were that maintainers should provide:
    1) what’s keeping them from releasing packages
    2) where they are in the process of packaging a new version (ie. just started and will be finished in 2 months or almost finished and it should only be a couple of days)

    These are obviously much better ideas than my “pointless” ideas of listing
    1) packaging issues
    2) proposed release date

    I hope the sacasm was noted.

    [ Please login, or register ]

    Subject: KDE’s woes
    Author: ndogg
    Date: Sunday, 2002/04/21 – 08:31
    Does anyone realize that this is the second time that Debian is having problems with KDE?

    I don’t exactly know the problems (if any) behind the motivations of Ivan’s departure, but I wonder if it had anything to do with the immensity of the KDE packages.

    I wonder if KDE’s woes have more to do with all of its related packages…?

    [ Please login, or register ]

    Subject: Re: Suggestions for Improving Packaging Efficiency?
    Author: Anonymous
    Date: Sunday, 2002/04/21 – 01:34
    Hmmm, i can’t say i have any ideas of my own right now. But looking at how the BSDs do it may offer some techniques to make releases of both packages and the whole distribution a little faster. The BSDs tend to have very rigid and usually fast release schedules and i don’t think anyone can legitamtly claim freebsd or openbsd is unsecure or unstable.

    People will say debian is non-profit so it doesn’t need to put out new versions all the time. But i say since it is non-profit and has an excellent upgrade system why not release more often? For profit distros can only release so often otherwise customers will get sick of buying a new version all the time and they tend to have clumsy upgrade systems. So i think debian being non-profit and having an excellent upgrade system means it should be releasing all the time. But in order to keep stability high this would slow it down a bit, so i don’t see why debian couldn’t meet the two at a equilibrium close to the BSDs for 6 months or a year.

    Open Source software moves fast, if you get stuck with the same version for 3 years you’re missing some of the advantage.

    [ Please login, or register ]

     

    Subject: Re: Suggestions for Improving Packaging Efficiency?
    Author: Joy
    Date: Sunday, 2002/04/21 – 11:08
    Stop lowercasing Debian and mentioning “3 years” without an example. People will think you are a troll. You wouldn’t want that, now would you? >
    [ Please login, or register ]

     

    Subject: Re: Suggestions for Improving Packaging Efficiency?
    Author: Anonymous
    Date: Sunday, 2002/04/21 – 14:09
    Oh sorry by the time woody is released as stable it will only be 2 years and 6 months, pardon me!

    (and that’s assuming it’s actually released on the estimated release date, which is rather unlikely)

    (and that’s also assuming the software in the last release wasn’t already several months old to begin with)

    so 3 years is probably more realistic i guess…

    [ Please login, or register ]

     

    Subject: Re: Suggestions for Improving Packaging Efficiency?
    Author: Joy
    Date: Sunday, 2002/04/21 – 16:11
    Okay, let me get this straight. Potato (r0) was released on 2000-08-14. Woody (r0) will likely be released around 2002-05-01. Doesn’t it seem to you that there’s an extra year in your calculation? 😛
    [ Please login, or register ]

     

    Subject: Two Years!#@ WTF???
    Author: Anonymous
    Date: Sunday, 2002/04/21 – 18:33
    Ok two years is still a hell of a long time. And it’s not like with release(s) r1-r5 you had any “package update”… To my knowledge the only things that make it into those releases are security fixes and release critical bug fixes. Release 5 was primarly all security updates anyways.

    So my point is two years is too much. No pun intended. Atleast for a desktop/workstation machine. I don’t mind running a server like that, but as for a desktop I think we all want a up to date desktop enviroment, xf86, libc6, etc…

    I think the best suggestion I have heard on this subject is to use testing as a desktop tree and “stable” as the defacto server tree. The Desktop set of packages doesn’t even have to be just “testing”, it could be testing with security updaptes or something. It is certainly stable enough. Hell sid is pretty damn stable at that. So I don’t know. Compromise anyone?

    simon lewis

    [ Please login, or register ]

     

    Subject: Re: Suggestions for Improving Packaging Efficiency?
    Author: robot101
    Date: Sunday, 2002/04/21 – 03:37
    The advent of testing means two things become possible, firstly that at any time you can take a snapshot of testing and release it, and that it will mostly work, because the system is conservatively designed that the number of bugs in testing goes down, not up. After we squash bugs in testing, the hope is that the number will stay down, so we’ll be able to release at more like the generally agreed 6 monthly rate.

    The second is a more strange thing, the idea that the majority of people will not use a release at all. With some work in the area of security updates, the majority of people could actually just use testing on a full time basis. I know I already do on all of my machines, there comes a time where potato is just too old. If we can support testing as well as we can a stable release, all we need to do is release CDs and installers every 6 months, and point everyone to testing. Now that would *rock*. =)

    [ Please login, or register ]

    Subject: What’s the hurry
    Author: elcrago
    Date: Sunday, 2002/04/21 – 01:02
    Is the delay so incredibly long that it’s really a problem, or are people spoiled?

    For all the packages I care about the packaging lag is a few months or less. I haven’t seen a convincing argument as to why this is a problem.

    Whoever those complainers are out there, I suggest they either build their own distro, help out with patches, or STFU.

    [ Please login, or register ]

     

    Subject: Re: What’s the hurry
    Author: Anonymous
    Date: Sunday, 2002/04/21 – 14:14
    Forum maintainers: please correct the spelling of “insightful” (it appears with no t).

    As to the “why can’t we wait, why are we so impatient” vs. “we deserve the latest packages” question, it’s a flamewar that will go on and on, because we’re not perfect. The maintainers aren’t perfect. All we can do is try to address the issues in some way, and it seems that there will be some serious consideration of this issue once (if) woody releases.

    [ Please login, or register ]

     

    Subject: Re: What’s the hurry
    Author: Anonymous
    Date: Sunday, 2002/04/21 – 09:33
    Look, the Debian project is a community project, for it’s community of users. The distro is updated and released for… the community.

    So if the community wants a faster release schedule, or whatever it maybe the project is obligated to listen and incorperate those changes. Because if Debian isn’t done for it’s users, then it should close down the public apt servers.

    Please don’t tell me to start my own distro. Thats the most unreasonable thing I have ever heard. I’m sure everyone is capable of that, and even the people who are would want to do that.

    I encourage you to look at your defense mechanism of completely shutting off to debate. It’s ok to have different opinions and be critical, really it is. You don’t need to get caught up in the game of defending your self out of an emotional reaction because you are obviously insecure about receiving a contradicting view to your own. It really makes everyone involved with Debian look really immature and stupid.

    So please stop on our behalf, if not for your own “personal growth”.

    Regards,

    simon lewis.

    [ Please login, or register ]

     

    Subject: That makes no sense
    Author: elcrago
    Date: Monday, 2002/04/22 – 10:02
    I’m not a package maintainer, never have been. I have nothing to be defensive about. Your attack is utterly meaningless in this context.

    My post came from frustration with people posting on mailing lists and sites like this, complaining about things they would never lift a finger to do anything about themselves, but accusing the targets of their complaint of slacking. I’m tired of reading about what some whiny bastard wants someone else to do for them. It reminds me too much of social programs.

    [ Please login, or register ]

     

    Subject: Re: What’s the hurry
    Author: Anonymous
    Date: Monday, 2002/04/22 – 04:25
    Look, the Debian project is a community project, for it’s community of users. The distro is updated and released for… the community.

    So if the community wants a faster release schedule, or whatever it maybe the project is obligated to listen and incorperate those changes. Because if Debian isn’t done for it’s users, then it should close down the public apt servers.

    But the developers of Debian are its users, too; this distribution is for them as much as it is for us.

    You make it sound like there’s an artificial distinction of “them” providing a service for “us”, and you assume because some vocal users are complaining that KDE 3/XFree 4.2 packages aren’t ready to go yet, that “they” are not providing “us” the sevice we “deserve”.

    Others try to hold the developers’ good intentions hostage against them; “well, they volunteered to maintain those packages, they have an obligation to give us what we want and have to listen to us piss and moan and insult them and belittle them until we get it.” Let me tell you something; as a person who’s worked 5 years in retail/customer service, I can tell you that “service” does NOT entail “kissing the ass of the whiny bitchy customer.” I have told customers that they’re being rude, that they’re being unreasonable and that they shouldn’t expect me to do any extra favors for them when they’ve done nothing but insult or attack me. And I’ve been right to do so, because to do otherwise is to encourage more laziness or bad behavior on their part.

    The same goes for Debian developers; yes, they’re providing a service to the whole community, and yes, that has some obligations. But if they spend all of their time responding to every flaming idiot that comes their way, then it encourages the non-developer (dare I say “non-contributing”?) users that acting like a jerk is the best way to get what you want. Then we won’t have any developers, because no one in their right minds would want to put up with the hassle.

    If there is a problem with the speed of packaging, or the stable release schedule, then the users (that includes the developers, remember) need to work together to come up with a solution; but as far as I’m concerned Debian is the LAST distribution in the world to be an armchair quarterback for.

    Jay (=

    [ Please login, or register ]

     

    Subject: Re: What’s the hurry
    Author: Anonymous
    Date: Sunday, 2002/04/21 – 16:33
    The Developers are putting in alot of time to build a quality OS. After reading the mailing list archives and studying the philosophy of the Debian distribution, it is easy to see, they are doing an excellent job. There are processes that can be improved, but that is to be expected in any large project. Debian has committed Developers.

    The Users are also committed to Debian. Two of the most visible User projects are “I want” and “Help me”, these projects rival some of the best Developer projects. Another fine User project that has received attention lately is the “This is what you should do” project. This is a well intentioned project, lead by what appear to be, some very fine sidewalk supervisors.

    So there are a handful of User projects and thousands of Developer projects. Which group are you planning to help?

    Debian needs constructive Users, that are interested in starting projects that help the Debian community. These projects shouldn’t rely on the Developers for support, but support the Developers and themselves.

    The Users need to develop (invent?) themselves.

    Doug Jensen
    Debian User

    [ Please login, or register ]

     

    Subject: Re: What’s the hurry
    Author: Anonymous
    Date: Sunday, 2002/04/21 – 13:45
    Ya i’ve already decided i’m not building any new debian boxes. The existing ones will stay, i’m not gonna make a bunch of work for myself. There’s no way i’m gonna put debian on any new machines though. The debian community never ever listens to the users. That’s not good. Plus they think debian is perfect, it’s good, but far from perfect. The kind of people drawn to this project tend to be immature, emotional, needy and just generally annoying little shits. Who the hell wants to put up with that crap?
    [ Please login, or register ]

     

    Subject: Re: What’s the hurry
    Author: lordsutch
    Date: Monday, 2002/04/22 – 08:54

    The debian community never ever listens to the users.

    Ah, that must be why I have been completely ignoring wishlist bugs. I mean, seriously, does any other distro even solicit wishlist items?

    [ Please login, or register ]

     

    Subject: Re: What’s the hurry
    Author: robot101
    Date: Sunday, 2002/04/21 – 01:23
    People are spoiled, definitely, by other distros that come out with new software and new releases more quickly, for a variety of reasons, like they have less architectures to support, they are paid to update the packages and have other people in the company to deal with bugs and stuff, they have poor QA, they have a fast release schedule, or just one that is designed to ignore the reliability of the packages they ship, or finally they have someone in the upstream of X to make sure they’re out with a new distro release after every X major release. Naming no names, of course.

    I think you’re being overly harsh on people. There are some valid reasons to want to see a new upstream release.

    In the case of X4.2, people have a right to be antsy. It supports a lot of the hardware that X3 does which was dropped for the sake of a timely X4 release, and does so with better functionality and features like DRI which people have been waiting for some time.

    Some other packages such as Gnomemeeting lag critically behind because the maintainer has agreed something with the upstream which the upstream then fail to do. In which case, they have nobody but themselves to blame for inconveniencing their users.

    With KDE3, I can’t see as much of an excuse. KDE2 is by no means ancient or broken, and KDE3 isn’t a release that adds a critical amount of long-needed features.

    I only cite these examples because they have been cited to me as complaints with Debian, or even reasons for switching away to Gentoo or such. Lots of other complex packages like GNOME, Mozilla, gcc, glibc, etc, are updated in a timely manner, and nobody complains – it’s natural that the people who do complain about the few that do get held up will make more noise than everyone else who is happy. It’s their right to complain, and it’s ostensibly our right to keep on doing what we do for the reasons we do it, regardless of what people say. I just wish it didn’t suck up so much of people’s time.

    [ Please login, or register ]

     

    Subject: Re: What’s the hurry
    Author: elcrago
    Date: Monday, 2002/04/22 – 10:11
    XF4.1 is in woody. XF4.2 is not. If we were talking about 3 vs 4, I would be right along with you, but 4.1 has been out for a long time, and 4.2 has not.

    http://lists.debian.org/debian-x/2002/debian-x-200204/msg00035.html

    [ Please login, or register ]

     

    Subject: Re: What’s the hurry
    Author: Anonymous
    Date: Sunday, 2002/04/21 – 14:05
    x 3.3.6 isn’t even being maintained any more as of last winter, stable is so freaking old the version of x isn’t even maintained anymore…yikes.
    [ Please login, or register ]

    Subject: Re: Suggestions for Improving Packaging Efficiency?
    Author: Anonymous
    Date: Sunday, 2002/04/21 – 00:01
    At least part of the issue, i think, goes back to problems with debian’s stable release schedule. When a new “stable” is coming up, more then any other time, developers spend their time working on making old versions of software work better, so that they won’t get kicked from stable. Meanwhile, new versions of the software are released, and the maintainer gets behind, and actually has to spend time catching up.

    Maybe the “stable/testing/unstable” philosophy of debian’s releases needs to extend to the maintainers as well? A maintainer to bring in changes from upstream (unstable), a maintainer to deal with release issues (stable)… I’m not sure how a maintainer at the “testing” level would make sense, but then again this is just a random idea I’m throwing up. Thoughts?

    [ Please login, or register ]

     

    Subject: Re: Suggestions for Improving Packaging Efficiency?
    Author: robot101
    Date: Sunday, 2002/04/21 – 00:24
    Sounds inherently sensible – after all it is what they do with kernels. Linus breaks stuff at the cutting edge, and palms it off to Marcello or Alan when he’s had enough, and they bring it under control. If only we could fork() and have the parent work on the unstable versions, and the children work on maintaining the older versions. Makes it sound a bit like slave labour though. =)

    Maybe a guy for stable is overkill – little effort is required except for security releases which are handled by their team, but a maintainer at “testing” level makes sense if a new upstream version isn’t suitable for the upcoming release, like with KDE3 or X4.2 for woody.

    If the unstable guy (no pun intended, Branden =) worked on the new version, perhaps uploading to experimental, and someone else could work on squashing bugs in the pending-release version, uploading to unstable, Debian would have less criticism levelled towards it for being slow to adopt new upstream versions.

    Maybe this could all fit in with the CVS’d packages idea by having branches for released versions to ease syncing up and avoiding duplicated effort.

    [ Please login, or register ]

     

    Subject: Re: Suggestions for Improving Packaging Efficiency?
    Author: Anonymous
    Date: Sunday, 2002/04/21 – 00:28
    Well, a guy for stable is critical in the months preceeding a new debian stable release anyways. Unless we’re just stuck on a vocabulary gap.
    [ Please login, or register ]

     

    Subject: Re: Suggestions for Improving Packaging Efficiency?
    Author: robot101
    Date: Sunday, 2002/04/21 – 01:13
    Probably the latter. We only call a release stable after it’s been released. I think you’re meaning a testing guy.
    [ Please login, or register ]

    Search articles



    Category
    ·News (363)
    ·Features (5)
    ·Site News (15)
    ·HOWTOs (66)
    ·Tips (18)
    ·Opinion (27)
    ·Q & A (28)
    ·Sponsorship (1)
    ·Press Releases (4)

    Log in
    Username:

    Password:

    Remember me

    » Register
    » New password

    Debian Security Announcements
    DSA-777 mozilla
    DSA-776 clamav
    DSA-775 mozilla-firefox
    DSA-774 fetchmail
    DSA-773 amd64
    DSA-772 apt-cacher
    DSA-771 pdns
    DSA-770 gopher
    DSA-769 gaim
    DSA-768 phpbb2

    Planet Debian
    Martin F. Krafft: Vegetables!
    Amaya Rodrigo: Hackergotchi Paradise!
    Anthony Towns: Birthdays!
    Wouter Verhelst: New bugs.d.o layout
    Wouter Verhelst: Where’s my print?
    Julien Danjou: NetBSD/Xen unstable 🙁
    Wouter Verhelst: Understatement.
    Hanna Wallach: birthday!
    Erinn Clark: This is how we chill from ’93 ’til…
    Erich Schubert: Rant about XML, XSLT, CSS, …

    Debian Administration
    Apache/perl package install and testing (e.g. mod-perl and Mason)
    Searching MySQL databases with fulltext indexes
    The Debian Bug Tracking system gets upgraded
    Changing the timezone of your Debian system
    An introduction to run-levels
    Analyzing boot performance with bootchart
    Question: How to move Debian network from static IP to DHCP
    Unattended, Encrypted, Incremental Network Backups: Part 1
    Setting up multiple Subversion repositories
    Maintaining apache2 sites and modules lists

    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.