> [BUILDFIX PATCH] au0828: debug is a poor global identifier

Another issue for which I already sent a (slightly different) patch.

Why not check the mailing list before duplicating work? [1]

And if you e.g. discover next that our x86 userspace headers in
2.6.25 (sic) are ****ed up guess who already sent a patch last
weekend... [2]

Why do other people get over 100 checkpatch fixes into the tree at once
or Linus applies patches directly bypassing the maintainers (like the
one you sent just before [3], which I've also already sent before [4])
but my patches bitrot forever?

And Linus didn't even bother to answer what the correct path for my
patches is. [5]

My current record is sending a patch 7 times (and still counting)
without it getting applied anywhere. [6]

And if anyone has doubts in the quality of my patches try to find
commits of me in Linus' tree that introduced any bugs - you most
likely won't find 3 buggy commits among my last 500 commits.

Guys, this is neither a kindergarten nor the right place for corporate
mobbing games. If you want to get rid of me simply say so and I'll
immediately unsubscribe and stop bothering you with patches.

Really annoyed
Adrian

[1] http://lkml.org/lkml/2008/4/25/376
[2] http://lkml.org/lkml/2008/4/20/181
[3] http://lkml.org/lkml/2008/4/25/511
[4] http://lkml.org/lkml/2008/4/24/523
[5] http://lkml.org/lkml/2008/4/2/369
[6] http://lkml.org/lkml/2008/4/21/523
http://lkml.org/lkml/2008/4/21/577

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi Adrian.

> Why do other people get over 100 checkpatch fixes into the tree at once
> or Linus applies patches directly bypassing the maintainers (like the
> one you sent just before [3], which I've also already sent before [4])
> but my patches bitrot forever?

The patches you submit touches all parts of the kernel tree.
And you do a good job in finding the relevant receivers.

To me you are partly in the saem situation as Andrew in that
you handle a great deal of patches touching a lot of different
subsystems.
We all know that the patch acceptance ratio differ a lot between
the different maintainers and the way Andrew deals with this
seems quite effective.
After enough tries Andrew just submit the pacthes himself direct
to Linus. But almost never without trying to get the relevant
Maintainer to take it first.
So in your position I would keep all patches in
a place so they can be sucked into -next and regular spam
the relevant amintainers with their patches.
When the merge window opens then submit the rest to Linus
with a noe that they have been sent to Maintainers without
any feedback previously.

This is not far away from what you do now and should not create
that big frustrations (I hope).

Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Sat, Apr 26, 2008 at 01:27:17PM +0200, Sam Ravnborg wrote:
> Hi Adrian.

Hi Sam,

> > Why do other people get over 100 checkpatch fixes into the tree at once
> > or Linus applies patches directly bypassing the maintainers (like the
> > one you sent just before [3], which I've also already sent before [4])
> > but my patches bitrot forever?
>
> The patches you submit touches all parts of the kernel tree.
> And you do a good job in finding the relevant receivers.
>
> To me you are partly in the saem situation as Andrew in that
> you handle a great deal of patches touching a lot of different
> subsystems.
>...

Linus takes patches from people like Andrew, Al and Harvey directly,
but he doesn't take the same patches directly from me.

Whatever applies to these people doesn't help me.

> So in your position I would keep all patches in
> a place so they can be sucked into -next and regular spam
> the relevant amintainers with their patches.
> When the merge window opens then submit the rest to Linus
> with a noe that they have been sent to Maintainers without
> any feedback previously.
>
> This is not far away from what you do now and should not create
> that big frustrations (I hope).

You missed the "And Linus didn't even bother to answer what the correct
path for my patches is."

I'd have no problem creating a git tree for such stuff.

But if Linus doesn't bother to tell me how he wants to get patches from
me he most likely also won't bother to pull from my tree.


And it wouldn't be usable for bugfixes that should get into 2.6.26.

It might e.g. make sense to let maintainers handle fixes and let them
decide whether they want a patch this way, but if my patch goes through
the maintainer and later Linus applies the same patch by someone else
directly it simply makes no sense that I spend my spare time on fixing
bugs in the kernel.


> Sam

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Sat, 26 Apr 2008 14:00:44 +0300 Adrian Bunk wrote:

> Why do other people get over 100 checkpatch fixes into the tree at once
> or Linus applies patches directly bypassing the maintainers (like the
> one you sent just before [3], which I've also already sent before [4])
> but my patches bitrot forever?

If I am not cc'ed on a patch and have to resort to plucking it off the
mailing list it ends up being significantly more work and more error-prone
for me to process it.

I used to merge your patches but then you chose to stop ccing me on them so
I stopped applying them. The increased hassle just isn't worth it for some
random make-foo-static patch. I do try to keep an eye out for more
significant changes but hey, stuff happens.

You chose to disrupt the workflow and now you're here complaining and blaming
others for the consequences of your own action.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Sat, Apr 26, 2008 at 07:51:32AM -0700, Andrew Morton wrote:
> On Sat, 26 Apr 2008 14:00:44 +0300 Adrian Bunk wrote:
>
> > Why do other people get over 100 checkpatch fixes into the tree at once
> > or Linus applies patches directly bypassing the maintainers (like the
> > one you sent just before [3], which I've also already sent before [4])
> > but my patches bitrot forever?
>
> If I am not cc'ed on a patch and have to resort to plucking it off the
> mailing list it ends up being significantly more work and more error-prone
> for me to process it.
>
> I used to merge your patches but then you chose to stop ccing me on them so
> I stopped applying them. The increased hassle just isn't worth it for some
> random make-foo-static patch. I do try to keep an eye out for more
> significant changes but hey, stuff happens.
>
> You chose to disrupt the workflow and now you're here complaining and blaming
> others for the consequences of your own action.


Why didn't you tell me an explicit Cc is important for you?

I'll resend my pending batch with a Cc to you.


That only leaves the question why bugfixes are directly applied by Linux
when they come from other people, but not when they come from me. Is
there also a Cc required? But my patch for the x86 userspace headers
****up was Cc'ed to Linus (and I can't send it to -stable before it is
in Linus' tree).

Is the correct path for bug fixes to go through the maintainer or to go
directly through Linus? And in the latter case, what was wrong with my
patches?


cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Sat, 26 Apr 2008 18:23:41 +0300 Adrian Bunk wrote:

> On Sat, Apr 26, 2008 at 07:51:32AM -0700, Andrew Morton wrote:
> > On Sat, 26 Apr 2008 14:00:44 +0300 Adrian Bunk wrote:
> >
> > > Why do other people get over 100 checkpatch fixes into the tree at once
> > > or Linus applies patches directly bypassing the maintainers (like the
> > > one you sent just before [3], which I've also already sent before [4])
> > > but my patches bitrot forever?
> >
> > If I am not cc'ed on a patch and have to resort to plucking it off the
> > mailing list it ends up being significantly more work and more error-prone
> > for me to process it.
> >
> > I used to merge your patches but then you chose to stop ccing me on them so
> > I stopped applying them. The increased hassle just isn't worth it for some
> > random make-foo-static patch. I do try to keep an eye out for more
> > significant changes but hey, stuff happens.
> >
> > You chose to disrupt the workflow and now you're here complaining and blaming
> > others for the consequences of your own action.
>
>
> Why didn't you tell me an explicit Cc is important for you?

Don't know, really. Something in me resiles from going and doing things
which increase the patch volume, perhaps.

> I'll resend my pending batch with a Cc to you.

OK.

Many of your make-static-foo-etc patches are in fact fixes against
recently-merged changes, I think. It's better to get those fixes folded
into the errant patch before things go into mainline: we get one correct
commit in the permanent record rather than one dodgy commit followed by a
later oh-let's-fix-that-up commit.

So I'd encourage you to try to catch these things in -mm or linux-next and,
if poss (and I know it's a bit of work), identify the offending commit.

git-tree owners might need, umm, some encouragement here. It's much easier
for them to slap the oh-let's-fix-that-up commit at the tail of their
queue, which leaves us with the straggly commit record.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Saturday 26 April 2008, you wrote:
> > [BUILDFIX PATCH] au0828: debug is a poor global identifier
>
> Another issue for which I already sent a (slightly different) patch.
>
> Why not check the mailing list before duplicating work? [1]
>
> And if you e.g. discover next that our x86 userspace headers in
> 2.6.25 (sic) are ****ed up guess who already sent a patch last
> weekend... [2]
>
> Why do other people get over 100 checkpatch fixes into the tree at once
> or Linus applies patches directly bypassing the maintainers (like the
> one you sent just before [3], which I've also already sent before [4])
> but my patches bitrot forever?
>
> And Linus didn't even bother to answer what the correct path for my
> patches is. [5]

Linus just can't tell you directly to send him pull requests for patches
touching kernel areas which are (or are supposed to be) maintained by other
people but he isn't going to ignore properly justified git pull requests
(see below).

Also you may try this for your changes:

* set -mm like tree containing all pending patches
(+ ask for inclusion into -next tree and -mm tree)

* send tree status updates to LKML (w/ some "marketing") regularly

* send git pull requests to Linus with changes ACK-ed by relevant
parties or lacking feedback (> 1 month timeout)

> My current record is sending a patch 7 times (and still counting)
> without it getting applied anywhere. [6]

Please send a git pull request with v850 removal to Linus noting that:

* the code has been broken for ages (since 2.6.19) and maintainer
cannot be even reached, according to MAINTAINERS:

UCLINUX FOR NEC V850
P: Miles Bader

* the patch was posted multiple times (first 3 months ago)
and there were no complains

* you've got an ACK from Greg Ungerer and you may add mine
(FWIW, ACK-s from other arch maintainers would be more valuable),

also back in February Ingo was positive about removing v850
port and suggested adding info about it to

Documentation/feature-removal-schedule.txt

as a prerequisite for the removal (unfortunately it hasn't happened?)

> And if anyone has doubts in the quality of my patches try to find
> commits of me in Linus' tree that introduced any bugs - you most
> likely won't find 3 buggy commits among my last 500 commits.

Nobody questions quality of your patches - the problem is that they are
spread all over the tree and are likely to conflict with other people's
trees. Setting your own tree and putting it into -next tree seems like
a best solution for this. It should also help in preventing duplicated
work / patches getting lost.

Thanks,
Bart

> Guys, this is neither a kindergarten nor the right place for corporate
> mobbing games. If you want to get rid of me simply say so and I'll
> immediately unsubscribe and stop bothering you with patches.
>
> Really annoyed
> Adrian
>
> [1] http://lkml.org/lkml/2008/4/25/376
> [2] http://lkml.org/lkml/2008/4/20/181
> [3] http://lkml.org/lkml/2008/4/25/511
> [4] http://lkml.org/lkml/2008/4/24/523
> [5] http://lkml.org/lkml/2008/4/2/369
> [6] http://lkml.org/lkml/2008/4/21/523
> http://lkml.org/lkml/2008/4/21/577
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Sat, 26 Apr 2008, Adrian Bunk wrote:
>
> Linus takes patches from people like Andrew, Al and Harvey directly,
> but he doesn't take the same patches directly from me.

It's because I hate you.

Oh, no, wait.

It's because you didn't send the patch to me.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Sat, Apr 26, 2008 at 09:51:48AM -0700, Linus Torvalds wrote:
>
>
> On Sat, 26 Apr 2008, Adrian Bunk wrote:
> >
> > Linus takes patches from people like Andrew, Al and Harvey directly,
> > but he doesn't take the same patches directly from me.
>
> It's because I hate you.
>
> Oh, no, wait.
>
> It's because you didn't send the patch to me.

The patch for the x86 userspace header breakage last weekend was Cc'ed
to you.

> Linus

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Sat, Apr 26, 2008 at 08:44:20AM -0700, Andrew Morton wrote:
>...
> git-tree owners might need, umm, some encouragement here. It's much easier
> for them to slap the oh-let's-fix-that-up commit at the tail of their
> queue, which leaves us with the straggly commit record.

As far as I understand Linus on these matters people David Miller
mustn't edit older commits in their trees once their tree got pushed
out.

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Sat, Apr 26, 2008 at 02:00:44PM +0300, Adrian Bunk wrote:
>...
> And if you e.g. discover next that our x86 userspace headers in
> 2.6.25 (sic) are ****ed up guess who already sent a patch last
> weekend... [2]
>...

Sorry, I got that wrong.

It was a past 2.6.25 breakage.

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Sat, 26 Apr 2008 20:16:04 +0300 Adrian Bunk wrote:

> On Sat, Apr 26, 2008 at 08:44:20AM -0700, Andrew Morton wrote:
> >...
> > git-tree owners might need, umm, some encouragement here. It's much easier
> > for them to slap the oh-let's-fix-that-up commit at the tail of their
> > queue, which leaves us with the straggly commit record.
>
> As far as I understand Linus on these matters people David Miller
> mustn't edit older commits in their trees once their tree got pushed
> out.

I expect that means "don't alter stuff after you've sent the pull request".
That'd be fairly dumb.

But during the two-month -rcX timeframe the patches in the git and quilt
trees get altered, dropped, reordered regularly. Some of the git trees
don't really exist, I believe - their owners assemble them from a
quilt-based master tree for external sharing only.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Sat, Apr 26, 2008 at 10:20:24AM -0700, Andrew Morton wrote:
> On Sat, 26 Apr 2008 20:16:04 +0300 Adrian Bunk wrote:
>
> > On Sat, Apr 26, 2008 at 08:44:20AM -0700, Andrew Morton wrote:
> > >...
> > > git-tree owners might need, umm, some encouragement here. It's much easier
> > > for them to slap the oh-let's-fix-that-up commit at the tail of their
> > > queue, which leaves us with the straggly commit record.
> >
> > As far as I understand Linus on these matters people David Miller
> > mustn't edit older commits in their trees once their tree got pushed
> > out.
>
> I expect that means "don't alter stuff after you've sent the pull request".
> That'd be fairly dumb.
>
> But during the two-month -rcX timeframe the patches in the git and quilt
> trees get altered, dropped, reordered regularly. Some of the git trees
> don't really exist, I believe - their owners assemble them from a
> quilt-based master tree for external sharing only.

As far as I understand it, changes in Daves tree would cause problems
for people like Jeff Garzik and John Linville who themselves base their
work on Daves tree during the two-month -rcX timeframe.

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Sat, 26 Apr 2008, Adrian Bunk wrote:
>
> The patch for the x86 userspace header breakage last weekend was Cc'ed
> to you.

Yes, and I couldn't care less - it wasn't critical in any way (nobody
should be using kernel headers directly in user space anyway, so the only
people who could _possibly_ care were the people who build glibc releases
etc).

IOW, it wasn't a critical bug-fix that needed to be pushed out
aggressively.

Which means that I totally ignore a patch when I see that there are people
who actually maintain that area (especially if I know they are responsible
maintainers) that are also cc'd and that even reply to it.

It so happens that that patch got merged into my tree today - unrelated to
this discussion - and it came through all the normal channels (ie the x86
maintainer tree).

IOW, everything happened exactly the way it is SUPPOSED to happen.

That said, it also obviously does happen that I lose patches for real.
Maybe some of them even from you. But your complaints really aren't
sensible in this case.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Sat, 26 Apr 2008, Adrian Bunk wrote:
> On Sat, Apr 26, 2008 at 08:44:20AM -0700, Andrew Morton wrote:
> >...
> > git-tree owners might need, umm, some encouragement here. It's much easier
> > for them to slap the oh-let's-fix-that-up commit at the tail of their
> > queue, which leaves us with the straggly commit record.
>
> As far as I understand Linus on these matters people David Miller
> mustn't edit older commits in their trees once their tree got pushed
> out.

I wouldn't say "mustn't", because the _one_ thing I hate is totally rigid
rules.

What I do try to encourage is for people to think publicising their git
trees as "version announcements". They're obviously _development_
versions, but they're still real versions, and before you publicize them
you should try to make sure that they make sense and are something you can
stand behind.

And once you've publicized them, you don't know who has that tree, so just
from a sanity and debugging standpoint, you should try to avoid mucking
with already-public versions. If you made a mistake, add a patch on top to
fix it (and announce the new state), but generally try to not "hide" the
fact that the state has changed.

But it's not a hard rule. Sometimes simple cleanliness means that you can
decide to go "oops, that was *really* wrong, let's just throw that away
and do a whole new set of patches". But it should be something rare - not
normal coding practice.

Because if it becomes normal coding practice, now people cannot work with
you sanely any more (ie some random person pulls your tree for testing,
and then I pull it at some other time, and the tester reports a problem,
but now the commits he is talking about don't actually even exist in my
tree any more, and it's all really messy!).

The x86 tree still does this. I absolutely detest it. Ingo claims that his
model is better, and I'm pretty damn sure he's wrong. But until it starts
causing bigger problems, I'll give him the benefit of the doubt.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Sat, 26 Apr 2008, Adrian Bunk wrote:

> On Sat, Apr 26, 2008 at 10:20:24AM -0700, Andrew Morton wrote:
> >
> > I expect that means "don't alter stuff after you've sent the pull request".
> > That'd be fairly dumb.
> >
> > But during the two-month -rcX timeframe the patches in the git and quilt
> > trees get altered, dropped, reordered regularly. Some of the git trees
> > don't really exist, I believe - their owners assemble them from a
> > quilt-based master tree for external sharing only.
>
> As far as I understand it, changes in Daves tree would cause problems
> for people like Jeff Garzik and John Linville who themselves base their
> work on Daves tree during the two-month -rcX timeframe.

Yes. It really depends on how people use those trees.

For trees that are *only* used for basically throw-away single-use testing
(ie -mm and -next, both of which will always re-build the whole tree each
time), changing a published tree doesn't matter at all, or matters very
little.

But once you get real people, rather than automation, that actually want
to do development on top of a git tree, then rebuilding that tree is
really really annoying for those users.

So the networking tree, where you have other maintainers that are also git
users, really shouldn't be rebuilt, because that messes with developers.

Many other git trees are really more of a "private development trees that
are exposed to -mm and -next to get some wider testing".

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Sat, Apr 26, 2008 at 10:21:33AM -0700, Linus Torvalds wrote:
>
>
> On Sat, 26 Apr 2008, Adrian Bunk wrote:
> >
> > The patch for the x86 userspace header breakage last weekend was Cc'ed
> > to you.
>
> Yes, and I couldn't care less - it wasn't critical in any way (nobody
> should be using kernel headers directly in user space anyway, so the only
> people who could _possibly_ care were the people who build glibc releases
> etc).
>
> IOW, it wasn't a critical bug-fix that needed to be pushed out
> aggressively.
>
> Which means that I totally ignore a patch when I see that there are people
> who actually maintain that area (especially if I know they are responsible
> maintainers) that are also cc'd and that even reply to it.
>...

I'm not yet getting your definition of a critical bug-fix.

The patch of Harvey you already applied was a build fix in a well
maintained area (Mauro would have sent you my patch today).

Do you consider all patches that fix build errors as critical?
If yes, only for x86 or for all architectures?

> Linus

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

>
> Because if it becomes normal coding practice, now people cannot work with
> you sanely any more (ie some random person pulls your tree for testing,
> and then I pull it at some other time, and the tester reports a problem,
> but now the commits he is talking about don't actually even exist in my
> tree any more, and it's all really messy!).

It also depends on whare you are located in the dependency tree.
Being kbuidl maintainer I have very few people that actually
pull me git tree (except from -mm and -next).
So I rebase at will and have so far not got a single complaint
from anyone pulling my tree.

But people like Davem and Ingo sits much higher in the dependency chain
and thus they have a very different set of users and thus a different
set of problems to take into account.

Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Sat, 26 Apr 2008, Adrian Bunk wrote:
>
> Do you consider all patches that fix build errors as critical?
> If yes, only for x86 or for all architectures?

I think that things that hold up people testing a development kernel is
"important". Maybe not "critical", but certainly stuff I should fix asap,
just so that people who might otherwise test a kernel (but aren't
technical enough to fix even possibly trivial errors) won't get
discouraged.

And yes, x86(-64) is the one that matters a whole lot more for that kind
of 'random tester' issue. If other architectures don't build in some
random config, I don't consider that a huge deal, since anybody who builds
a development kernel for (say) powerpc will also generally have the
ability to fix whatever silly brown-paper-bug issue just as well as I
could.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/