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 :-).
On Tue, Feb 12, 2008 at 12:50:51PM -0800, Greg KH wrote:
> I can run the numbers, but almost every one of those changes has at
> least 2 signed-off-by: on them, so they should all be being reviewed
> properly.
Good joke..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
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 that the speed issue should be the same.
I like using "guilt" because
On Tue, Feb 12, 2008 at 09:51:52PM +, Alan Cox wrote:
> > We could simply decide that API changes affecting more than one subsystem
> > Must Be Serialized(tm). Explicitly. As in "any such change is posted
>
> Welcome to dreamland. The only way I can get serial changes done is to
> wait
On Tue, Feb 12, 2008 at 11:19:14AM -0800, Greg KH wrote:
> We usually get this warning today in -mm.
We don't always - and I'd say in terms of ARM it would be extremely rare.
The sysfs API changes at the start of the last merge window is one example
of this.
I had everything nicely prepared in
>
> 2) Let's move away from some/dir/{Kconfig,Makefile} schemes and
>instead have each "thing" have it's own Kconfig.foo or
>Makefile.foo that gets automatically sucked into the main
>directory Makefile or Kconfig using file globs or similar.
So we could do:
config foo
2) Let's move away from some/dir/{Kconfig,Makefile} schemes and
instead have each thing have it's own Kconfig.foo or
Makefile.foo that gets automatically sucked into the main
directory Makefile or Kconfig using file globs or similar.
So we could do:
config foo
tristate do
On Tue, Feb 12, 2008 at 11:19:14AM -0800, Greg KH wrote:
We usually get this warning today in -mm.
We don't always - and I'd say in terms of ARM it would be extremely rare.
The sysfs API changes at the start of the last merge window is one example
of this.
I had everything nicely prepared in
On Tue, Feb 12, 2008 at 09:51:52PM +, Alan Cox wrote:
We could simply decide that API changes affecting more than one subsystem
Must Be Serialized(tm). Explicitly. As in any such change is posted
Welcome to dreamland. The only way I can get serial changes done is to
wait months and
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 that the speed issue should be the same.
I like using guilt because I
On Tue, Feb 12, 2008 at 12:50:51PM -0800, Greg KH wrote:
I can run the numbers, but almost every one of those changes has at
least 2 signed-off-by: on them, so they should all be being reviewed
properly.
Good joke..
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
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 :-). We
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 [--graphical]
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 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 -
which
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 brave
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 unsafe.
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 rebaseable .
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 is, evolution often
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 choose
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 picked
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_ that
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, 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 that
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
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
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 you
Hi,
On Wednesday 13. February 2008, Sam Ravnborg wrote:
config foo
tristate do you want foo?
depends on USB BAR
module
obj-$(CONFIG_FOO) += foo.o
foo-y := file1.o file2.o
help
foo will allow you to explode your PC
I'm more thinking about
On Tue, 12 Feb 2008, Andrew Morton wrote:
> On Tue, 12 Feb 2008 16:41:49 -0800 (PST)
> David Miller <[EMAIL PROTECTED]> wrote:
>
> > Here are some odd-the-cuff
> > suggestions:
> >
> > 1) Make feature-removal-schedule a directory with files in it.
> >Everyone touches that file, creating
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 note: if some quilt user can send an
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 note: if some quilt user can send an "annotated history file"
> of their
On Tue, 12 Feb 2008, J. Bruce Fields wrote:
> > So as a result, some *random* commit that was actually fine on its own has
> > now become a bug, just because it was re-written.
>
> If there was a "fundamental thing that didn't cause a conflict", then
> the two trees in question probably
On Tue, 12 Feb 2008, Linus Torvalds wrote:
> Of course, if you didn't even want to save the old branch, just skip the
> first step. If you have reflogs enabled (and git does that by default in
> any half-way recent version), you can always find it again, even without
> having to do "git fsck
On Tue, 12 Feb 2008, Linus Torvalds wrote:
> So let's say that you have a remote branch that you track that goes
> rebasing (let's call it "origin/pu" to match the real-life git behaviour),
> then you should literally be able to do
>
> old=$(git rev-parse origin/pu) &&
> git fetch
After glancing at some of this thread its clear to me what Stephen's
real goal is:
1. collect kernel trees (or underpants)
2. ?
3. profit
http://en.wikipedia.org/wiki/Underpants_Gnomes
- k
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Tue, Feb 12, 2008 at 05:20:51PM -0800, David Miller wrote:
> From: Linus Torvalds <[EMAIL PROTECTED]>
> Date: Tue, 12 Feb 2008 16:44:47 -0800 (PST)
>
> > gitk --merge
> ...
> > This is something where I actually think git could and should do better:
> > git has the capability to act as
On Tue, Feb 12, 2008 at 05:31:10PM -0800, Linus Torvalds wrote:
> The importance of merging (rather, not screwing up history in general)
> becomes really obvious when things go tits-up. Then they go tits-up
> *without* screwing up the history of the trees that were hopefully tested
>
On Tue, Feb 12, 2008 at 09:00:16PM -0600, James Bottomley wrote:
> On Tue, 2008-02-12 at 18:35 -0800, Linus Torvalds wrote:
> >
> > On Tue, 12 Feb 2008, James Bottomley wrote:
> > >
> > > Yes, this is exactly the feature I'm looking for. It would allow the
> > > downstream users of a rebased
On Tue, 2008-02-12 at 19:31 -0800, Linus Torvalds wrote:
>
> On Tue, 12 Feb 2008, James Bottomley wrote:
> >
> > Right at the moment, I maintain a and a -base and
> > simply cherry pick the commits between the two to do the right thing
> > when I know my volatile base has changed. It would be
On Tue, 12 Feb 2008, Linus Torvalds wrote:
>
> git rebase --onto $new $old
..and in case it wasn't clear - this is just a general way of saying "move
the commits on this branch since $old to be based on top of $new" instead.
You can pick out those old/new commit ID's using gitk or
On Tue, 12 Feb 2008, James Bottomley wrote:
>
> Right at the moment, I maintain a and a -base and
> simply cherry pick the commits between the two to do the right thing
> when I know my volatile base has changed. It would be very helpful to
> have a version of rebase that new my base had been
On Tue, 2008-02-12 at 18:35 -0800, Linus Torvalds wrote:
>
> On Tue, 12 Feb 2008, James Bottomley wrote:
> >
> > Yes, this is exactly the feature I'm looking for. It would allow the
> > downstream users of a rebased tree to rebase themselves correctly.
> >
> > All the information about the
On Tue, Feb 12, 2008 at 06:20:12PM -0800, David Miller wrote:
> From: Andrew Morton <[EMAIL PROTECTED]>
> Date: Tue, 12 Feb 2008 18:06:13 -0800
>
> > So perhaps a better workflow would be keep the linux-next trees all
> > messy, and then each developer can consolidate, rebase, join and
> > drop
On Tue, 12 Feb 2008, James Bottomley wrote:
>
> Yes, this is exactly the feature I'm looking for. It would allow the
> downstream users of a rebased tree to rebase themselves correctly.
>
> All the information about the rebase is in the reflog ... it can't be
> too difficult to pass it
On Tue, 2008-02-12 at 17:20 -0800, David Miller wrote:
> What would be really cool is if you could do the rebase thing, push
> that to a remote tree you were already pushing into and others could
> pull from that and all the right things happen.
>
> A rebase is just a series of events, and those
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 18:06:13 -0800
> So perhaps a better workflow would be keep the linux-next trees all
> messy, and then each developer can consolidate, rebase, join and
> drop things prior to sending their individual trees to Linus.
We could do that,
On Tue, 12 Feb 2008, Andrew Morton wrote:
>
> So it would not be efficient for David to do all this queue-cleaning
> *prior* to putting the tree into linux-next, because more stuff will pop up
> anyway.
Well, what others have done is to have special "temporary branches".
This is what git
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 note: if some quilt user can send an "annotated history file"
> of their quilt
On Tue, 12 Feb 2008 17:57:19 -0800 (PST) Linus Torvalds <[EMAIL PROTECTED]>
wrote:
> - and you actually can help fix your issues by doing some simple things
>*before* pushing out, rather than push out immediately. IOW, do your
>whitespace sanity fixes, your compile checks etc early,
On Tue, 12 Feb 2008, David Miller wrote:
>
> Now how do I remove a bogus commit for a tree that I've already pushed
> out and published for other people, without any record of it appearing
> in the GIT tree any more?
So, the answer is: if others have actually pulled, it's simply not
possible.
On Tue, 12 Feb 2008 17:16:03 -0800 (PST) David Miller <[EMAIL PROTECTED]> wrote:
> From: Andrew Morton <[EMAIL PROTECTED]>
> Date: Tue, 12 Feb 2008 16:37:42 -0800
>
> > Well there's a case in point. rcupdate.h is not a part of networking, and
> > it is random tree-wandering like this which
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 17:41:19 -0800 (PST)
> Trust me, you don't know how good you have it.
I know, preserving history is valuable.
I'll take up the various suggestions and try working
a little differently this time around. We'll see
how well it works.
On Tue, 12 Feb 2008, David Miller wrote:
>
> But as soon as I've applied any patches to my tree I've "pushed out".
> So this scheme doesn't work for me. The first thing I do when I have
> changes to apply is clone a tree locally and on master.kernel.org,
> then I apply that first patch locally
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 17:31:10 -0800 (PST)
> You don't see the problems as much, because you merge probably only
> about a tenth of the volume I merge, and you can keep track of the
> subsystem more.
Good point.
Now how do I remove a bogus commit for a
On Tue, 12 Feb 2008, David Miller wrote:
>
> > Put another way: think of the absolute *chaos* that would happen if I were
> > to rebase instead of just merging. Every time I pull from you I'd
> > invalidate your whole tree, and you'd have to re-generate. It gets
> > unmaintainable very
On Tue, Feb 12, 2008 at 04:59:23PM -0800, Linus Torvalds wrote:
>
>
> On Wed, 13 Feb 2008, Al Viro wrote:
>
> > On Tue, Feb 12, 2008 at 07:16:50PM -0500, J. Bruce Fields wrote:
> > > > Ahem... Use of git-cherry-pick preserves commit information just fine.
> > >
> > > Not by default, at least
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 16:53:50 -0800 (PST)
> The fact is, that "outlying code" is where we have all the bulk of the
> code, and it's also where we have all those developers who aren't on the
> "inside track". So we should help the outliers, not the core
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 16:49:46 -0800 (PST)
> Btw, on that note: if some quilt user can send an "annotated history file"
> of their quilt usage, it's something that git really can do, and I'll see
> if I can merge (or rather, coax Junio to merge) the
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 16:47:26 -0800
> My usual way of fixing these things when they pop up is to just move
> the offending addition to some random position other than
> end-of-list. I must have done this hundreds of times and as yet I
> don't think
On Tue, 12 Feb 2008 12:02:08 +1100 Stephen Rothwell wrote:
> Hi all,
>
> 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. So, this is to announce the creating of
> such a
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 16:44:47 -0800 (PST)
> gitk --merge
...
> This is something where I actually think git could and should do better:
> git has the capability to act as more of a "quilt replacement", but
> because it wasn't part of the
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 16:37:42 -0800
> Well there's a case in point. rcupdate.h is not a part of networking, and
> it is random tree-wandering like this which causes me problems and which
> will cause Stephen problems.
>
> Now, I don't know which tree
On Wed, 13 Feb 2008, Al Viro wrote:
> On Tue, Feb 12, 2008 at 07:16:50PM -0500, J. Bruce Fields wrote:
> > > Ahem... Use of git-cherry-pick preserves commit information just fine.
> >
> > Not by default, at least (note they said "commiters", not "authors"):
>
> That's why you give it -r.
On Wed, Feb 13, 2008 at 12:48:41AM +, Al Viro wrote:
> On Tue, Feb 12, 2008 at 07:16:50PM -0500, J. Bruce Fields wrote:
> > > Ahem... Use of git-cherry-pick preserves commit information just fine.
> >
> > Not by default, at least (note they said "commiters", not "authors"):
>
> That's why
On Tue, 12 Feb 2008, David Miller wrote:
> From: Linus Torvalds <[EMAIL PROTECTED]>
> Date: Tue, 12 Feb 2008 10:59:00 -0800 (PST)
>
> > That sure as hell would put the pain on API changes solidly where it
> > belongs.
>
> If a person does a driver API change and does all the work to sweep
>
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 note: if some quilt user can send an "annotated history file"
of their quilt usage, it's something that git really can do, and I'll see
if I can merge (or
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 12:07:07 -0800 (PST)
>
>
> On Tue, 12 Feb 2008, J. Bruce Fields wrote:
> >
> > But the "author" is still preserved, right? Why do you need the
> > committer name to be preserved? (I'm not denying that there could be
> > reasons,
On Tue, Feb 12, 2008 at 07:16:50PM -0500, J. Bruce Fields wrote:
> > Ahem... Use of git-cherry-pick preserves commit information just fine.
>
> Not by default, at least (note they said "commiters", not "authors"):
That's why you give it -r.
--
To unsubscribe from this list: send the line
On Tue, 12 Feb 2008 16:41:49 -0800 (PST)
David Miller <[EMAIL PROTECTED]> wrote:
> Here are some odd-the-cuff
> suggestions:
>
> 1) Make feature-removal-schedule a directory with files in it.
>Everyone touches that file, creating merge issues.
>
> 2) Let's move away from
On Tue, 12 Feb 2008, David Miller wrote:
>
> At 1500 changesets, a merge conflict shows up about once
> every day or two as 2.6.N nears it's release into final
> as bug fixes trickle in.
>
> I find using GIT to fixup merge errors on a tree of that
> scale to be really painful. And it only
From: Greg KH <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 11:15:53 -0800
> On Tue, Feb 12, 2008 at 10:26:53AM -0800, Linus Torvalds wrote:
> > We absolutely MUST NOT have the mindset that "cross-subsystem conflicts
> > happen all the time".
>
> They usually don't, by virtue of our current
On Tue, 12 Feb 2008 15:58:53 -0800 (PST)
David Miller <[EMAIL PROTECTED]> wrote:
> But right now I have to redo the include/linux/rcupdate.h that's in
> there because it has a bug.
Well there's a case in point. rcupdate.h is not a part of networking, and
it is random tree-wandering like this
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 10:59:00 -0800 (PST)
> That sure as hell would put the pain on API changes solidly where it
> belongs.
If a person does a driver API change and does all the work to sweep
the entire tree updating all the drivers, doesn't it penalize
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 10:48:38 -0800 (PST)
> On Tue, 12 Feb 2008, James Bottomley wrote:
> > Yes ... I don't do that ... Like I said, I only rebase for an actual
> > conflict.
>
> And this is how things should work.
And if conflicts happen every day,
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 10:26:53 -0800 (PST)
> We absolutely MUST NOT have the mindset that "cross-subsystem conflicts
> happen all the time".
Perhaps not, but self-conflicts are the bigger issue for the
networking.
If I (or Jeff or John) push a bug fix
From: James Bottomley <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 12:24:42 -0600
> Hm ... I think net is a counter example to this. Rebases certainly work
> for them. The issue, I thought, was around the policy of rebasing and
> how often.
>
> I see the question as being one of who creates the
On Tue, Feb 12, 2008 at 03:58:53PM -0800, David Miller wrote:
> From: Jeff Garzik <[EMAIL PROTECTED]>
> Date: Tue, 12 Feb 2008 11:36:24 -0500
>
> > Rebasing is low impact only if you don't have git downstream people.
> > Otherwise, you're just treating it as a useful quilt clone, really.
>
>
On Tue, Feb 12, 2008 at 11:54:01PM +, Al Viro wrote:
> On Tue, Feb 12, 2008 at 03:51:07PM -0800, David Miller wrote:
> > From: Jeff Garzik <[EMAIL PROTECTED]>
> > Date: Tue, 12 Feb 2008 11:31:48 -0500
> >
> > > I understand the desire to want a nice and clean history, but the
> > > frequency
From: "John W. Linville" <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 12:04:22 -0500
> net-2.6.26 updates certain to go to the next release
> net-2.6.26-maybeupdates that might not make it to the next
> release
If I knew something was "maybe" ahead of time I
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 11:36:24 -0500
> Rebasing is low impact only if you don't have git downstream people.
> Otherwise, you're just treating it as a useful quilt clone, really.
Understood.
One of the key operations that I'm interested in is removing
On Tue, Feb 12, 2008 at 03:51:07PM -0800, David Miller wrote:
> From: Jeff Garzik <[EMAIL PROTECTED]>
> Date: Tue, 12 Feb 2008 11:31:48 -0500
>
> > I understand the desire to want a nice and clean history, but the
> > frequency here really has a negative impact on your downstreams.
>
> Ok, fair
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 11:31:48 -0500
> I understand the desire to want a nice and clean history, but the
> frequency here really has a negative impact on your downstreams.
Ok, fair enough. Any alternative suggestions on how to remove turds
without them
On Tue, Feb 12, 2008 at 12:48:13PM -0800, Greg KH wrote:
> On Tue, Feb 12, 2008 at 11:55:45AM -0800, Linus Torvalds wrote:
> > >
> > > Not it isn't. To quote you a number of years ago:
> > > "Linux is evolution, not intelligent design"
I think this statement has been used unfortunately as a
On Tue, Feb 12, 2008 at 10:59:00PM +, Alan Cox wrote:
> On Tue, 12 Feb 2008 14:55:31 -0800
> Greg KH <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Feb 12, 2008 at 10:20:44PM +, Alan Cox wrote:
> > > > I think the best way to get the serial drivers maintained would be to
> > > > cat
> > > >
On Tue, Feb 12, 2008 at 11:01:32PM +, Alan Cox wrote:
> > Hrm... How badly is pl2303 broken? I actually use that sucker, so if
> > it needs help - count me in.
>
> 2303 is pretty good (in fact by usb serial standards outstanding). It has
> all the internal locking needed for now and right
> Hrm... How badly is pl2303 broken? I actually use that sucker, so if
> it needs help - count me in.
2303 is pretty good (in fact by usb serial standards outstanding). It has
all the internal locking needed for now and right down to killing
lock_kernel entirely outside of open/close (which is
On Tue, 12 Feb 2008 14:55:31 -0800
Greg KH <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 12, 2008 at 10:20:44PM +, Alan Cox wrote:
> > > I think the best way to get the serial drivers maintained would be to cat
> > > them all onto the end of synclink.c and hope that Paul thinks he did it.
> >
> >
On Tue, Feb 12, 2008 at 10:20:44PM +, Alan Cox wrote:
> > I think the best way to get the serial drivers maintained would be to cat
> > them all onto the end of synclink.c and hope that Paul thinks he did it.
>
> Well I've already broken the buffering so he'd fix it ;)
>
> We have a pile of
On Mon, Feb 11, 2008 at 11:06:17PM -0800, Arjan van de Ven wrote:
> There is maybe a middle ground in this -next idea; as very first
> part of the series, the new api gets added, current users converted
> and api marked __deprecated.
>
> Then there's a second part to the patch, which is a
On Tue, Feb 12, 2008 at 10:20:44PM +, Alan Cox wrote:
> > I think the best way to get the serial drivers maintained would be to cat
> > them all onto the end of synclink.c and hope that Paul thinks he did it.
>
> Well I've already broken the buffering so he'd fix it ;)
>
> We have a pile of
On Feb 11 2008 20:21, Greg KH wrote:
>>
>> I hope to recreate this tree every day automatically. In order to do
>> this, any tree that has a conflict will be dropped from that days tree.
>
>Oh oh oh, I get merged first! me me me!
No, you can't have a tree like that. [森林 Not yours. 森林]
Let's
> I think the best way to get the serial drivers maintained would be to cat
> them all onto the end of synclink.c and hope that Paul thinks he did it.
Well I've already broken the buffering so he'd fix it ;)
We have a pile of old ISA drivers that are going to break soon with the
locking changes
On Tue, 12 Feb 2008 21:51:52 +
Alan Cox <[EMAIL PROTECTED]> wrote:
> > We could simply decide that API changes affecting more than one subsystem
> > Must Be Serialized(tm). Explicitly. As in "any such change is posted
>
> Welcome to dreamland. The only way I can get serial changes done is
> We could simply decide that API changes affecting more than one subsystem
> Must Be Serialized(tm). Explicitly. As in "any such change is posted
Welcome to dreamland. The only way I can get serial changes done is to
wait months and eventually simply persuade Andrew to ignore the
"maintainers"
On Tue, Feb 12, 2008 at 10:30:04AM -0800, Linus Torvalds wrote:
>
>
> On Tue, 12 Feb 2008, Jeff Garzik wrote:
>
> > Greg KH wrote:
> > > The work I'm doing here is for stupid PCI firmware engineers, who have
> > > created devices that are different things, all bound up under the same
> > > PCI
On Tue, 12 Feb 2008, Greg KH wrote:
>
> Yes, I agree, there are lots of examples of this, but the overall
> majority are reviewed by 2 people at least (or sure as hell should be,
> maybe we need to bring into existance the "reviewed-by" marking to
> ensure this.)
Well, I don't really "review"
101 - 200 of 403 matches
Mail list logo
