Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×

Anthony Towns Elected New Debian Leader 69

Posted by ScuttleMonkey from the there's-a-new-sheriff-in-town dept.
daria42 writes "Australian developer Anthony Towns has just been elected Debian Project Leader starting 17 April. In his platform for election, Towns said the most important issue for Debian was 'increasing its tempo'. 'We've been slow in a lot of things, from releasing, to getting updates in, to processing applications from prospective developers, to fixing bugs, to making decisions on policy questions, and all sorts of other things,' he said."
This discussion has been archived. No new comments can be posted.

Anthony Towns Elected New Debian Leader More

Anthony Towns Elected New Debian Leader

Comments Filter:

  • Comment removed (Score:5, Funny)

    by account_deleted ( 4530225 ) on Monday April 10, 2006 @06:19AM (#15098205)
    Comment removed based on user account deletion
    • As the old saying goes, "Hell freezes faster than Debian Stable". Good to see that Towns intends to take action.

      The three main BSD projects are comparable to Debian, yet they manage to get their releases out on a (fairly) regular basis.

      • Re:Slowness (Score:1, Insightful)

        by Anonymous Coward
        The three main BSD projects are comparable to Debian, yet they manage to get their releases out on a (fairly) regular basis.

        The only one I have any experience with is FreeBSD, and I can say for a fact that I would never dream of using an X.0 release of FreeBSD. Since I've started following their progress, it's always taken till at least X.4 before a major version was stable enough to consider for serious use.

        This is in no way comparable to Debian, which prefers to wait six months longer and then get things

        • Re:Slowness (Score:3, Informative)

          by Homology ( 639438 )
          The only one I have any experience with is FreeBSD, and I can say for a fact that I would never dream of using an X.0 release of FreeBSD. Since I've started following their progress, it's always taken till at least X.4 before a major version was stable enough to consider for serious use.

          OpenBSD has a different release policy (i.e. a release every six months) that works very well. The 3.9 release is coming 1th of May, but the release in November will have version 4.0. Of course, someone had to ask if 4.0

          • OpenBSD supports an impressive list of 16 arches. Debian supports 11 arches. However, Debian and OpenBSD use different definitions of "support."

            OpenBSD is officially supported on the following [16] platforms. Official support means that the release install media is known to work, that the architecture can self-compile itself, and that most of the basic tools exist on the architecture.

            So for OpenBSD this means that they have working installer, you can compile your own kernel on your own box and most of t

            • Re:Slowness (Score:3, Informative)

              by Homology ( 639438 )

              So for OpenBSD this means that they have working installer, you can compile your own kernel on your own box and most of the basic tools exist (emphasis mine.)

              It's requirement for a supported arch that not only the kernel, but userland (including thirdparty applications like perl, Apache httpd, BIND, Sendmail, gcc toolchain and more) must also be built natively: cross-compiling is not sufficient to claim support, unlike some other OS that shall be unnamed. Some archs, like vax, is limited by hardware, wh

  • I guess things will heat up for debian now....

    • Re:Good Move (Score:4, Insightful)

      by babbling ( 952366 ) on Monday April 10, 2006 @06:31AM (#15098228)
      What makes you think that? I mean, sure, he stated that he wants to get releases out quicker, but that doesn't necessarily mean he will be able to. I imagine that has more to do with the independent, unpaid Debian developers rather than the project leader. It's rather likely that the previous Debian project leader also wanted a shorter release cycle.

      This is one of the problems with free software. If developers are less accountable, fixed release dates are more difficult to achieve. On the other hand, almost all proprietary software seems to be facing the same problem, and sometimes to a greater degree...
      • I think the slowness of Debian has a lot to do with the endless discussions, too. I don't say they're irrelevant or obsolete but they can get very lengthy (and sometimes repetitive) on some topics. In effect some decicions take longer than expected and schedule's getting out of control. Nevertheless, I'm a happy Debian user.
        • I'm a happy Debian user, too. I just thought I should point out that a leader who wants quicker release cycles doesn't necessarily imply quicker release cycles.
      • What makes you think that? I mean, sure, he stated that he wants to get releases out quicker, but that doesn't necessarily mean he will be able to. I imagine that has more to do with the independent, unpaid Debian developers rather than the project leader.

        Unlike the equally unpaid Gentoo Developers who manage to make 2 releases every year, and at point even did 4 (but that was, i admit, too much work).

        • It's because the binary packages of Debian require you to install 500 packages just to get a window manager, and 150 more for the development packages if you want to *do* anything with them. They also have neutered support for things that less people use, so if you use something rare, like Kerberos with SSH, you're screwed.

      • Best intentions... (Score:4, Insightful)

        by QuaintRealist ( 905302 ) * <quaintrealist&gmail,com> on Monday April 10, 2006 @08:01AM (#15098458) Homepage Journal
        I'd have to agree with you. One of the main reasons Debian has been slow to update has been the range of architectures and applications they attempt to simultaneously support. Other distros update faster, but most of them take one of two paths: a) limit supported architecture (usually to the x86 and x86 64) or b) support only a small subset of applications.

        Really, as much as I'd love to see Debian update faster, I'd hate to see them take one of those expediencies to get the job done.

        • Re:Best intentions... (Score:3, Insightful)

          by Dan Ost ( 415913 )
          The reason why Gentoo can release predictably and why Debian can't is that Gentoo allows
          different profiles for different architectures (Gentoo 2006.0 may have different stable versions for an app for different architectures, assuming the app is available for both
          arches in the first place) while Debian requires that the stable profile for each arch is
          synchronized.
        • I'd hate to see them take one of those expediencies to get the job done

          I wouldn't. Who cares if new releases still work on Alpha? If that slows down the other 99% of the world then drop it, and leave it to a specialized subproject to deal with. The three people who care can work on it.

  • Joke (Score:5, Funny)

    by zaguar ( 881743 ) on Monday April 10, 2006 @06:28AM (#15098220)
    For those who were wondering, voting started in 2001. He was elected today because the commitee wanted to make sure the candidates were 'stable'.

    • Re:Joke (Score:5, Funny)

      by wild_berry ( 448019 ) on Monday April 10, 2006 @06:45AM (#15098255) Journal
      You forgot to mention that the candidates were also frozen for bugfixing. Towns has only lost two fingers to frostbite; the debian-privates e-mail list suggests that another candidate lost something more personal and delicate.
    • For those who were wondering, voting started in 2001. He was elected today because the commitee wanted to make sure the candidates were 'stable'.

      If we had only used that method in choose the current US President ...

      • Re:Joke (Score:1, Offtopic)

        by Bob Uhl ( 30977 )
        Bush unstable?!? Have you seen Gore lately? The man's gone off the deep end.

        And as for Bush, he appears to be a level-headed fellow.

  • What is this "Debian" you speak of? Is it more like Ubuntu, or Fedora?

    (yes, it was a joke)
  • They should remove 99% of the packages from the core distribution and go with a simple small set of base packages for each release. Then switch to a 6 month release schedule like many other projects are using. All those other packages can go into an "extra" repository or something.

    I think even Ubuntu tries to put too many packages in the base release. They should take a hint from the BSD distros which use this method with the base install and ports. Hell, Windows uses the same method. After installing

    • Worst idea ever? (Score:5, Insightful)

      by babbling ( 952366 ) on Monday April 10, 2006 @08:20AM (#15098516)
      Why? I'm a Debian user, and I appreciate how well EVERYTHING works. I'd hate for them to sacrifice the quality of most of the software I use just so they can release twice as often.

      I don't really trust distributions that guarantee a release every 6 months, because I get the impression they must be rushing things. I'd prefer something quality, even if it's usually "behind the pack".
      • It's not rushing if you work off a small core (see OpenBSD). I would rather have a really stable up-to-date system than 1000's of packages I don't use.

        They just can't make everything work stable when there are thousands upon thousands of packages, that's why it takes so long to release anything. In the meantime we're stuck with either an incredibly outdated system or running the unstable branch that changes way too often and sometimes breaks (not good for servers or media boxes and similar).

      • Re:Worst idea ever? (Score:3, Informative)

        by Bogtha ( 906264 )

        Why? I'm a Debian user, and I appreciate how well EVERYTHING works. I'd hate for them to sacrifice the quality of most of the software I use just so they can release twice as often.

        The idea isn't to skip testing, the idea is to decouple the release schedule of the OS from the release schedule of the applications. So long as the base Debian system maintains compatibility between releases (and I was under the impression it did), it shouldn't matter to the applications when new versions of the OS is rel

        • The idea isn't to skip testing, the idea is to decouple the release schedule of the OS from the release schedule of the applications.

          So not only should the package maintainers test for OS release X, but also for several other releases as well. In addition there will be updated packages that needs testing. Nice idea, if you are willing to pay the (mostly) unpaid package maintainers to do this. Do you?

          • Package maintainers don't do the majority of the testing as it is, that's what the 'unstable' and 'testing' distributions are for. Or are you under the impression that each and every package maintainer has a computer of each architecture supported by Debian dedicated to testing? Testing has always been a distributed task.

            Did you miss the part of my comment about Debian remaining compatible from release to release? Are you claiming Debian don't already do that? Do you understand the implications that

            • Did you miss the part of my comment about Debian remaining compatible from release to release? Are you claiming Debian don't already do that? Do you understand the implications that has on the necessity of testing applications against each Debian system release?

              I'm astonished that Debian does this, since it clearly implies much extra work in testing an updated package (No wonder that Debian releases so seldom) That is why I misread your comment concerning compatability from release to release. On OpenBS

            • "id you miss the part of my comment about Debian remaining compatible from release to release? Are you claiming Debian don't already do that?"

              I do (in an aspect). While it is true that Debian tries hard to be compatible from release to release, compatible doesn't mean you can just take, let's say, Postfix from Potato and through it into Sarge (that's obviously true if we consider only the binary packages and their DLL dependencies, but it is equally true regarding package configuration tools, integration w
        • So where do you draw the line between the OS and the apps? Some things are obvious: the kernel goes in the OS. and ok, everything that you need to build the kernel, which is really a lot of stuff. And I guess that means you need libc et al. hmmm, but do you need an editor bundled with the OS so you can configure stuff? well you can't pick just one or you lose your [EMACS|ViM] fans. And then what about something like hotplug/udev? You don't really need them, but they are central to the operation of the OS in

      • Re:Worst idea ever? (Score:3, Insightful)

        by Spazmania ( 174582 )
        More to the point, I'd hate for them to release twice as often period. I maintain more than 60 machines; frequent release upgrades would be a serious drain on my time.

        If you want a distro that does significant upgrades to core packages every few weeks, get Fedora. Its great for that. Sucks for stability, but it has a really fast upgrade cycle.

      • Re:Worst idea ever? (Score:4, Informative)

        by croddy ( 659025 ) on Monday April 10, 2006 @09:25AM (#15098747)
        I would definitely agree. It is unusual (in the Linux world) that Sarge took two and a half years to release, but I think that the benefits of the Debian QA process are very apparent. Taking the time to sort out bugs as well as they do -- on a very large number of packages -- makes a Debian release worth waiting for.

        The slower release cycle is offset by two things. If you know you need a fresher system, and are willing to sacrifice some stability for updated packages, you have as many choices as you can handle: adding a few packages from testing to your stable system, directly tracking testing or unstable, some mix of any of the three, or even adding packages from experimental if you really want to go out on a limb.

        The power of Debian is not only in APT, but in Debconf, the configuration system. Configuration changes are pretty much a given on a system that's directly tracking sid, but are unheard-of (and perhaps even forbidden?) in the stable release. The ease of administration that comes with knowing that changes Debian stable will consist only of backported security patches makes it worth the wait.

        Lastly, a system administrator does not want to have to go through a major operating system upgrade on numerous heterogenous servers every 9 months. Knowing that it will be somewhere around 18-36 months between Debian releases means spending a lot less time migrating and fiddling with systems just to keep up with supported releases.

        Other distributions do release every 6-9 months. It's not for me... except when it is, and I use testing/unstable in those cases :-)

      • In fact wanting Debian to follow Ubuntu path makes little sense. It will end up suffering from the same problems and having the same bonuses (I admit the problems i have experienced are minor, the perceived superior quality of Debian may be just subjective, Ubuntu is impressive). I suggest closer interaction between debian ubuntu and other apt based distros and letting the user choose. As long as it's Free software, I see no problem. Of course it makes sense for the leader of Debian project to streamline
      • I totally agree.

        I hang out on debian-user a lot and I can say, that having everyone on the same page helps a LOT. In fact, you can count on one hand the number of recurring problems and they usually only involve a couple packages.

        What does this mean? That out of something like 16,000 packages, spanning 3+ releases (still some Woodies out there), only a handful are problematic. True, a lot of those packages are not used by many, but still, it is telling. Debian Just Works, by and large.
    • I value their large repository for its well-organized dependency tracking and the fact that packages have all been tested for mutual compatibility.

      I don't care how often "stable" releases. I track "testing" with frequent dist-upgrades on my desktop machines, and on servers I'd not worry if "stable" was a bit long in the tooth.

      Throwing away the packages to get a rapid release cycle would be a bad bargain for me.

    • Try the Debian netinst images (~180mb) and don't select any additional packages. Makes a great minimal installation. Very neat.

  • there's-a-new-sheriff-in-town dept.

    I can see I'm not the only one who read that as, "Anthony Debian Elected New Town Leader."

    -Loyal

  • Brandon replaced after only 1 year? (Score:4, Interesting)

    by JSBiff ( 87824 ) on Monday April 10, 2006 @08:48AM (#15098612) Journal
    I don't really follow Debian politics much. But, I remember seeing just last year that Brandon Robinson had been elected project lead (he too was planning to put Debian on a faster release cycle last year as I recall).

    So, did Brandon resign the post, or did the Debian voters just decide that 1 year of Brandon was enough? I presume that Debian must elect a new leader annually? Are incumbents allowed to run for a second term? Did Brandon run again? Can anyone provide a post-mortem of Brandon's year - was it generally considered that he did a good job in the post?

  • Changes (Score:2, Interesting)

    by Hellboy0101 ( 680494 )
    There used to be a time when a new Debian leader election would not have been relegated to a sub headline on Slashdot. I agree with others on this thread that excess architectures need to be dumped, and a firm timeline needs to be put in place. I say putting out a new Stable release every 12 months is the way to go. Debian has an excellent reputation for it's performance and stability. Six months is too soon to keep up that reputation. A new Testing release would be available every six months. With securi

Slashdot Top Deals

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (10) Sorry, but that's too useful.

Close