Hi Russell,
On Sat, 16 Feb 2008 00:09:43 + Russell King <[EMAIL PROTECTED]> wrote:
>
> On Tue, Feb 12, 2008 at 12:02:08PM +1100, Stephen Rothwell wrote:
> > I will attempt to build the tree between each merge (and a failed build
> > will again cause the offending tree to be dropped). These
Hi Russell,
On Sat, 16 Feb 2008 00:09:43 + Russell King [EMAIL PROTECTED] wrote:
On Tue, Feb 12, 2008 at 12:02:08PM +1100, Stephen Rothwell wrote:
I will attempt to build the tree between each merge (and a failed build
will again cause the offending tree to be dropped). These builds
On Wed, Feb 20, 2008 at 07:13:16PM +0200, Adrian Bunk wrote:
> > A third option would be if people add new functions (with no users) in
> > -rc2 or -rc3 timeframes as long as it is part of a fully reviewed
> > patch with users that will use those new features in various kernel
> > development
On Wed, Feb 20, 2008 at 07:13:16PM +0200, Adrian Bunk wrote:
A third option would be if people add new functions (with no users) in
-rc2 or -rc3 timeframes as long as it is part of a fully reviewed
patch with users that will use those new features in various kernel
development trees.
...
On Wed, Feb 20, 2008 at 10:42:35AM -0500, Theodore Tso wrote:
> On Wed, Feb 20, 2008 at 04:38:52PM +0100, Stefan Richter wrote:
> > Two things may largely eliminate the need for parallel branches.
> >
> > 1. Do infrastructure changes and whole tree wide refactoring etc. in a
> > compatible manner
On Wed, Feb 20, 2008 at 04:38:52PM +0100, Stefan Richter wrote:
> Two things may largely eliminate the need for parallel branches.
>
> 1. Do infrastructure changes and whole tree wide refactoring etc. in a
> compatible manner with a brief but nonzero transition period.
>
> 2. Insert a second
Stephen Rothwell wrote:
> On Thu, 14 Feb 2008 10:01:14 -0800 (PST) Linus Torvalds <[EMAIL PROTECTED]>
> wrote:
>>
>> I absolutely have no problem with having a "this is the infrastrcture
>> changes that will go into the next release". In fact, I can even
>> *maintain* such a branch.
>>
>>
Hi Linus,
On Thu, 14 Feb 2008 10:01:14 -0800 (PST) Linus Torvalds <[EMAIL PROTECTED]>
wrote:
>
> I absolutely have no problem with having a "this is the infrastrcture
> changes that will go into the next release". In fact, I can even
> *maintain* such a branch.
>
> I've not wanted to open up
Hi Linus,
On Thu, 14 Feb 2008 10:01:14 -0800 (PST) Linus Torvalds [EMAIL PROTECTED]
wrote:
I absolutely have no problem with having a this is the infrastrcture
changes that will go into the next release. In fact, I can even
*maintain* such a branch.
I've not wanted to open up a second
Stephen Rothwell wrote:
On Thu, 14 Feb 2008 10:01:14 -0800 (PST) Linus Torvalds [EMAIL PROTECTED]
wrote:
I absolutely have no problem with having a this is the infrastrcture
changes that will go into the next release. In fact, I can even
*maintain* such a branch.
I've not wanted to
On Wed, Feb 20, 2008 at 04:38:52PM +0100, Stefan Richter wrote:
Two things may largely eliminate the need for parallel branches.
1. Do infrastructure changes and whole tree wide refactoring etc. in a
compatible manner with a brief but nonzero transition period.
2. Insert a second merge
On Wed, Feb 20, 2008 at 10:42:35AM -0500, Theodore Tso wrote:
On Wed, Feb 20, 2008 at 04:38:52PM +0100, Stefan Richter wrote:
Two things may largely eliminate the need for parallel branches.
1. Do infrastructure changes and whole tree wide refactoring etc. in a
compatible manner with a
Frank Seidel wrote:
> Lets get serious. I cannot speak for Ann and Harvey, but I'm quite sure they
> also really hope - at least i very strongly do - you not only call on us when
> things become a burden, but let us help and assist you right from the start.
I just started a little naive webpage
Frank Seidel wrote:
Lets get serious. I cannot speak for Ann and Harvey, but I'm quite sure they
also really hope - at least i very strongly do - you not only call on us when
things become a burden, but let us help and assist you right from the start.
I just started a little naive webpage
On Sun, 2008-02-17 at 16:25 +1100, Stephen Rothwell wrote:
> Hi James,
>
> On Sat, 16 Feb 2008 09:14:32 -0600 James Bottomley <[EMAIL PROTECTED]> wrote:
> >
> > Do you have the tree and build logs available anywhere? I'd like to
> > turn off the merge tree builds when this is able to replace it.
On Tue, 2008-02-12 at 12:24 -0600, James Bottomley wrote:
> Hm ... I think net is a counter example to this. Rebases certainly work
> for them.
That's a matter of opinion.
I'm working on cleaning up the libertas driver as and when I have time,
and the constant rebasing of the git trees
On Tue, 2008-02-12 at 12:24 -0600, James Bottomley wrote:
Hm ... I think net is a counter example to this. Rebases certainly work
for them.
That's a matter of opinion.
I'm working on cleaning up the libertas driver as and when I have time,
and the constant rebasing of the git trees
On Sun, 2008-02-17 at 16:25 +1100, Stephen Rothwell wrote:
Hi James,
On Sat, 16 Feb 2008 09:14:32 -0600 James Bottomley [EMAIL PROTECTED] wrote:
Do you have the tree and build logs available anywhere? I'd like to
turn off the merge tree builds when this is able to replace it.
The
Hi James,
On Sat, 16 Feb 2008 09:14:32 -0600 James Bottomley <[EMAIL PROTECTED]> wrote:
>
> Do you have the tree and build logs available anywhere? I'd like to
> turn off the merge tree builds when this is able to replace it.
The tree is at
On Fri, 2008-02-15 at 12:02 +1100, Stephen Rothwell wrote:
> Hi Roland,
>
> On Thu, 14 Feb 2008 15:22:46 -0800 Roland Dreier <[EMAIL PROTECTED]> wrote:
> >
> > For InfiniBand/RDMA, the tree is:
> >
> > master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
> > for-next
> >
> >
On Wed, 13 Feb 2008, Geert Uytterhoeven wrote:
> On Tue, 12 Feb 2008, Greg KH wrote:
> > On Tue, Feb 12, 2008 at 04:49:46PM -0800, Linus Torvalds wrote:
> > > On Tue, 12 Feb 2008, Greg KH wrote:
> > > > Perhaps you need to switch to using quilt. This is the main reason why
> > > > I use it.
> > >
On Sat, Feb 16, 2008 at 03:42:49AM +0300, Alexey Dobriyan wrote:
> On Fri, Feb 15, 2008 at 04:21:21PM -0800, Andrew Morton wrote:
> > On Sat, 16 Feb 2008 00:09:43 +
> > Russell King <[EMAIL PROTECTED]> wrote:
> >
> > > For reference, even _I_ don't build test the entire set of ARM defconfigs
On Sat, Feb 16, 2008 at 03:42:49AM +0300, Alexey Dobriyan wrote:
On Fri, Feb 15, 2008 at 04:21:21PM -0800, Andrew Morton wrote:
On Sat, 16 Feb 2008 00:09:43 +
Russell King [EMAIL PROTECTED] wrote:
For reference, even _I_ don't build test the entire set of ARM defconfigs
-
at
On Wed, 13 Feb 2008, Geert Uytterhoeven wrote:
On Tue, 12 Feb 2008, Greg KH wrote:
On Tue, Feb 12, 2008 at 04:49:46PM -0800, Linus Torvalds wrote:
On Tue, 12 Feb 2008, Greg KH wrote:
Perhaps you need to switch to using quilt. This is the main reason why
I use it.
Btw, on that
On Fri, 2008-02-15 at 12:02 +1100, Stephen Rothwell wrote:
Hi Roland,
On Thu, 14 Feb 2008 15:22:46 -0800 Roland Dreier [EMAIL PROTECTED] wrote:
For InfiniBand/RDMA, the tree is:
master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
for-next
or via git protocol:
Hi James,
On Sat, 16 Feb 2008 09:14:32 -0600 James Bottomley [EMAIL PROTECTED] wrote:
Do you have the tree and build logs available anywhere? I'd like to
turn off the merge tree builds when this is able to replace it.
The tree is at
On Sat, 16 Feb 2008 00:31:36 +
Russell King <[EMAIL PROTECTED]> wrote:
> > so would a stupid `for i in arch/arm/configs/*' script be sufficient
> > coverage?
>
> It will certainly improve the situation significantly, and pick up
> on some non-ARM problems like (badge4_defconfig, since
On Fri, Feb 15, 2008 at 04:21:21PM -0800, Andrew Morton wrote:
> On Sat, 16 Feb 2008 00:09:43 +
> Russell King <[EMAIL PROTECTED]> wrote:
>
> > For reference, even _I_ don't build test the entire set of ARM defconfigs -
> > at about 7 minutes a build, 75 defconfigs, that's about 9 hours... I
On Fri, Feb 15, 2008 at 04:21:21PM -0800, Andrew Morton wrote:
> On Sat, 16 Feb 2008 00:09:43 +
> Russell King <[EMAIL PROTECTED]> wrote:
>
> > For reference, even _I_ don't build test the entire set of ARM defconfigs -
> > at about 7 minutes a build, 75 defconfigs, that's about 9 hours... I
Russell King wrote:
On Fri, Feb 15, 2008 at 03:47:24PM -0800, Randy Dunlap wrote:
On Fri, 15 Feb 2008 15:37:32 -0800 Andrew Morton wrote:
I wonder why I didn't see any of this - I build arm allmodconfig at least
once a week, usually more frequently.
Basically, you don't build any of the PXA
On Fri, Feb 15, 2008 at 03:47:24PM -0800, Randy Dunlap wrote:
> On Fri, 15 Feb 2008 15:37:32 -0800 Andrew Morton wrote:
> > I wonder why I didn't see any of this - I build arm allmodconfig at least
> > once a week, usually more frequently.
Basically, you don't build any of the PXA platforms,
On Sat, 16 Feb 2008 00:09:43 +
Russell King <[EMAIL PROTECTED]> wrote:
> For reference, even _I_ don't build test the entire set of ARM defconfigs -
> at about 7 minutes a build, 75 defconfigs, that's about 9 hours... I
> just build those which are important to myself, hope that the others
On Sat, 16 Feb 2008 00:05:59 +0100
Roel Kluin <[EMAIL PROTECTED]> wrote:
> Alan Cox wrote:
> >> Evolution in nature and changes in code are different because in code junk
> >> and bugs are constantly removed. In biology junk is allowed and may provide
> >> a pool for future development. Linux
On Fri, 15 Feb 2008 15:47:24 -0800
Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Fri, 15 Feb 2008 15:37:32 -0800 Andrew Morton wrote:
>
> > On Fri, 15 Feb 2008 23:23:08 +
> > Russell King <[EMAIL PROTECTED]> wrote:
> >
> > > On Tue, Feb 12, 2008 at 12:48:13PM -0800, Greg KH wrote:
> > > > I
On Tue, Feb 12, 2008 at 12:02:08PM +1100, Stephen Rothwell wrote:
> I will attempt to build the tree between each merge (and a failed build
> will again cause the offending tree to be dropped). These builds will be
> necessarily restricted to probably one architecture/config. I will build
> the
On Fri, 15 Feb 2008 15:37:32 -0800 Andrew Morton wrote:
> On Fri, 15 Feb 2008 23:23:08 +
> Russell King <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Feb 12, 2008 at 12:48:13PM -0800, Greg KH wrote:
> > > I have tried, and successfully done this many times in the past. The
> > > kobject change
On Fri, 15 Feb 2008 23:23:08 +
Russell King <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 12, 2008 at 12:48:13PM -0800, Greg KH wrote:
> > I have tried, and successfully done this many times in the past. The
> > kobject change was one example: add a new function, migrate all users of
> > a direct
On Tue, Feb 12, 2008 at 12:48:13PM -0800, Greg KH wrote:
> I have tried, and successfully done this many times in the past. The
> kobject change was one example: add a new function, migrate all users of
> a direct pointer over to that function, after that work is all done and
> in, change the
Alan Cox wrote:
>> Evolution in nature and changes in code are different because in code junk
>> and bugs are constantly removed. In biology junk is allowed and may provide
>> a pool for future development. Linux development is intended and not
>> survival.
>
> I would be interested to see any
Linus Torvalds wrote:
>
> On Wed, 13 Feb 2008, Roel Kluin wrote:
>> In nature there is a lot of duplication: several copies of genes can exist
>> and different copies may have a distinct evolution.
>
> This is true of very complex animals, but much less so when looking at
> things like bacteria
On Thu, Feb 14, 2008 at 07:35:03PM +0200, Benny Halevy wrote:
> One idea that I thought about when debating rebase vs. merge (and it's
> far far from being fully baked) is versioned commits. The gist of it
> is that patches are assigned an hash identifier like today when they
> are first
On Fri, 15 Feb 2008 04:26:45 EST, Gene Heskett said:
> On Friday 15 February 2008, [EMAIL PROTECTED] wrote:
> >On Thu, 14 Feb 2008 13:32:02 EST, Gene Heskett said:
> >> Nvidia vs 2.6.25-rc1 being a case in point, and they (nvidia) are
> >> appearing to indicate its not a problem until some distro
On Friday 15 February 2008, [EMAIL PROTECTED] wrote:
>On Thu, 14 Feb 2008 13:32:02 EST, Gene Heskett said:
>> Nvidia vs 2.6.25-rc1 being a case in point, and they (nvidia) are
>> appearing to indicate its not a problem until some distro actually ships a
>> kernel with the changes that broke it.
On Friday 15 February 2008, [EMAIL PROTECTED] wrote:
On Thu, 14 Feb 2008 13:32:02 EST, Gene Heskett said:
Nvidia vs 2.6.25-rc1 being a case in point, and they (nvidia) are
appearing to indicate its not a problem until some distro actually ships a
kernel with the changes that broke it. That
On Fri, 15 Feb 2008 04:26:45 EST, Gene Heskett said:
On Friday 15 February 2008, [EMAIL PROTECTED] wrote:
On Thu, 14 Feb 2008 13:32:02 EST, Gene Heskett said:
Nvidia vs 2.6.25-rc1 being a case in point, and they (nvidia) are
appearing to indicate its not a problem until some distro actually
On Thu, Feb 14, 2008 at 07:35:03PM +0200, Benny Halevy wrote:
One idea that I thought about when debating rebase vs. merge (and it's
far far from being fully baked) is versioned commits. The gist of it
is that patches are assigned an hash identifier like today when they
are first committed
Linus Torvalds wrote:
On Wed, 13 Feb 2008, Roel Kluin wrote:
In nature there is a lot of duplication: several copies of genes can exist
and different copies may have a distinct evolution.
This is true of very complex animals, but much less so when looking at
things like bacteria (and
Alan Cox wrote:
Evolution in nature and changes in code are different because in code junk
and bugs are constantly removed. In biology junk is allowed and may provide
a pool for future development. Linux development is intended and not
survival.
I would be interested to see any evidence
On Tue, Feb 12, 2008 at 12:48:13PM -0800, Greg KH wrote:
I have tried, and successfully done this many times in the past. The
kobject change was one example: add a new function, migrate all users of
a direct pointer over to that function, after that work is all done and
in, change the
On Fri, 15 Feb 2008 23:23:08 +
Russell King [EMAIL PROTECTED] wrote:
On Tue, Feb 12, 2008 at 12:48:13PM -0800, Greg KH wrote:
I have tried, and successfully done this many times in the past. The
kobject change was one example: add a new function, migrate all users of
a direct pointer
On Tue, Feb 12, 2008 at 12:02:08PM +1100, Stephen Rothwell wrote:
I will attempt to build the tree between each merge (and a failed build
will again cause the offending tree to be dropped). These builds will be
necessarily restricted to probably one architecture/config. I will build
the
On Fri, 15 Feb 2008 15:37:32 -0800 Andrew Morton wrote:
On Fri, 15 Feb 2008 23:23:08 +
Russell King [EMAIL PROTECTED] wrote:
On Tue, Feb 12, 2008 at 12:48:13PM -0800, Greg KH wrote:
I have tried, and successfully done this many times in the past. The
kobject change was one
On Sat, 16 Feb 2008 00:09:43 +
Russell King [EMAIL PROTECTED] wrote:
For reference, even _I_ don't build test the entire set of ARM defconfigs -
at about 7 minutes a build, 75 defconfigs, that's about 9 hours... I
just build those which are important to myself, hope that the others are
On Fri, Feb 15, 2008 at 03:47:24PM -0800, Randy Dunlap wrote:
On Fri, 15 Feb 2008 15:37:32 -0800 Andrew Morton wrote:
I wonder why I didn't see any of this - I build arm allmodconfig at least
once a week, usually more frequently.
Basically, you don't build any of the PXA platforms, which is
Russell King wrote:
On Fri, Feb 15, 2008 at 03:47:24PM -0800, Randy Dunlap wrote:
On Fri, 15 Feb 2008 15:37:32 -0800 Andrew Morton wrote:
I wonder why I didn't see any of this - I build arm allmodconfig at least
once a week, usually more frequently.
Basically, you don't build any of the PXA
On Fri, Feb 15, 2008 at 04:21:21PM -0800, Andrew Morton wrote:
On Sat, 16 Feb 2008 00:09:43 +
Russell King [EMAIL PROTECTED] wrote:
For reference, even _I_ don't build test the entire set of ARM defconfigs -
at about 7 minutes a build, 75 defconfigs, that's about 9 hours... I
just
On Sat, 16 Feb 2008 00:05:59 +0100
Roel Kluin [EMAIL PROTECTED] wrote:
Alan Cox wrote:
Evolution in nature and changes in code are different because in code junk
and bugs are constantly removed. In biology junk is allowed and may provide
a pool for future development. Linux development is
On Fri, 15 Feb 2008 15:47:24 -0800
Randy Dunlap [EMAIL PROTECTED] wrote:
On Fri, 15 Feb 2008 15:37:32 -0800 Andrew Morton wrote:
On Fri, 15 Feb 2008 23:23:08 +
Russell King [EMAIL PROTECTED] wrote:
On Tue, Feb 12, 2008 at 12:48:13PM -0800, Greg KH wrote:
I have tried, and
On Sat, 16 Feb 2008 00:31:36 +
Russell King [EMAIL PROTECTED] wrote:
so would a stupid `for i in arch/arm/configs/*' script be sufficient
coverage?
It will certainly improve the situation significantly, and pick up
on some non-ARM problems like (badge4_defconfig, since 2.6.24-git2):
On Fri, Feb 15, 2008 at 04:21:21PM -0800, Andrew Morton wrote:
On Sat, 16 Feb 2008 00:09:43 +
Russell King [EMAIL PROTECTED] wrote:
For reference, even _I_ don't build test the entire set of ARM defconfigs -
at about 7 minutes a build, 75 defconfigs, that's about 9 hours... I
just
On Thu, 14 Feb 2008 12:32:29 PST, Greg KH said:
> How about "weeks". Both Fedora and openSUSE's next release is going to
> be based on 2.6.25, and the first round of -rc1 kernels should be
> showing up in their trees in a few days. So for this instance, I think
> you will be fine :)
a few days
On Thu, 14 Feb 2008 13:32:02 EST, Gene Heskett said:
> Nvidia vs 2.6.25-rc1 being a case in point, and they (nvidia) are appearing
> to
> indicate its not a problem until some distro actually ships a kernel with the
> changes that broke it. That could be months or even a year plus.
Actually
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Thu, 14 Feb 2008, Stephen Rothwell wrote:
> >
> > Originally, I assumed the stable branch would be for our "usual" API
> > changes, but it appears we are not having any more of those. :-)
>
> It's not that we should _never_ have them, it's that
Hi Roland,
On Thu, 14 Feb 2008 15:22:46 -0800 Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> For InfiniBand/RDMA, the tree is:
>
> master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-next
>
> or via git protocol:
>
>
> The first things I need from the subsystem maintainers (you know who you
> are) are a contact address (a list address is fine) and at least one git
> branch or quilt series that contains all the things you want to see go
> into 2.6.26.
For InfiniBand/RDMA, the tree is:
On Thursday 14 February 2008, Greg KH wrote:
>On Thu, Feb 14, 2008 at 01:32:02PM -0500, Gene Heskett wrote:
>> On Thursday 14 February 2008, Linus Torvalds wrote:
>> [...]
>>
>> >And this is where "process" really matters. Making sure people don't get
>> >too frustrated about the constant grind.
On Thu, Feb 14, 2008 at 01:32:02PM -0500, Gene Heskett wrote:
> On Thursday 14 February 2008, Linus Torvalds wrote:
> [...]
> >And this is where "process" really matters. Making sure people don't get
> >too frustrated about the constant grind.
>
> One of the problems caused by this 'grind' is
On Thursday 14 February 2008, Linus Torvalds wrote:
[...]
>And this is where "process" really matters. Making sure people don't get
>too frustrated about the constant grind.
One of the problems caused by this 'grind' is being locked out of using 3rd
party closed drivers until the vendor decides
On Thu, 14 Feb 2008, Stephen Rothwell wrote:
>
> Originally, I assumed the stable branch would be for our "usual" API
> changes, but it appears we are not having any more of those. :-)
It's not that we should _never_ have them, it's that they shouldn't be
"business as usual".
I'm happy with
On Feb. 13, 2008, 19:52 +0200, "J. Bruce Fields" <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 12, 2008 at 09:43:10PM -0800, Linus Torvalds wrote:
>> So just the fact that the right commit gets blamed when somebody does a
>> "git bisect" is I think a big issue. It's just fundamentally more fair to
>>
Hi Russell,
On Thu, 14 Feb 2008 08:14:05 + Russell King <[EMAIL PROTECTED]> wrote:
>
> On Tue, Feb 12, 2008 at 10:57:16PM +1100, Stephen Rothwell wrote:
> > We need to ask Linus to promise that he will pull the stable branch from
> > linux-next first in the merge window. For that to happen,
On Tue, Feb 12, 2008 at 10:57:16PM +1100, Stephen Rothwell wrote:
> We need to ask Linus to promise that he will pull the stable branch from
> linux-next first in the merge window. For that to happen, I would expect
> that Linus would also review and sign off (or ack) these commits to the
>
On Tue, Feb 12, 2008 at 10:57:16PM +1100, Stephen Rothwell wrote:
We need to ask Linus to promise that he will pull the stable branch from
linux-next first in the merge window. For that to happen, I would expect
that Linus would also review and sign off (or ack) these commits to the
Hi Russell,
On Thu, 14 Feb 2008 08:14:05 + Russell King [EMAIL PROTECTED] wrote:
On Tue, Feb 12, 2008 at 10:57:16PM +1100, Stephen Rothwell wrote:
We need to ask Linus to promise that he will pull the stable branch from
linux-next first in the merge window. For that to happen, I would
On Feb. 13, 2008, 19:52 +0200, J. Bruce Fields [EMAIL PROTECTED] wrote:
On Tue, Feb 12, 2008 at 09:43:10PM -0800, Linus Torvalds wrote:
So just the fact that the right commit gets blamed when somebody does a
git bisect is I think a big issue. It's just fundamentally more fair to
everybody.
On Thu, 14 Feb 2008, Stephen Rothwell wrote:
Originally, I assumed the stable branch would be for our usual API
changes, but it appears we are not having any more of those. :-)
It's not that we should _never_ have them, it's that they shouldn't be
business as usual.
I'm happy with them
On Thursday 14 February 2008, Linus Torvalds wrote:
[...]
And this is where process really matters. Making sure people don't get
too frustrated about the constant grind.
One of the problems caused by this 'grind' is being locked out of using 3rd
party closed drivers until the vendor decides its
On Thu, Feb 14, 2008 at 01:32:02PM -0500, Gene Heskett wrote:
On Thursday 14 February 2008, Linus Torvalds wrote:
[...]
And this is where process really matters. Making sure people don't get
too frustrated about the constant grind.
One of the problems caused by this 'grind' is being locked
On Thursday 14 February 2008, Greg KH wrote:
On Thu, Feb 14, 2008 at 01:32:02PM -0500, Gene Heskett wrote:
On Thursday 14 February 2008, Linus Torvalds wrote:
[...]
And this is where process really matters. Making sure people don't get
too frustrated about the constant grind.
One of the
The first things I need from the subsystem maintainers (you know who you
are) are a contact address (a list address is fine) and at least one git
branch or quilt series that contains all the things you want to see go
into 2.6.26.
For InfiniBand/RDMA, the tree is:
Hi Roland,
On Thu, 14 Feb 2008 15:22:46 -0800 Roland Dreier [EMAIL PROTECTED] wrote:
For InfiniBand/RDMA, the tree is:
master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-next
or via git protocol:
* Linus Torvalds [EMAIL PROTECTED] wrote:
On Thu, 14 Feb 2008, Stephen Rothwell wrote:
Originally, I assumed the stable branch would be for our usual API
changes, but it appears we are not having any more of those. :-)
It's not that we should _never_ have them, it's that they
On Thu, 14 Feb 2008 13:32:02 EST, Gene Heskett said:
Nvidia vs 2.6.25-rc1 being a case in point, and they (nvidia) are appearing
to
indicate its not a problem until some distro actually ships a kernel with the
changes that broke it. That could be months or even a year plus.
Actually
On Thu, 14 Feb 2008 12:32:29 PST, Greg KH said:
How about weeks. Both Fedora and openSUSE's next release is going to
be based on 2.6.25, and the first round of -rc1 kernels should be
showing up in their trees in a few days. So for this instance, I think
you will be fine :)
a few days ==
On Wed, Feb 13, 2008 at 01:24:41PM -0700, Ann Davis wrote:
> Frank Seidel wrote:
>>
>> Lets get serious. I cannot speak for Ann and Harvey, but I'm quite sure they
>> also really hope - at least i very strongly do - you not only call on us when
>> things become a burden, but let us help and assist
Frank Seidel wrote:
Lets get serious. I cannot speak for Ann and Harvey, but I'm quite sure they
also really hope - at least i very strongly do - you not only call on us when
things become a burden, but let us help and assist you right from the start.
Agreed. I'm happy to do daily builds
> Evolution in nature and changes in code are different because in code junk
> and bugs are constantly removed. In biology junk is allowed and may provide
> a pool for future development. Linux development is intended and not
> survival.
I would be interested to see any evidence (rather than
On Wed, 13 Feb 2008, Roel Kluin wrote:
>
> In nature there is a lot of duplication: several copies of genes can exist
> and different copies may have a distinct evolution.
This is true of very complex animals, but much less so when looking at
things like bacteria (and arguably, any current sw
On Wed, Feb 13, 2008 at 05:36:41AM -0500, Theodore Tso wrote:
> On Tue, Feb 12, 2008 at 10:16:53PM -0800, Greg KH wrote:
> > I was amazed at how slow stgit was when I tried it out. I use
> > git-quiltimport a lot and I don't think it's any slower than just using
> > quilt on its own. So I think
On Tue, Feb 12, 2008 at 09:09:34AM -0800, Linus Torvalds wrote:
>...
> The other is that once somebody says "ok, I *really* need to cause this
> breakage, because there's a major bug or we need it for fundamental reason
> XYZ", then that person should
>
> (a) create a base tree with _just_
On Tue, Feb 12, 2008 at 09:43:10PM -0800, Linus Torvalds wrote:
> So just the fact that the right commit gets blamed when somebody does a
> "git bisect" is I think a big issue. It's just fundamentally more fair to
> everybody. And it means that the people who push their work to me can
> really
On Tue, Feb 12, 2008 at 12:50:51PM -0800, Greg KH wrote:
> On Tue, Feb 12, 2008 at 07:46:51PM +, Al Viro wrote:
>...
> > AFAICS, we are in situation when review bandwidth is where the bottleneck
> > is. Not the merge one...
>
> Are there still large numbers of posted patches, not reviewed or
Linus Torvalds wrote:
>
> On Tue, 12 Feb 2008, Greg KH wrote:
>>> That's the point.
>> Not it isn't. To quote you a number of years ago:
>> "Linux is evolution, not intelligent design"
>
> Umm. Have you read a lot of books on evolution?
>
> It doesn't sound like you have.
>
> The fact
On Wed, Feb 13, 2008 at 10:06:16AM -0500, John W. Linville wrote:
> On Tue, Feb 12, 2008 at 06:47:30PM -0800, Joel Becker wrote:
> > Make the distinction earlier. With ocfs2 and configfs (we got
> > this scheme from Jeff), we keep the topic branches as "unsafe" - that
> > is, officially
On Tue, Feb 12, 2008 at 06:47:30PM -0800, Joel Becker wrote:
> Make the distinction earlier. With ocfs2 and configfs (we got
> this scheme from Jeff), we keep the topic branches as "unsafe" - that
> is, officially rebaseable . We merge them all into a big "ALL" branch,
> which is also
Stephen Rothwell wrote:
> On Tue, 12 Feb 2008 12:02:08 +1100 Stephen Rothwell wrote:
>> Andrew was looking for someone to run a linux-next tree that just
>> contained the subsystem git and quilt trees for 2.6.x+1 and I (in a
>> moment of madness) volunteered.
>
> I neglected to mention the other
On Wed, Feb 13, 2008 at 07:06:24AM -0500, Jeff Garzik wrote:
> Russell King wrote:
> >We know that the -mm tree is pretty much useless in terms of code
> >coverage for ARM, and it's getting increasingly unlikely that anything
> >short of a build of all ARM defconfigs will pick up on merge issues -
Russell King wrote:
We know that the -mm tree is pretty much useless in terms of code
coverage for ARM, and it's getting increasingly unlikely that anything
short of a build of all ARM defconfigs will pick up on merge issues -
which is a lot of CPU cycles, and I'm not going to insist its
On Tue, 2008-02-12 at 22:16 -0800, Greg KH wrote:
> Ted's description matches mine (keep quilt tree in git, edit changelog
> entries, rebase on newer kernel versions, etc.) I can go into details
> if needed.
I added some time ago patch history tracking in stgit and you can run
"stg log
On Tue, 2008-02-12 at 21:16 -0500, Theodore Tso wrote:
> I've never been very happy with stgit because of past experiences
> which has scarred me when it got get confused and lost my entire patch
> series (this was before git reflogs, so recovery was interesting).
It got much better now :-).
1 - 100 of 393 matches
Mail list logo
