login
Search
Hi all, I have created the first cut of the linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git. Things to know about this tree: It has two branches - master and stable. Stable is currently just Linus' tree and will never rebase. Master will rebase on an almost daily basis (maybe slower at the start). The tree consists of subsystem git and quilt trees. Currently, the quilt trees are integrated by importing them into appropriately based git branches and then merging those branches. This has the advantage that any conflict resolution will onlt have to happen once at the merge point rather than, possibly, sevveral times during the series. However, I am considering just applying the quilt trees on top of the current tree to get a result more like Linus' tree - we will see. The git trees are obviously just merged. Between each merge, the tree was built with both an allmodconfig for both powerpc and x86_64. The tree currently contains: Greg's driver-core, pci and usb quilt series (in that order) Alasdair Kergon's device-mapper quilt tree Jiri Kosina's hid git tree Jean Delvare's i2c quilt tree Randy Dunlap's kernel-doc quilt tree Haavard Skinnemoen's avr32 git tree There was only one unresolved conflict which could have been caused because I was not sure where to base the kernel-doc tree. So, comments, please. Also, more trees please ... :-) --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
Now, would it be possible to have somewhere listed the URLs of git/quilt trees that were merged? The commit messages about merges with different branches aren't too informative, it might sometime be useful to know more about the trees that were merged. Maybe just an additional file somewhere in the root of the source tree would be sufficient ... Thanks, -- Jiri Kosina --
Good idea. I have pushed out an extra commit that just contains the top level "Trees" file. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
Perhaps you can add: git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 test Thanks, Rafael --
Hi Rafael, I would prefer that the trees be added by the subsystem maintainers and they can tell me which branch represents their expectations for the next kernel release (in this case 2.6.26). But thanks, hopefully you will have prodded them along. :-) --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
For the s390 architecture please use the "features" branch of git390: git://git390.osdl.marist.edu/pub/scm/linux-2.6.git features -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. --
Hi Martin, On Thu, 14 Feb 2008 16:25:09 +0100 Martin Schwidefsky <schwidefsky@de.ibm.c= Added thanks. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
For SH: master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.git This is also what goes in to -mm. --
Hi Paul, Added, thanks. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
Please add: git://git.kernel.org/pub/scm/linux/kernel/git/shaggy/jfs-2.6.git next Thanks, Shaggy -- David Kleikamp IBM Linux Technology Center --
Hi Dave, Added, thanks. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
Rafael has it right, please add the branch above. It will include both the upcoming ACPI and suspend patches. Note that I reserve the right to re-base it from time to time - so when you pull it, you want to pull it onto a new branch vs. Linux rather than onto a previous copy of itself. thanks, -Len --
Hi Len, That is fine, I expect rebases. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
As devout believers in testing things early we test -mm and -git releases as they drop. I am keen that we are able to continue this with the -next tree once it gets going. Having just pulled this tree its not obvious how I would communicate which tree I had tested. I guess we could use the SHA1 of the actual head used, but that really is cumbersome for the poor people who have to check the results and actually report things to lkml. As I previously indicated (on my stupidly subjected "testing linux-next") to make it simple for us to test these releases, and for the reporters to have a clear way to refer to them, we need some kind of sensible handle for each. It is also very desirable that it be trivial for a script to detect releases. The -git series is pretty handily named, following that example might make sense. I was going to propose you name them in a similar way to the main -gitN releases. But, I note that you are merging with what appears to be an up to date Linus master tree. Which means there is no nice name for the real base point for your merges anyhow. I guess there are a couple of sensible names for these. Either a simple date or using the nearest sane tag. So either: next-20080214 or: v2.6.25-rc1-next1 Where the "base" version would be determinable from: apw@pinky$ git describe --tags origin/stable v2.6.25-rc1-120-ge760e71 I am guessing if a maintainer is coming back to look at a failure reported by yourself, they are also going to want to know what the base was for the merge which failed. So it may make sense to keep a tag for that too? Also will you be producing any tarballs for these releases? If so I would say they would definatly need to be against some common base, like against the nearest official tag "below". -apw --
Hi Andy, I hope I have addressed this issue by tagging each tree with its date I hadn't considered tarballs, but I will give it some thought. Thanks for your thoughts. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
Hi, i'll provide tars of the current linux-next tree reachable via my http://linux-next.f-seidel.de wiki ("Tar Downloads"). Is that what you were looking for? Thanks, Frank --
Looks close. It needs to be scriptable (not just a dynamically generated link) and have predictable names. As long as those are true, then it should be great. Thanks. -- ~Randy --
// add the next git repo as a tracked remote git remote add next git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git // fetch any objects you don't have // run this whenever you want to check for more objects git remote update // produce a tarball of the tree tagged next-20080220 git archive --format=tar next-20080220 > next-20080220.tar Cheers, Harvey --
Yes, i would have scripted it when it tourned out to be of use for others. But as i just saw Stephen already has something ready for this :-) Thanks, Frank --
Any reason we can't get these on kernel.org so that the mirror system will kick in for the whole world? thanks, greg k-h --
Only that i don't have a kernel.org account ;-) But Stephen has and i suppose he'll put it there. Thanks, Frank --
Hi Frank, I was going to start providing tarballs yesterday, but other things happened :-( I will provide a next-YYYYMMDD.tar.gz file on kernel.org starting today. I will mention it in today's announcement. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
Hello Stephen, sorry, i didn't knew/considered you could have something prepared for this as well, as i couldn't see any feedback from you to this request for quite some time. So, i just thought i could try to take care of this point. But of course its much more handy when you just do it together when releasing a new linux-next. Thanks, Frank --
Hi Frank, Yeah, sorry, but the last few days have been a bit hectic ... should be I can easily generate them straight out of the tree on master.kernel.org. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au
Please add v4l-dvb tree, at: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-next.git The above tree has two branches: 'master' and 'stable' Both branches will have V4L/DVB next patches. The first is against your master, and the second, against your stable. I've opted to have both trees, since probably 'stable' is the better option for you to clone. On the other hand, 'master' allow me to foresee if an "alien" patch would conflict with a subsystem patch. Cheers, Mauro --
Hi Mauro, On Thu, 14 Feb 2008 15:38:50 -0200 Mauro Carvalho Chehab <mchehab@infradead= OK, this looks good (I should read ahead in my email before replying :-)). I will fetch the stable branch of this tree instead of the previous tree you sent me, OK? --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
On Fri, 15 Feb 2008 09:24:14 +1100 OK. Cheers, Mauro --
can you make stable rebase too? so we make git-bisect working by fold in some obvious bug fix. or that is linux-stable tree? YH --
Could you change the Makefile to show that if we build and run this tree, it really isn't Linus's tree? Yes, I know the -git number will be different, but that might not be very obvious to people reading bug reports on lkml. Just adding "-next" to the extraversion would be great. thanks, greg k-h --
A non-intrusive way to do so would be to add a file in the top-level directory and name it localversion*. For example: echo '-next' > localversion-next Sam --
Hi Sam, Excellent, I will do this for the next release. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
Hi Greg, Yes, sure, I should have though of that. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild.git master It is rebased from time to time and is what gets into -mm Sam --
Hi Sam, That's fine. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
Please add the 'NEXT' branch of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git to your list. This is a throwaway meta-branch that is rebased often. The 'master' branch of libata-dev.git always contains the base commit from torvalds/linux-2.6.git from which all other branches are based. I never ever commit to the 'master' branch, only update it from torvalds/linux-2.6.git. Andrew, I will continue to maintain the 'ALL' branch exactly as before. It may contain changes not suitable for 'NEXT', but suitable for -mm testing. In my new development process, things will almost always land in 'ALL' before 'NEXT'. Jeff --
Additional FYI: Don't be worried if "git diff master..NEXT" is empty from time to time. This condition occurs whenever the 'NEXT' queue is empty. Jeff --
So does this indicate the meaning of upstream and upstream-fixes is still the same? I always took upstream-fixes to be bug fixes for this -rc and upstream as queued for the next merge window, in which case NEXT would be the union of those two sets? James --
In practice, #upstream-fixes isn't very useful, because I send its contents to Linus very very rapidly once they are committed to that branch. I then locally delete that branch once Linus merges it, and re-create it [again, locally] the next time I have some bug fixes to apply. So it is a "somewhat throwaway" branch. The main utility of #upstream-fixes is so that I can do git branch upstream-linus upstream-fixes and then continue making commits in parallel with a Linus pull+push cycle. The #upstream branch is much more useful, because that is where things for the next kernel are stored, during a bug-fix-only cycle. This is largely equivalent to NEXT, though I plan to be more stringent in my requirements for NEXT commits than #upstream commits. One thing to note is that "pure" rebases are somewhat rare; I much prefer to wait until the batch of commits lands in torvalds/linux-2.6.git, before I blow away and recreate (with a new torvalds HEAD) the branch in question. So, to answer your question... Fixes should go upstream fast enough that they should hit NEXT implicitly via a Linus pull+push. It should be the union of two sets, yes, if a Linus cycle takes a long time. When both #upstream and #upstream-fixes are active, I tend to always branch #upstream off of #upstream-fixes and/or do a "git pull . upstream-fixes" when updating #upstream. Jeff --
Hi Jeff, Sounds like a good plan. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
Please add the 'linux-next' branch of git://git.linux-nfs.org/projects/trondmy/nfs-2.6.git Cheers Trond --
Hi Trond, On Thu, 14 Feb 2008 17:27:57 -0500 Trond Myklebust <trond.myklebust@fys.uio= Added, thanks. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
On Fri, 15 Feb 2008 16:00:57 -0500 "J. Bruce Fields" <bfields@fieldses.org>= Added, thanks. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au
The current XFS tree that goes into -mm is: git://oss.sgi.com:8090/xfs/xfs-2.6.git master Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --
Hi David, Added, thanks. I have put you as the contact point - is this correct? I notice that the MAINTAINERS file has a different contact for XFS. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
Yup - xfs-masters@oss.sgi.com. If you want a real person on the end of problem reports feel free to leave me there, but you should really also cc the xfs-masters address as well to guarantee that the problem is seen and dealt with promptly as I'm not always available..... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --
Hi David, OK, added. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
Hi Stephen, Could you please add Blackfin tree to the linux-next git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/blackfin-2.6.git for-linus Thanks a lot. And do you have the blackfin cross-compile toolchain? Regards, -Bryan --
On Fri, 15 Feb 2008 16:33:50 +0800 "Bryan Wu" <cooloney.lkml@gmail.com> wro= No, I don't at the moment. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au
You can grab (i386 rpms and tar ball) that should work from: http://blackfin.uclinux.org/gf/project/toolchain/frs/?action=FrsReleaseView&releas... You will need: - toolchain blackfin-toolchain-08r1-8.i386.rpm - c library (either one of): - blackfin-toolchain-uclibc-default-08r1-8.i386.rpm - blackfin-toolchain-uclibc-full-08r1-8.i386.rpm Other arch's & packages should appear shortly. -Robin --
Hi Robin, On Sat, 16 Feb 2008 21:23:47 -0500 Robin Getz <rgetz@blackfin.uclinux.org> = Thanks, I will have a look. My current build machines are powerpc, so I may have to wait ... --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au
Stephen, please add the for-next branch of linux1394-2.6.git to your
tree to receive updates for drivers/firewire/ and drivers/ieee1394/.
The URL is
master.kernel.org:/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git for-next
or via git protocol:
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git for-next
Contact addresses are:
Stefan Richter <stefanr@s5r6.in-berlin.de>
<linux1394-devel@lists.sourceforge.net>
Thanks.
--
Stefan Richter
-=====-==--- --=- =----
http://arcgraph.de/sr/
--
On Sat, 16 Feb 2008 16:13:40 +0100 (CET) Stefan Richter <stefanr@s5r6.in-be= Added, thanks. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
Hi Stephen: This tree gets rebased pretty much whenever Linus adds a new tag. As a rule of thumb, you should merge from Jean Delvare's i2c tree first. The hwmon/testing tree does not usually depend on anything else. Thanks & regards, -- Mark M. Hoffman mhoffman@lightlink.com --
Hi Mark, On Sun, 17 Feb 2008 14:09:57 -0500 "Mark M. Hoffman" <mhoffman@lightlink.co= Added, thanks. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/
Hi, The UBI tree which is here: git://git.infradead.org/~dedekind/ubi-2.6.git master -- Best Regards, Artem Bityutskiy (Артём Битюцкий) --
Hi Artem, On Mon, 18 Feb 2008 10:04:17 +0200 Artem Bityutskiy <dedekind@yandex.ru> wr= Added, thanks. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au
Hi Stephen, I would like to update the "The development process" section in Documentation/HOWTO including some information about the linux-next tree. I understand what it's including but I didn't get how it will fit in the process. Is Linus going to pull from that tree as soon as we reach -rc0 or this is just a tree used for testing what will be pushed to Linus as soon as the two weeks merge window open? Thanks. Ciao, -- Paolo http://paolo.ciarrocchi.googlepages.com/ --
Hi Paolo, On Mon, 18 Feb 2008 12:11:33 +0100 "Paolo Ciarrocchi" <paolo.ciarrocchi@gma= The intention is the latter. I hope to help people sort out some of the conflicts and cross subsystem issues before we get into the merge window and the code gets into Linus' tree. Andrew Morton also hopes that the linux-next tree may get more testing that the -mm tree did if we can stop it having to many regressions by only including the less experimental code that is destined for the next kernel release. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au
