On Wed, Apr 12, 2017 at 08:34:51AM -0400, valdis.kletnieks@xxxxxx wrote: > On Wed, 12 Apr 2017 10:30:27 +0800, Tran Ly Vu said: > > > How exactly do i start to contribute to linux community, i.e fix bug, etc > > Step 0: Figure out *why* you want to contribute to the Linux kernel. > > Did your boss just tell you that you have 6 weeks to write a driver for > your company's new widget? > > Do you have a device that doesn't have Linux support? > > Is your kernel crashing/misbehaving? > > Do you have an intense interest in filesystems, or memory management, or > networking, or process scheduling, or other aspect of kernels? > > Do you just want to give back to the community? > > Did you think it was a good way to attract members of the appropriate gender? > > What you do next will depend on *why* you're here, and what your current > technical skills are. > > Note that asking others for what you should do is as bad an idea as > asking people whether you should write a murder mystery or a romance novel, > and for exactly the same reason. If you're doing it because somebody else > suggested it but you don't care for it, the results will be bad. > > Though if you just want to give back to the community, the easiest thing > to do, and the most useful, is to build and boot linux-next kernels and > see if anything breaks on your system. We have *lots* of people slinging > code, and not so many testing. And testing is easier than coding. :) > > Here's the cheat sheet for linux-next: > > $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > $ cd linux > $ git remote add linux-next git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git > $ git fetch linux-next > $ git fetch --tags linux-next > > (now get a .config file - grabbing your distro's config is a good place > to start. 'make locallmodconfig' if you want a faster build by not building > device driver modules for devices you don't have. > Then do a 'make' and install/boot your kernel. Google for detailed > instructions for how to build/install your own kernel on your distro > > ... # later on - do this once every 1-3 weeks or as time permits > $ git remote update > $ make oldconfig > $ make > (install as above) > Boot it, and report any problems. > > Do *not* do a 'git pull' to get the most recent linux-next, it won't do what > you think. > > Yes, it really *is* that simple. > > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies@xxxxxxxxxxxxxxxxx > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies Hey, that's quite interesting. (And Hi, I'm really new here) So, the best "branch" of developement to test if it doesn't break our system is the linux-next branch, or the mainline kernel (currently tagged by Linus as 4.11-RC6) ? I'm currently trying to understand how kernel developement is actually organized, here's what I've understood Developers pull the code fror the next kernel release (mainline? linux-next?) and make changes. They gett the diff of theses changes (patches), and send them by mail to the relevent maintainers and mailing lists. Maintainers approves (or discuss) the changes, and acked/sign them off. >From there, where are the patches going? To Linux Next? or th Linus's mainline tree? - In the mean time, Linux get patches from trusted mainaines into he's own tree while working on what will become the next kernel version. After a while, he decide to not accept "new features" patches for that version, only bugfixes. That's when he's doing "release candidates" of the kernel. After multiple of these, when eveything is "ready", the new kernel is released. For example, the next one will be 4.11. - Once that is done, Linux start's working on getting the patches from 4.12 in the same way, while the maintainer for the "stable" kernel, port back the important fixes to the current kernel. That's hw we get kernels like the 4.10.9 that I'm currently running (Just got out of my distro's testing process. ArchLinux holds binary packages in a "testing" repository before putting them in "core" Arch. That's off-topic). So, how "linux-next" works ? Is that a "testing ground" for new kernel patches? When/how does the changes the maintainers accepted are merged into the mainline kernel? ^^" Oh, and, I almost forgot : If I try to use a linux-next kenrel, and things breaks, who do I tell? ^^" Sorry if that's a lot of questions, but I'm fairly curious right now Thanks in advance, Arthur Brainville _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
