Forgot your password?
typodupeerror
Programming Software IT Linux Technology

Linux Foundation Paving Way for New Kernel Developers 46

Posted by ScuttleMonkey
from the map-and-a-stopwatch-for-flying-blind dept.
Jack Spine writes "The Linux Foundation has published a how-to document for developers who want to negotiate the hidden shoals of open source. According to both the Linux Foundation and the Open Source Consortium, developers can get frustrated with the processes in open source coding, especially for enterprise-class projects like Linux. 'A guide to the kernel development process' aims to encourage participation from new programmers by explaining what's involved. Some developers and businesses attempting to submit changes to the Linux kernel find themselves tangled up with the processes used, according to the guide, which was written by Jonathan Corbet, executive editor of lwn.net and himself a Linux developer."
This discussion has been archived. No new comments can be posted.

Linux Foundation Paving Way for New Kernel Developers

Comments Filter:
  • direct link (Score:5, Informative)

    by larry bagina (561269) on Friday August 15, 2008 @05:12PM (#24622031) Journal
    here [linuxfoundation.org].
  • How much skill? (Score:5, Insightful)

    by colmore (56499) on Friday August 15, 2008 @05:38PM (#24622221) Journal

    So I can pretty well follow a spec, an algorithm description, or pseudo-code in C. But I'm no pro. Do I have the skills to start contributing to a top-tier open source project like the kernel, gcc, apache, etc? I'm looking at this link, what others would people recommend for how to get started?

    • Re:How much skill? (Score:5, Informative)

      by gbjbaanb (229885) on Friday August 15, 2008 @05:48PM (#24622283)

      This one [sourceforge.net].

      Pick a project (you will have to filter the language to C for the more kernel-like projects), then offer to help out with some coding. The people running it should be happy for you to help out (just don't expect to suddenly become a respected developer until you've proven it) and should be able to provide you with more assistance in getting up to speed. Once there, you should have the confidence to tackle something more high-profile.

      • Re:How much skill? (Score:5, Informative)

        by flowsnake (1051494) on Friday August 15, 2008 @07:49PM (#24623251)
        The SourceForge Help Wanted [sourceforge.net] page is also a good place to look. Most of the projects looking for help aren't really top-tier projects, but they'd be a good way of building up reputation when the GP later wants to go for the big name projects.
      • Re: (Score:3, Informative)

        by TheRaven64 (641858)

        Also don't forget that Sourceforge isn't the only place to find Free Software projects. A lot of us use GNA [gna.org] for our hosting, since it isn't quite so cluttered with ads and the entire platform they use is Free Software, so if we decide we don't like them we can move to our own server somewhere without changing the server-side components at all (GNA is run by FSF France and bandwidth is donated by the French ISP Free.fr).

        A good place to look for getting involved with projects is in the bugs database. Pick

    • Re:How much skill? (Score:4, Insightful)

      by larry bagina (561269) on Friday August 15, 2008 @05:58PM (#24622365) Journal
      1. use FREE software.
      2. Find bugs, annoyances, or missing features.
      3. submit bug report, enhancement request, or patch
      4. watch bug report get ignored or closed, watch patch get rejected for using 4 spaces per tab instead of 2
      • Re:How much skill? (Score:4, Insightful)

        by Thiez (1281866) on Friday August 15, 2008 @06:23PM (#24622625)

        5. Write javascript webpage that can change the indent style of code (K&R, Allman, KNF, GNU, etc). (Paste code in textarea, select style, click 'Go', and the code changes to the selected style)
        6. Place some adds on your webpage
        7. ???
        8. Profit!

      • watch patch get rejected for using 4 spaces per tab instead of 2

        4 spaces per tab? You vile subhuman vermin. Death is too good for you. I hope you roast in Linux hell with your 72 (male) virgins arguing about naming conventions and software licensing for all eternity.

        12 tab characters per tab has always been the standard, just do a s/\t/\t\t\t\t\t\t\t\t\t\t\t\t/g on your code before you commit.

    • by thefear (1011449)
      The worst they can do is not apply it
      • by greg1104 (461138) <gsmith@gregsmith.com> on Friday August 15, 2008 @06:14PM (#24622537) Homepage

        Actually, the worst they can do is not apply it and decide you're incompetent/don't play by the rules/etc. Then you risk your future submissions being less likely to be considered even if you improve later. The person who wastes the time of a patch reviewer is not soon forgotten by that reviewer.

        It really is better to not submit a patch at all if you don't know what's going on yet, which is exactly why guides like this one are helpful. I've worked on a similar one for PostgreSQL [postgresql.org] because it's hard for new people to pick up the unique requirement quirks of a group of developers, and lowering that barrier improves the health of the project.

        • Actually, the worst they can do is not apply it and decide you're incompetent/don't play by the rules/etc.

          No, the worst they can do is not apply it and decide you are so incomptent that you are a menace to life on earth so they send "kill -9" kernel assassination squads to take out you, your entire family and your dog and then burn your house down to hide the evidence.

          • by greg1104 (461138)

            Well, sure, that's how outraged FreeBSD kernel developers handle people who send bad patches, but we were talking about Linux.

        • 1. Lurk for a while. 2. Make a post on an introductory thread. 3. Attempt to join in a discussion, preferably one that you *really* care about, and get shouted down because everyone thinks you're an asshat. 4. Karma whore on bullshit discussions, to get your reputation back. 5. ???
        • So? (Score:3, Interesting)

          by Gazzonyx (982402)
          If someone decides that you're a trouble maker, or whatever, try to get your patch in a different branch of the tree. The kernel has a long tail, and all patches go upstream to Andrew Mortons tree and then hop to Linus' tree, provided that the code is decent and it serves a genuine purpose (A guy from Google has two spelling corrections that were merged and he got credited for).

          You'll get yelled at for formatting and such before anyone of higher authority sees your code. You probably won't get your cod
    • by bfields (66644)

      So I can pretty well follow a spec, an algorithm description, or pseudo-code in C. But I'm no pro. Do I have the skills to start contributing to a top-tier open source project like the kernel, gcc, apache, etc? I'm looking at this link, what others would people recommend for how to get started?

      One great thing to do is just to figure out how to download and build the latest development versions of the software, and try it out.

      That's especially true for the kernel, which runs on a much wider variety of hardware than any one developer can have access to.

      In the process of learning to write good bug reports, helping reproduce and debug problems, etc., you can learn a lot about the code.

      • Not relevant to the Linux kernel, but one thing that's really helpful is to try building on less mainstream platforms. We test on FreeBSD and Ubuntu (both x86), and occasionally OpenBSD/PowerPC and Debian/PowerPC, but no one regularly tests on Solaris (x86 or SPARC) even though we have some special case code for Solaris in a few places, and no one has ever tested on NetBSD on any platform, to my knowledge.

    • I actually am looking at the Apache2 code right now for some obscure reasons. I have 6 years of professional development experience (though very little of that in C).
      What I saw was, it took me like 2 weeks of constant battling to make some sense of the code in any way. GDB, inserting random print statement statements, stace and ltrace helped. However what has come out as the most difficult road block for me is: Macros!
      I don't get flustered by pointers too much, but Apache2 code uses some demonic macros, res

    • by johannesg (664142)

      Wanna code? Great, go for it. But consider this: what Open Source really needs is more people who can write decent documentation, create user interfaces that actually work, and draw pretty icons.

      How many Open Source projects are there with a homepage that doesn't even bother to tell you what the project does? If the first words on your homepage are not the name of your project, followed by about three lines of very clear descriptive text, you have lost most of your prospective users already - they will neve

      • by colmore (56499)

        I'm not really interested in working on the equivalents of shrinkwrapped software. I'm more interested in working with the inner guts of the system. There are different concerns when your software has a gui or interacts directly with a large number of regular users. I'm not as interested in that stuff.

  • by PAStheLoD (872844) on Saturday August 16, 2008 @12:24AM (#24624421) Homepage
    I don't know what's the bigger achievement. Getting a patch into mainline or reading all of these 67-miles long "super-qucik howtos". Seriously, what's wrong with a wiki, where you can "abstract" hundreds of lines into smaller, more managable articles? Anyhow, it's good to see the most sacred inner-cult of KernelMailingList opening up a little :)

As the trials of life continue to take their toll, remember that there is always a future in Computer Maintenance. -- National Lampoon, "Deteriorata"

Working...