How to contribute (was Re: Kernelnewbies Digest, Vol 77, Issue 7

[Arthur Brainville (Ybalrid)]

On Wed, Apr 12, 2017 at 08:34:51AM -0400, valdis.kletnieks at vt.edu 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 at kernelnewbies.org
> 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