Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Linux Business Software Programming Linux IT Technology

Torvalds & Linux Dev Process 240

Posted by Hemos from the minding-the-shop dept.
sebFlyte writes "Builder UK is reporting that Linus Torvalds is concerned that the Linux production kernel maintainence process might be overly taxing Andrew Morton, saying: "One issue is that I actually worry that Andrew will at some point be where I was a couple of years ago -- overworked and stressed out by just tons and tons of patches. If Andrew burns out, we'll all suffer hugely." Morton himself wants to make -mm releases more often. He sees bugs as more of a problem, rather than patches themselves. His solution is simple: "I'd like to release -mm's more often and I'd like -mm to have less of a wild-and-crappy reputation. Both of these would happen if originators were to test their stuff more carefully.""
This discussion has been archived. No new comments can be posted.

Torvalds & Linux Dev Process More

Torvalds & Linux Dev Process

Comments Filter:

  • Bus (Score:5, Insightful)

    by kevin_conaway ( 585204 ) on Monday September 26, 2005 @11:01AM (#13651213) Homepage
    What if he gets hit by a bus? What would happen then?

    Is there a hierarchy of maintainers (like the succession to President) or what?

    Seems to me they should have at least 2 people at that spot so its not completely a single point of failure.

    • Re:Bus (Score:4, Insightful)

      by Pieroxy ( 222434 ) on Monday September 26, 2005 @11:05AM (#13651239) Homepage
      As far as my experience has shown me, there is no 'single point of failure' in any team made of humans. Some things would be lost for sure, but life (of the project) would just go on.

      Of course, as everything in life, it is not black and white. He would have to be replaced (or the devel structure shifted) and changes would result from this. But the whole thing would not just stop.
      • Obviously not a sports fan. If a star player gets injured, the "project" of winning the championship game that season will fail if there is insufficient talent elsewhere on the team to pick up the slack. Granted, Linux is not in direct competition with anybody, so they have basically unlimited time to find a replacement, but in the grand scheme of things if a few top contributors to Linux were to disappear or stop, Linux would lose a lot of footing in the OS wars.
        • Talk about comparing apples and oranges, but I'll bite.

          Well, it all depends. Winning the championship is not a project, it is a temporary goal of your team. The team is the project, not the championship. That's if you want to make a parallel with a development team of course. In a development team, people don't rely on others on the same way.

          And of course, if you set yourself statistically almost-unnatainable goals (like winning against 10 other teams, 1/10 chances) of course even a minor change in course c
      • Some people die, but that is life.

        It sounds cynic, a bit like life.
        • 'Some people die...'

          Sorry to burst your bubble but we all die, life is a terminal illness, nobody gets out of here alive etc.

      • The graveyards are full of indispensable men. (Score:4, Funny)

        by Chyeburashka ( 122715 ) on Monday September 26, 2005 @12:26PM (#13651912) Homepage
        Obligitory Charles de Gaulle quote, although he may have actually said "Les cimetières sont pleins d'hommes indispensables."

        Of course, this may explain France's military record.

    • Re:Bus (Score:5, Funny)

      by gowen ( 141411 ) <gwowen@gmail.com> on Monday September 26, 2005 @11:15AM (#13651328) Homepage Journal
      Is there a hierarchy of maintainers (like the succession to President) or what?
      Yes. If Andrew Morton gets hit by a bus, Dick Cheney gets to maintain the Linux kernel. If Dick is unable to fulfil those duties, the maintenance gets subcontracted to Halliburton.

    • Re:Bus (Score:3, Insightful)

      by greppling ( 601175 )
      What if he gets hit by a bus? What would happen then?

      Nobody knows but I am not worried. The Linux kernel community has always been great in adopting to new circumstances. Alan Cox decided to drop kernel work for a year to do a MBA? No problem, his role got taken over by a couple of people. Linus has to decide to drop BK? No big problem, Linus start writing GIT, which is quickly taken over by other people, and after 2 weeks development continues almost as if nothing happened. Dave Jones gets overworked pus

    • As the sole maintainer/builder of a sizeable project (trading system), I thoroughly sympathize - patches really aren't a problem - it's when some £$^$%^^%%$ checks in broken code, or forgets to check something in, that you want to go and wring their bloody neck, because you're pissing your sunday away trying to fix the weekly rollup build.

      • Re:Bus (Score:3, Interesting)

        by rossifer ( 581396 )
        - it's when some £$^$%^^%%$ checks in broken code, or forgets to check something in, that you want to go and wring their bloody neck, because you're pissing your sunday away trying to fix the weekly rollup build.

        This is why I love products that protect the source tip with pre-commit testing. If it doesn't pass the regression suite, it's their problem and not your problem. You can do it with commit hooks in some CM tools (Subversion gives you some ability to do this, as an example), and there are a f

    • Re:Bus (Score:3, Funny)

      by hobuddy ( 253368 )
      The solution is to put Richard Stallman in charge of the kernel development process. If he got hit by a bus, the only problem would be a pulverised bus.
    • Most likely, the process would change, because I don't think anyone else's style is quite the same. There's nothing that says patches have to go through -mm or any other particular catch-all development tree; it's just that, since -mm exists, it is expected that patches will go through it. Most likely, were Andrew to get hit by a bus, subsystem maintainers would solicit more testing of their trees and would send patches directly to Linus. Most likely, Linus would take over Andrew's role, and the maintainers

    • Obviously (Score:3, Funny)

      by joe_bruin ( 266648 )
      Kernel Panic: Bus Error

  • Fantastic (Score:5, Funny)

    by Professor S. Brown ( 780963 ) on Monday September 26, 2005 @11:03AM (#13651224)
    I have to say that we in my lab are thrilled with the progress in the Linux kernel. We have been running Linux in our labs for ages, and it now controls the massive coils that circle all the corridors in our buildings, ominously humming in the night. Before, we had Windows XP controlling the titantic voltages that flow through the rings, and we found that very often the control threads would become scheduled into irrelevance and the voltages would become unstable. This would lead to devastating magnetic fields that would reverse the path of time across the carpet in my room, staining it really badly.

    • Re:Fantastic (Score:2, Funny)

      by eno2001 ( 527078 )
      Sir. I cannot believe your claims for the simple matter of the fact that the Linux kernel has not yet been proven to pierce the veil of time and space. If Windows XP cannot manage time and space properly as you purport, then Linux clearly cannot as the Linux corporation has no R&D budget due to the non-profit nature of the beast. Anyone who makes such claims is most obviously blowing hot air and doesn't know what he is talking about. The only time that the Linux corporation will be able to make such

  • Test? (Score:4, Funny)

    by Hrodvitnir ( 101283 ) on Monday September 26, 2005 @11:04AM (#13651226)
    Don't be silly. That's what users are for.

    At least, that seems to be the prevailing ideology the past 10 years or so.
    • "I'd like -mm to have less of a wild-and-crappy reputation"

      well with pictures like this http://www.iwantalife.com/ramblings/blog/roadster. jpg [iwantalife.com], what do you expect???

    • Re:Test? (Score:4, Insightful)

      by brunson ( 91995 ) on Monday September 26, 2005 @11:49AM (#13651623) Homepage
      It sounds like they could benefit from a practice in Xtreme Programming. The test cases should be written before the patch is written and submitted with the patch. The test cases would then go into a regression framework and the regression test must be passed before a release.

      • Re:Test? (Score:3, Insightful)

        by laptop006 ( 37721 )
        Show me how to write usable test cases for hundreds of peices of random hardware.

        That which can be tested already is (The big one I can think of is filesystem stability).

        You should at least read kernel traffic to see how much attention some of this code gets, and personally, I'm amazed at how few bugs are left, and how many of those are just badly designed hardware.

      • Re:Test? (Score:4, Funny)

        by schon ( 31600 ) on Monday September 26, 2005 @02:16PM (#13652754)
        It sounds like they could benefit from a practice in Xtreme Programming.

        Is that where they jump out of an airplane with only a laptop and a parachute, and see how much they can code on the way down?

  • I haven't moved to 2.6, others haven't either? (Score:5, Interesting)

    by garcia ( 6573 ) on Monday September 26, 2005 @11:04AM (#13651228)
    There doesn't seem to be much happening out there wrt 2.6.15," said Morton in a mailing list posting. "We're at rc2 [the second release candidate of 2.6.14] and I only have only maybe 100 patches tagged for 2.6.15 at this time. The number of actual major features lined up for 2.6.15 looks relatively small too," he said in a later posting.

    Ok, not that much going on w/this kernel, and then we get:

    In the same mailing list thread, Linus Torvalds, the creator of Linux and the maintainer of the development kernel, expressed concerns that the kernel development process may need to be changed to make sure that Morton is not overworked.

    So, there isn't much traffic coming through and Morton wants to do even more -mm releases but Linus thinks he might become overworked? I'm confused. Any clarification on this from the list that the article doesn't give?

    He suggested this may indicate that the kernel is nearing completion. "Famous last words, but the actual patch volume _has_ to drop off one day," said Morton. "We have to finish this thing one day."

    I still haven't even bothered to move to 2.6.x as I have no reason to. I used to update my kernels immediately (and even ran various -AC, etc) but 2.4.x has been so stable for me that I see no reason to bother. Perhaps the reason why traffic is low is because of that?
    • Hell, if there aren't any threatening security problems, fancy new features or important bugfixes, there's no reason to upgrade. What you might get if you did, however, would be better performance, ATAPI CD burning (unless of course you're happy with SCSI emulation, which works great still) and a few other bits and pieces, like ALSA integrated into the kernel and such. The biggest feature is better performance, though. Not that it really matters that much unless your machines run in a high-load environment,
    • I still haven't even bothered to move to 2.6.x as I have no reason to. I used to update my kernels immediately (and even ran various -AC, etc) but 2.4.x has been so stable for me that I see no reason to bother.

      Wow. You used to run kernel versions maintained by Anonymous Cowards? You are certainly more daring than I.

      BTW, of my 4 Linux systems here, only one uses 2.6.x. The others run 2.4.x. Upgrading the kernel on some of my systems is a real pain (my firewall, for example, is a 100MHz processor w/32MB R
      • 2 questions:
        1. How is it a pain? I see that it can take a long time on this machine, but it does it on its own, doesn't it. Unless of course you can't afford the performance hit. Which leads me to
        2. Why don't you simply (coss-)compile it on another machine and copy it over?
        • How is it a pain? I see that it can take a long time on this machine, but it does it on its own, doesn't it. Unless of course you can't afford the performance hit

          I use a minimalist configuration of the kernel with no dynamic modules (helps prevent rootkits). So I have to go through the configuration process every time I upgrade the kernel. With the change from the 2.4-style most-commonly-used items enabled to the 2.6-style everything enabled, it just is not practical for me to move this item.

          As for the ot
      • I'm still using 2.4 on most of my machines. My desktops are running 2.6.12.5 (2.6.13 gives me intermittant lockups)

        of my 4 Linux systems here, only one uses 2.6.x. The others run 2.4.x. Upgrading the kernel on some of my systems is a real pain (my firewall, for example, is a 100MHz processor w/32MB RAM.

        I've installed 2.6 on a couple of firewalls (a P75 and a P133, each with 32MB RAM) and it runs fine.

        Recompiling the kernel to my specifications is a real pain.

        Why? One kernel tree on a dev machine, keep a
        • I've installed 2.6 on a couple of firewalls (a P75 and a P133, each with 32MB RAM) and it runs fine.

          I have several customers running it, but my firewall is a bit different. My customers' firewalls are designed so that anyone can update them without having to contact me for schematics/documentation. My firewall is heavily hardened to the extent that I have an extremely customized kernel configuration (among other things, no support for dynamic modules). I think that I am the only one at the moment who can
      • Um, you know you don't have to compile a kernel on the machine it is going to be installed on, right? In Debian, it is really easy to generate a package for a custom kernel (and modules) to be distributed.

        • Um, you know you don't have to compile a kernel on the machine it is going to be installed on, right? In Debian, it is really easy to generate a package for a custom kernel (and modules) to be distributed.

          Note the phrase *to my specifications.* Most of the issue has to do with configuring the darned thing. Why would I worry about compiling on a different system? It does compile (takes a few hours) and as long as it is already running, no real performance hit. (Compiling user-mode applications is quite di

    • Re:I haven't moved to 2.6, others haven't either? (Score:4, Informative)

      by Kjella ( 173770 ) on Monday September 26, 2005 @12:36PM (#13651980) Homepage
      I'm confused. Any clarification on this from the list that the article doesn't give?

      Well, I'm not sure I understand the situation correctly, but is seems to me like a branch to 2.7 might be coming. Since there's been no separate development branch, there's been a lot more patching than usual for a stable kernel. I think the comments indicate that 2.6 might be close to "done" and should enter maintenance mode. Starting major breakage in the 2.6 branch would overwork Morton, hence the need for a "changed development process".

      I still haven't even bothered to move to 2.6.x as I have no reason to.

      Don't confuse user numbers with development. In fact, they are usually inversely related (the less development, the more stability and the more users.... to a point). And I'm quite sure the causality is that less development in 2.6.x leads to more adoption, not the other way around.

      Kjella
    • I'm on 2.6 for the responsiveness, but it's really buggy. Don't use it yet if you can avoid it.
    • Why don't you ask the Linux Counter [li.org] about the kernel version usage stats?
    • The thread actually went in the other order. Linus said he was worried about Andrew burning out, and asked him how he was doing. Andrew said he's fine with his job, but that getting patches that don't work slows him down a lot. Then he said that there doesn't seem to be much queued for 2.6.15.

      The reason for 2.6.15 being light isn't that everyone's using 2.4; 2.6.13 got so many changes that the changelog (since 2.6.12) was too big to send to the mailing list. My theory is that the latest change to the proces

    • I still haven't even bothered to move to 2.6.x as I have no reason to.

      Well, every man to himself, but are you nuts?

      The single largest attraction of the 2.6 series is the new driver model with its /sys filesystem. It allows not only taking driver coldplugging and, especially, hotplugging to a new level, but I also use it on servers because of the hardware introspection capabilities that it offers.

      There are also some really interesting things coming in 2.6, such as SECCOMP, NFSv4 and kernel key retenti

  • Windows broken? (Score:2, Interesting)

    by fak3r ( 917687 )
    Label this OT if you want, but a few mins ago /. had a story called "IT: Microsoft Windows is Officially Broken" - it appeared to have comments too, but when I went to read it, it was gone. Switch back to the front page; also gone. Hmmm...I'll post a screeny here: http://cryer.us/images/slash_story.png [cryer.us]

  • Start adding unit tests (Score:5, Insightful)

    by Anonymous Coward on Monday September 26, 2005 @11:07AM (#13651256)
    Add a requirement that each bug should have a failing unit test, that fails before the patch is applied and succeeds after the patch is applied.
    • ... the bug can still exist, you only test with such a test that the bug doesn't appear anymore in THAT particular situation.

      API unit tests should make sure the API interface specifications match the actual implementation. If that's succeeding through the unittests, THEN you have at least knowledge the API is implemented OK (according to the specs) and any bugs following those tests are the result of a bug in the DESIGN.
    • Quality comes from design and implementation, not testing. Testing confirms that quality (or its lack). Testing is only one means of achieving that confirmation, and it's almost never the most effective of those means (assuming "effectiveness" is measured as number of defects removed per unit of effort expended).
    • Are you contributing the zillion different devices that are needed for those tests?

    • Re:Start adding unit tests (Score:5, Interesting)

      by Craig Ringer ( 302899 ) on Monday September 26, 2005 @01:01PM (#13652156) Homepage Journal
      That's reasonable for some very high level subsystems in the kernel. For most things, such as drivers, the scheduler, etc, it's probably not.

      Sometimes defining "pass" and "fail" is hard enough, with tuning efforts. Then there's cleanups. On top of that there are fixes to obsure drivers for hardware that nobody on LKML actually has.

      I'm all for unit test based development, but there are some levels where it's practical, and some where I don't think it is. An OS kernel is to an extent the impractical side. I do like the idea of unit-tests from userspace to make sure nothing userspace-visible breaks, though.
      • An OS kernel is to an extent the impractical side.

        No. Unit testing a monolithic kernel is impractical. Unit testing and OO-like design are some of my favorite benefits of microkernels. Creating mock-hardware to use in the testing would still be extremely complex, but worthwhile in the end.

  • it's an architectural problem (Score:5, Insightful)

    by idlake ( 850372 ) on Monday September 26, 2005 @11:09AM (#13651276)
    This is an architectural problem, not a resource problem. There is no reason why the Linux kernel should require the baroque system of manual patches and updates that is currently in place. Instead, it should be composable at runtime out of many modules that are encapsulated enough and insulated enough from one another to be developed and updated independently.

  • automated testing in kernel development? (Score:5, Interesting)

    by markjugg ( 21992 ) * <mark@@@summersault...com> on Monday September 26, 2005 @11:10AM (#13651280) Homepage
    In the world of Perl module development, automated testing plays an important role. As a gatekeeper myself, I often request that a code patch also come with an automated test, and the contributors often follow-up with one, if they didn't supply it in the first place.

    In the Pugs [pugscode.org] project, the coders and testers are generally different people, when the tests being written first.

    I'm fairly ignorant about the kernel development process, so I ask: could automated testing play a greater role in the quality assurance of the project?

    • I'm fairly ignorant about the kernel development process, so I ask: could automated testing play a greater role in the quality assurance of the project?

      Short answer: no.

      Long answer: Of course, automatic testing has its role, and the OSDL and LTP guys have been doing this regularly. It is great to monitor for any kind of regressions, including performance-wise.

      But most kernel bugs are new, and it is pretty tough to set up a kernel test that intelligently discovers new bugs. Maybe even more importantly,

    • Unit Testing Is Hard (Score:4, Interesting)

      by Vagary ( 21383 ) <jawarren@@@gmail...com> on Monday September 26, 2005 @11:36AM (#13651487) Journal
      As someone who uses unit testing for application development, I'd have to wonder whether the cost of setting up such a system would be worth the benefits? One of the big challenges in automated testing is measuring behaviour to check correctness.

      How do you check that a kernel driver is using hardware correctly? It's more or less difficult to measure the beavhiour externally depending on the system. Effectively you need to use mock/simulated interfaces -- in this case probably virtual machines -- but then what kind of code coverage would you get?

      Personally, for the kernel, I'd guess the bang-for-buck of adding static checking would be higher than dynamic checking.

    • already there (Score:5, Informative)

      by diegocgteleline.es ( 653730 ) on Monday September 26, 2005 @11:46AM (#13651584)
      Linux Kernel Gets Fully Automated Test [slashdot.org]

      2.6 stabilization project [osdl.org] (helped a lot during 2.5.x develpment AFAIK)

      http://www.osdl.org/docs/stabilization_plan.curren t [osdl.org]

    • Some already exists. (Score:5, Informative)

      by jd ( 1658 ) <imipak@yahooMENCKEN.com minus author> on Monday September 26, 2005 @12:10PM (#13651791) Homepage Journal
      The Linux Test Project, Web100 (which profiles the network stack) and the TAHI IPv6/IPSec Test Suite should be usable to give you a starting point for validating the kernel. HOL may be usable as a component in formal proofs of components with well-defined behaviour (such as busses, networks, etc). Both TAU and the Performance Application Programming Interface would allow you to create profiles of kernel components running in User-Mode Linux, so allowing developers to spot the causes of things like latency.


      These wouldn't solve ALL problems, or even the majority of them, but they would solve some and they would make life easier on developers in the long-run. Are these being used? Well, a glance at the Freshmeat graphs for Web100 shows that it is getting downloaded. This doesn't mean it is getting used, though. The same is true of virtually all of the other code I've mentioned. People have copies, but if the code being submitted is flakey and taking a long time to fix, then maybe the code is not being used as much as it could/should be.


      The tools exist, the tools exist on people's hard drives, but unless the tools are being used in practice, that's not going to do any good.

  • I lost track of the SCM status for the kernel, but my crude understanding is that the kernel developers rolled their own, git [git.or.cz]. Is git a fully-featured SCM? And if not, could using git be causing any additional workload that would be alleviated by using darcs or whatever?

    And just for the record, what's the strategic plan for kernel SCM?

    • Re:SCM Status? (Score:2, Informative)

      by paskie ( 539112 )
      GIT is pretty much a fully-featured SCM by now. It still isn't fully stabilized and there is still plenty of things to work out, but it is completely practically usable, and it's actually from a large part designed to make things easy for the kernel people (well, especially Linus itself ;). I don't know if the workload is more or less than when using BK, and that would be actually a very interesting question to ask Linus, but I *think* things are easier for Linus now. I'm not really sure about Andrew Morton

  • Kernel 2.6 Problems (Was I better off with 2.4?) (Score:5, Interesting)

    by KhanReaper ( 514808 ) on Monday September 26, 2005 @11:33AM (#13651464) Homepage
    Is it me or has kernel 2.6 been comparibly unstable and quirky in the past six months? I have to admit that I am very disappointed with this instability and wish that the Linux developers would move back again to their old even-stable and odd-testing version numbering. Things did seem to be a lot more stable back then when this old versioning scheme was used. I mean really, for the past few months kernel quirks in 2.6 have made the kernel appear more like a testing kernel than anything. I am thoroughly disappointed.

    I know that people will complain that I have not cited anything specific or tangible; that is fine. The point for me is that I am sick of random spurious issues that seem to be fixed in one release and then some new permutation thereof appears later. Candidly a lot of these things have to do with CPU throttling, power management, USB, and other aspects of the kernel.

    While I appreciate how much Linux's hardware support has increased over the past few months, the desire for a more mature environment has left me wanting something more.

    In all seriousness, if the quirks of kernel 2.6 keep persisting, I might be inclined to migrate to, god-forbid, BSD.

  • better interface to the universe .. (Score:4, Interesting)

    by torpor ( 458 ) <ibisum AT gmail DOT com> on Monday September 26, 2005 @11:44AM (#13651549) Homepage Journal
    .. it should be far easier for branches/nodes of the linux kernel codebase to cross-polinate.

    the -mm releases are definitely a high order, public priority; but the broader picture is that there are as many possible permutations of linux code as there are tarballs being globbed.

    i see the taxing of andrew (and linus before) as more of an issue of broken tools. if the linux kernel codebase had tools integrated into the core Makefile which would allow for easier tree/pruning/updates and public server integration as the most -common- interface to the .config/Makefile hegemony, i think we'd be seeing a whole lot more public, broader testing going on. its only because i can't confirm/share system .config databases with my peers that it makes it so hard to test other peoples patches; this could just as easily become a 'namespace' manipulated through existing tools ..

    i mean, there are too many ways to get yourself a copy of the kernel, maneuver the patch universe (why haven't patch namespaces become another NS record type yet, i wonder..?), find bits you want to test, etc.

    i imagine a broader 'namespace of patches, and public tested .configs from .torrent servers[or whatever]' as part of the -basic- Makefile in the kernel releases.. yes, svn&co. have their 'namespaces', but i'm talking about 'make update_patches -server:blahblah.org' as a commonly accepted means of contributing to the patch-sphere.

    which is, actually, huge.

  • -mm's (Score:4, Funny)

    by jayemdaet ( 111145 ) on Monday September 26, 2005 @12:31PM (#13651948)
    Melt in your code not in your hand...
  • Really, I have rather exotic hardware and all of that is working under 2.6.12 (yeah, I know, I haven't tried for 2.6.12 or 2.6.14 or another bleeding edge). For _me_, 2.6.12 is stable and snappy and I never expierenced problems with that.

    However said that, I would like to see Linus and team to sucess in management of kernel, because development of it is so active that I really wonder how they still keep pulse on all this. My pick is that they should seperate development kernel from stable one - or at least
  • If I were a business looking to Linux for my future business and saw this article, I would have serious concerns about how Linux is maintained and supported.

    I realize that the kernal needs to be carefully controlled and maintained so that it is consistent worldwide, but to put that responsibility in the hands of one or two people (Linus could pick up immediately if something happened) seems like a very risky way to oversee one of the most important products in the world.

    If Morton does not have an appren

  • A watermelon after a romantic encounter with a loaded rail gun.

    Careful programming, thought, and writing programs like novels, with a flow, consideration for structure and areas you touch will ALWAYS beat out testing.

    There is a fundemantal flaw in relying on testing, or assuming testing 'better' will save something.

  • Secretary (Score:3, Interesting)

    by JThundley ( 631154 ) on Monday September 26, 2005 @08:02PM (#13655237)
    Maybe somebody could arrange for Morton & Torvalds to get a personal secretary. It can just be some CS student that gets some kind of work experience credits or some shit :)

Slashdot Top Deals

One good suit is worth a thousand resumes.

Close