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 ... :-)
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Fri, 15 Feb 2008, Stephen Rothwell wrote:
> 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.
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
On Thu, 14 Feb 2008 15:06:28 +0100 (CET) Jiri Kosina <[email protected]> wrote:
>
> On Fri, 15 Feb 2008, Stephen Rothwell wrote:
>
> > 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.
>
> 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 ...
Good idea. I have pushed out an extra commit that just contains the top
level "Trees" file.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Thursday, 14 of February 2008, Stephen Rothwell wrote:
> 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 ... :-)
Perhaps you can add:
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 test
Thanks,
Rafael
Hi Rafael,
On Thu, 14 Feb 2008 15:45:55 +0100 "Rafael J. Wysocki" <[email protected]> wrote:
>
> Perhaps you can add:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 test
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. :-)
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Fri, 2008-02-15 at 02:00 +1100, Stephen Rothwell wrote:
> 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. :-)
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.
On Fri, Feb 15, 2008 at 02:00:19AM +1100, Stephen Rothwell wrote:
> Hi Rafael,
>
> On Thu, 14 Feb 2008 15:45:55 +0100 "Rafael J. Wysocki" <[email protected]> wrote:
> >
> > Perhaps you can add:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 test
>
> 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. :-)
>
For SH:
master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.git
This is also what goes in to -mm.
On Fri, 2008-02-15 at 02:00 +1100, Stephen Rothwell wrote:
> 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. :-)
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
On Fri, Feb 15, 2008 at 12:35:37AM +1100, Stephen Rothwell wrote:
> 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).
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
> 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
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
On Thu, Feb 14, 2008 at 5:35 AM, Stephen Rothwell <[email protected]> wrote:
> 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).
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
On Feb. 14, 2008, 20:29 +0200, "Yinghai Lu" <[email protected]> wrote:
> On Thu, Feb 14, 2008 at 5:35 AM, Stephen Rothwell <[email protected]> wrote:
>> 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).
>
> can you make stable rebase too?
The point is that if you rebase it it's no longer stable.
Benny
>
> so we make git-bisect working by fold in some obvious bug fix.
>
> or that is linux-stable tree?
>
> YH
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Fri, Feb 15, 2008 at 12:35:37AM +1100, Stephen Rothwell wrote:
>
> So, comments, please.
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
>
> Also, more trees please ... :-)
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
On Thu, Feb 14, 2008 at 12:20:32PM -0800, Greg KH wrote:
> On Fri, Feb 15, 2008 at 12:35:37AM +1100, Stephen Rothwell wrote:
> >
> > So, comments, please.
>
> 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.
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
Stephen Rothwell wrote:
> Also, more trees please ... :-)
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
Jeff Garzik wrote:
> 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.
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
On Thu, 2008-02-14 at 16:03 -0500, Jeff Garzik wrote:
> Stephen Rothwell wrote:
> > Also, more trees please ... :-)
>
> 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'.
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
James Bottomley wrote:
> 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?
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 Martin,
On Thu, 14 Feb 2008 16:25:09 +0100 Martin Schwidefsky <[email protected]> wrote:
>
> For the s390 architecture please use the "features" branch of git390:
>
> git://git390.osdl.marist.edu/pub/scm/linux-2.6.git features
Added thanks.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
Hi Paul,
On Fri, 15 Feb 2008 00:49:28 +0900 Paul Mundt <[email protected]> wrote:
>
> For SH:
>
> master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.git
Added, thanks.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
Hi Dave,
On Thu, 14 Feb 2008 09:54:02 -0600 Dave Kleikamp <[email protected]> wrote:
>
> Please add:
> git://git.kernel.org/pub/scm/linux/kernel/git/shaggy/jfs-2.6.git next
Added, thanks.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
Hi Mauro,
On Thu, 14 Feb 2008 15:38:50 -0200 Mauro Carvalho Chehab <[email protected]> wrote:
>
> 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.
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?
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Fri, 2008-02-15 at 00:35 +1100, Stephen Rothwell wrote:
>
> Also, more trees please ... :-)
Please add the 'linux-next' branch of
git://git.linux-nfs.org/projects/trondmy/nfs-2.6.git
Cheers
Trond
On Fri, Feb 15, 2008 at 12:35:37AM +1100, Stephen Rothwell wrote:
> Also, more trees please ... :-)
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 Greg,
On Thu, 14 Feb 2008 12:20:32 -0800 Greg KH <[email protected]> wrote:
>
> 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.
Yes, sure, I should have though of that.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
Hi Sam,
On Thu, 14 Feb 2008 21:23:23 +0100 Sam Ravnborg <[email protected]> wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild.git master
Added, thanks.
> It is rebased from time to time and is what gets into -mm
That's fine.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
Hi Sam,
On Thu, 14 Feb 2008 21:50:31 +0100 Sam Ravnborg <[email protected]> wrote:
>
> 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
Excellent, I will do this for the next release.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
Hi Jeff,
On Thu, 14 Feb 2008 16:03:19 -0500 Jeff Garzik <[email protected]> wrote:
>
> 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.
Added, thanks.
> 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'.
Sounds like a good plan.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
Hi Trond,
On Thu, 14 Feb 2008 17:27:57 -0500 Trond Myklebust <[email protected]> wrote:
>
> Please add the 'linux-next' branch of
>
> git://git.linux-nfs.org/projects/trondmy/nfs-2.6.git
Added, thanks.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
Hi David,
On Fri, 15 Feb 2008 10:17:02 +1100 David Chinner <[email protected]> wrote:
>
> The current XFS tree that goes into -mm is:
>
> git://oss.sgi.com:8090/xfs/xfs-2.6.git master
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.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Fri, Feb 15, 2008 at 11:50:40AM +1100, Stephen Rothwell wrote:
> Hi David,
>
> On Fri, 15 Feb 2008 10:17:02 +1100 David Chinner <[email protected]> wrote:
> >
> > The current XFS tree that goes into -mm is:
> >
> > git://oss.sgi.com:8090/xfs/xfs-2.6.git master
>
> Added, thanks.
>
> I have put you as the contact point - is this correct?
Not really ;)
> I notice that the
> MAINTAINERS file has a different contact for XFS.
Yup - [email protected]. 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,
On Fri, 15 Feb 2008 12:10:42 +1100 David Chinner <[email protected]> wrote:
>
> > I notice that the
> > MAINTAINERS file has a different contact for XFS.
>
> Yup - [email protected]. 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.....
OK, added.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Thursday 14 February 2008 10:00, Stephen Rothwell wrote:
> Hi Rafael,
>
> On Thu, 14 Feb 2008 15:45:55 +0100 "Rafael J. Wysocki" <[email protected]> wrote:
> >
> > Perhaps you can add:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 test
>
> 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. :-)
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,
On Thu, 14 Feb 2008 23:58:38 -0500 Len Brown <[email protected]> wrote:
>
> Rafael has it right, please add the branch above.
> It will include both the upcoming ACPI and suspend patches.
Added, thanks, with you as contact.
> 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.
That is fine, I expect rebases.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Thu, Feb 14, 2008 at 9:35 PM, Stephen Rothwell <[email protected]> wrote:
> 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 ... :-)
>
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 Thu, Feb 14, 2008 at 05:27:57PM -0500, Trond Myklebust wrote:
>
> On Fri, 2008-02-15 at 00:35 +1100, Stephen Rothwell wrote:
> >
> > Also, more trees please ... :-)
>
> Please add the 'linux-next' branch of
>
> git://git.linux-nfs.org/projects/trondmy/nfs-2.6.git
And 'nfsd-next' at
git://git.linux-nfs.org/~bfields/linux.git nfsd-next
--b.
On 15 Feb, Stephen Rothwell wrote at LKML:
> 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.
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 <[email protected]>
<[email protected]>
Thanks.
--
Stefan Richter
-=====-==--- --=- =----
http://arcgraph.de/sr/
On Fri, 15 Feb 2008 16:33:50 +0800 "Bryan Wu" <[email protected]> wrote:
>
> 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
Added, thanks.
> And do you have the blackfin cross-compile toolchain?
No, I don't at the moment.
--
Cheers,
Stephen Rothwell [email protected]
On Fri, 15 Feb 2008 16:00:57 -0500 "J. Bruce Fields" <[email protected]> wrote:
>
> And 'nfsd-next' at
>
> git://git.linux-nfs.org/~bfields/linux.git nfsd-next
Added, thanks.
--
Cheers,
Stephen Rothwell [email protected]
On Sat, 16 Feb 2008 16:13:40 +0100 (CET) Stefan Richter <[email protected]> wrote:
>
> 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 <[email protected]>
> <[email protected]>
Added, thanks.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Sat 16 Feb 2008 10:33, Stephen Rothwell pondered:
> On Fri, 15 Feb 2008 16:33:50 +0800 "Bryan Wu" <[email protected]> wrote:
> >
> > 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
>
> Added, thanks.
>
> > And do you have the blackfin cross-compile toolchain?
>
> No, I don't at the moment.
You can grab (i386 rpms and tar ball) that should work from:
http://blackfin.uclinux.org/gf/project/toolchain/frs/?action=FrsReleaseView&release_id=375
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 <[email protected]> wrote:
>
> You can grab (i386 rpms and tar ball) that should work from:
>
> http://blackfin.uclinux.org/gf/project/toolchain/frs/?action=FrsReleaseView&release_id=375
>
> 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.
Thanks, I will have a look. My current build machines are powerpc, so I
may have to wait ...
--
Cheers,
Stephen Rothwell [email protected]
Hi Stephen:
* Stephen Rothwell <[email protected]> [2008-02-15 00:35:37 +1100]:
> 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 ... :-)
You can add the hwmon testing tree (from MAINTAINERS):
> git lm-sensors.org:/kernel/mhoffman/hwmon-2.6.git testing
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
[email protected]
Hi Mark,
On Sun, 17 Feb 2008 14:09:57 -0500 "Mark M. Hoffman" <[email protected]> wrote:
>
> You can add the hwmon testing tree (from MAINTAINERS):
>
> > git lm-sensors.org:/kernel/mhoffman/hwmon-2.6.git testing
>
> 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.
Added, thanks.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
Hi,
Stephen Rothwell wrote:
> Also, more trees please ... :-)
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 <[email protected]> wrote:
>
> The UBI tree which is here:
>
> git://git.infradead.org/~dedekind/ubi-2.6.git master
Added, thanks.
--
Cheers,
Stephen Rothwell [email protected]
On Feb 14, 2008 2:35 PM, Stephen Rothwell <[email protected]> wrote:
> Hi all,
>
> I have created the first cut of the linux-next tree at
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" <[email protected]> wrote:
>
> 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?
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.
--
Cheers,
Stephen Rothwell [email protected]
On Fri, 15 Feb 2008 09:24:14 +1100
Stephen Rothwell <[email protected]> wrote:
> Hi Mauro,
>
> On Thu, 14 Feb 2008 15:38:50 -0200 Mauro Carvalho Chehab <[email protected]> wrote:
> >
> > 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.
>
> 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?
OK.
Cheers,
Mauro
Hi Andy,
On Thu, 14 Feb 2008 16:04:36 +0000 Andy Whitcroft <[email protected]> wrote:
>
> 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.
I hope I have addressed this issue by tagging each tree with its date
i.e. todays was next-20080220.
> 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".
I hadn't considered tarballs, but I will give it some thought.
Thanks for your thoughts.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Thu, 21 Feb 2008 01:23:32 +1100 Stephen Rothwell wrote:
> Hi Andy,
>
> On Thu, 14 Feb 2008 16:04:36 +0000 Andy Whitcroft <[email protected]> wrote:
> >
> > 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.
>
> I hope I have addressed this issue by tagging each tree with its date
> i.e. todays was next-20080220.
>
> > 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".
>
> I hadn't considered tarballs, but I will give it some thought.
I'd like to see tarballs too, please...
---
~Randy
Randy Dunlap wrote:
> I'd like to see tarballs too, please...
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
Frank Seidel wrote:
> Randy Dunlap wrote:
>> I'd like to see tarballs too, please...
>
> 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?
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
On Fri, Feb 22, 2008 at 01:07:01AM +0100, Frank Seidel wrote:
> Randy Dunlap wrote:
> > I'd like to see tarballs too, please...
>
> 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?
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
On Thu, 2008-02-21 at 16:12 -0800, Randy Dunlap wrote:
> Frank Seidel wrote:
> > Randy Dunlap wrote:
> >> I'd like to see tarballs too, please...
> >
> > 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?
>
> 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.
>
// 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
Hi Frank,
On Fri, 22 Feb 2008 01:07:01 +0100 Frank Seidel <[email protected]> wrote:
>
> 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?
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.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
Randy Dunlap wrote:
> 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.
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
Greg KH wrote:
> Any reason we can't get these on kernel.org so that the mirror system
> will kick in for the whole world?
Only that i don't have a kernel.org account ;-) But Stephen has and
i suppose he'll put it there.
Thanks,
Frank
Hello Stephen,
Stephen Rothwell wrote:
> On Fri, 22 Feb 2008 01:07:01 +0100 Frank Seidel <[email protected]> wrote:
>> 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?
>
> 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.
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,
On Fri, 22 Feb 2008 06:41:00 +0100 Frank Seidel <[email protected]> wrote:
>
> Stephen Rothwell wrote:
> > On Fri, 22 Feb 2008 01:07:01 +0100 Frank Seidel <[email protected]> wrote:
> >> 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?
> >
> > 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.
>
> 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.
Yeah, sorry, but the last few days have been a bit hectic ... should be
better from now on, I hope. Don't be sorry - I like enthusiasm.
> 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.
I can easily generate them straight out of the tree on master.kernel.org.
--
Cheers,
Stephen Rothwell [email protected]