Hi Amit, > I've access to this machine as root also but as you've suggested I can use my > user login account as well. Well, it's up to you...it's just that being root all the time makes me nervous :-) > My current goal is to send some patches to kernel janitor group though I'm not > sure if this group is still active or not. > you mean to say that this is not the tree which i should be synced to? If not > then can you please send me the link to the relevant git repository ? > > -Amit Kernel-janitors is still very much active, it's a good list to follow as it is quite low volume (typically between maybe 5 - 10 emails a day? although it varies) and it's a great way of getting a feel for how things are done and getting ideas for patches. What tree you want to be testing against I think really depends on the patch you are doing, linux-next is supposed to be the official 'tree' but I think some maintainers have their own they sometimes prefer developers to use. It's trivial with git to follow these if you need to though. I'd recommend following (and looking into doing) some work on drivers in staging too, if you are trying to find a starting point (the mailing list for this is devel.linuxdriverproject.org). I _think_ Greg KH asks people to use linux-next (although staging has its own tree, to be sure, email before sending the patches). You can remote track linux-next from your existing repo. (this is how I do it.) cd into your linux-2.6/ and do this; $ 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 You will then be all set up to track linux-next. Then, in the future, do 'git remote update' to update the linux-next branch so you get all the latest tags each time (this will also update any other remote branches you have set up to track). Note that as I understand it linux-next isn't an 'evolving' tree like mainline, it's best to see it as being a list of individual kernels released as tags, i.e. you shouldn't be merging one into another. Stephen Rothwell's notification on the linux-kernel mailing list about the latest release explains this and is probably worth a read: https://lkml.org/lkml/2012/2/1/20 To list the tags, do: $ git tag -l next-* and the bottom one will be the latest linux-next version. So in my repo, having just done a remote update, the last few tags look like this: $ git tag -l next-* <...> next-20111215 next-20111216 next-20111221 next-20111228 next-20120113 next-20120118 next-20120201 The bottom one is the latest release so I can check out this tag, like so, (with accompanying message below:) $ git checkout next-20120201 Checking out files: 100% (2741/2741), done. Note: checking out 'next-20120201'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b new_branch_name HEAD is now at bc7f599... Add linux-next specific files for 20120201 Then I can create a new branch from here, e.g. $ git checkout -b 1st-feb-2012-next Now I have my own branch to build a linux-next kernel, or work on, etc. HTH. Cheers Julie _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
