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 treeThere 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/
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
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:
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/
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 ismaster.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,
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-linusThanks 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=FrsReleaseV...
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.rpmOther 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
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/
Please add the 'linux-next' branch of
git://git.linux-nfs.org/projects/trondmy/nfs-2.6.git
Cheers
Trond--
And 'nfsd-next' at
git://git.linux-nfs.org/~bfields/linux.git nfsd-next
--b.
--
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
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/
Please add the 'NEXT' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.gitto 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
--
Hi Jeff,
Sounds like a good plan.
--=20
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
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
--
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
--
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/
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
--
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/
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-nextSam
--
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/
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
--
The point is that if you rebase it it's no longer stable.
--
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
--
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-next1Where the "base" version would be determinable from:
apw@pinky$ git describe --tags origin/stable
v2.6.25-rc1-120-ge760e71I 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/
I'd like to see tarballs too, please...
---
~Randy
--
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
--
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
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
--
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
--
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
--
// 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.tarCheers,
Harvey
--
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/
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/
Please add:
git://git.kernel.org/pub/scm/linux/kernel/git/shaggy/jfs-2.6.git nextThanks,
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/
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/
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/
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/
| Ingo Molnar | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
| Roland Dreier | Re: Integration of SCST in the mainstream Linux kernel |
git: | |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Arjan van de Ven | Re: [GIT]: Networking |
| Linus Torvalds | Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49 |
