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

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

[Harvey Harrison]

Avoid link-time warnings with debug declared in x86/kernel/entry_32.S

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
Otherwise you'll see link time warnings about multiple defintions of
debug. (size 4 here, size 76 in entry_32.S)

 drivers/media/video/au0828/au0828-core.c |   14 +++++++-------
 drivers/media/video/au0828/au0828.h      |    4 ++--
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/media/video/au0828/au0828-core.c b/drivers/media/video/au0828/au0828-core.c
index e65d564..9b7a4d7 100644
--- a/drivers/media/video/au0828/au0828-core.c
+++ b/drivers/media/video/au0828/au0828-core.c
@@ -32,9 +32,9 @@
  * 4 = I2C related
  * 8 = Bridge related
  */
-unsigned int debug;
-module_param(debug, int, 0644);
-MODULE_PARM_DESC(debug, "enable debug messages");
+unsigned int au0828_debug;
+module_param(au0828_debug, int, 0644);
+MODULE_PARM_DESC(au0828_debug, "enable debug messages");
 
 unsigned int usb_debug;
 module_param(usb_debug, int, 0644);
@@ -229,23 +229,23 @@ static int __init au0828_init(void)
 {
 	int ret;
 
-	if (debug)
+	if (au0828_debug)
 		printk(KERN_INFO "%s() Debugging is enabled\n", __func__);
 
 	if (usb_debug) {
 		printk(KERN_INFO "%s() USB Debugging is enabled\n", __func__);
-		debug |= 2;
+		au0828_debug |= 2;
 	}
 
 	if (i2c_debug) {
 		printk(KERN_INFO "%s() I2C Debugging is enabled\n", __func__);
-		debug |= 4;
+		au0828_debug |= 4;
 	}
 
 	if (bridge_debug) {
 		printk(KERN_INFO "%s() Bridge Debugging is enabled\n",
 		       __func__);
-		debug |= 8;
+		au0828_debug |= 8;
 	}
 
 	printk(KERN_INFO "au0828 driver loaded\n");
diff --git a/drivers/media/video/au0828/au0828.h b/drivers/media/video/au0828/au0828.h
index 0200b9f..8344c45 100644
--- a/drivers/media/video/au0828/au0828.h
+++ b/drivers/media/video/au0828/au0828.h
@@ -96,7 +96,7 @@ struct au0828_buff {
 /* au0828-core.c */
 extern u32 au0828_read(struct au0828_dev *dev, u16 reg);
 extern u32 au0828_write(struct au0828_dev *dev, u16 reg, u32 val);
-extern unsigned int debug;
+extern unsigned int au0828_debug;
 extern unsigned int usb_debug;
 extern unsigned int bridge_debug;
 
@@ -123,6 +123,6 @@ extern int au0828_dvb_register(struct au0828_dev *dev);
 extern void au0828_dvb_unregister(struct au0828_dev *dev);
 
 #define dprintk(level, fmt, arg...)\
-	do { if (debug & level)\
+	do { if (au0828_debug & level)\
 		printk(KERN_DEBUG DRIVER_NAME "/0: " fmt, ## arg);\
 	} while (0)
-- 
1.5.5.1.270.g89765

If you want me to quit I will quit

[Adrian Bunk]

> [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 fucked 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

Re: If you want me to quit I will quit

[Sam Ravnborg]

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

Re: If you want me to quit I will quit

[Adrian Bunk]

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

Re: If you want me to quit I will quit

[Andrew Morton]

On Sat, 26 Apr 2008 14:00:44 +0300 Adrian Bunk <bunk@kernel.org> 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.

Re: If you want me to quit I will quit

[Adrian Bunk]

On Sat, Apr 26, 2008 at 07:51:32AM -0700, Andrew Morton wrote:
> On Sat, 26 Apr 2008 14:00:44 +0300 Adrian Bunk <bunk@kernel.org> 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 
fuckup 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

Re: If you want me to quit I will quit

[Andrew Morton]

On Sat, 26 Apr 2008 18:23:41 +0300 Adrian Bunk <bunk@kernel.org> 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 <bunk@kernel.org> 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.

Re: If you want me to quit I will quit

[Bartlomiej Zolnierkiewicz]

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 fucked 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

Re: If you want me to quit I will quit

[Linus Torvalds]

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

Re: If you want me to quit I will quit

[Adrian Bunk]

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

Re: If you want me to quit I will quit

[Adrian Bunk]

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 fucked 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

Re: If you want me to quit I will quit

[Adrian Bunk]

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

Re: If you want me to quit I will quit

[Andrew Morton]

On Sat, 26 Apr 2008 20:16:04 +0300 Adrian Bunk <bunk@kernel.org> 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.

Re: If you want me to quit I will quit

[Linus Torvalds]

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

Re: If you want me to quit I will quit

[Adrian Bunk]

On Sat, Apr 26, 2008 at 10:20:24AM -0700, Andrew Morton wrote:
> On Sat, 26 Apr 2008 20:16:04 +0300 Adrian Bunk <bunk@kernel.org> 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

Re: If you want me to quit I will quit

[Linus Torvalds]

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

Re: If you want me to quit I will quit

[Adrian Bunk]

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

Re: If you want me to quit I will quit

[Linus Torvalds]

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

Re: If you want me to quit I will quit

[Sam Ravnborg]

> 
> 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

Re: If you want me to quit I will quit

[Linus Torvalds]

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

Re: If you want me to quit I will quit

[Linus Torvalds]

On Sat, 26 Apr 2008, Sam Ravnborg wrote:
> 
> It also depends on whare you are located in the dependency tree.

Absolutely.

> 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.

I agree. Some trees are so specific (and/or simply don't have enough 
patches in them) that it simply doesn't matter if two different people 
pull the same tree. Even if it might end up causing some duplication of 
commits (because the pulled tree might end up being then pulled further), 
it's not a big deal if it's rare.

In fact, we have always had duplicated commits even when they are passed 
around as email - just because perhaps two different trees simply needed 
the same fix, and rather than wait for it, they both integrated it (and 
then when they get merged, the same patch exists twice in the history, 
just with different committer info etc).

So yeah, rebasing ends up being really convenient if you really don't 
expect to have any other "real" end users than eventually being pulled 
into my tree (or, even more commonly, and when rebasing is *really* 
convenient: when it's just you keeping track of your own private patches 
in your own private tree and don't know if they will *ever* go upstream at 
all).

> 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.

Yes. David has changed his workflow to accomodate others, while Ingo still 
does the rebasing (and it works out because nobody else works on his trees 
using git).

			Linus

Re: If you want me to quit I will quit

[Stefan Richter]

Linus Torvalds wrote:
> 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.

Well, the need to amend single patches --- and folding the amendment in 
before mainline submission to correct important problems of the first 
shot --- is something which happens all the time.

(People will have different opinions about what is important enough to 
redo a patch instead of keeping the amendment separate.)

> 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!).

In my experience, the submission branch cannot practically be the same 
as the development branch (I mean, a true ancestor of the of the 
development branch).  That's simply because the order of submission is 
different.

The only way to keep commits from the development branch identical in 
the submission branch would be to work with a huge number of topic 
branches, with the number of branches approaching the number of commits. 
But then testers and developers would still work with merge commits 
which will not appear in the mainline submission.  And there would be 
weird histories because of the need to merge from other trees, notably 
from torvalds/linux-2.6.git when necessary to avoid conflicts.

(I for one rebuild the development branch of linux1394-2.6.git from 
scratch after 2.6.x-rc1 came out, then keep its history until 2.6.x. 
During that time I occasionally 'pollute' it with reverts and with 
merges from torvalds/linux-2.6.git.  These will not be carried over into 
the submission branch.)
-- 
Stefan Richter
-=====-==--- -=-- ==-=-
http://arcgraph.de/sr/

Re: If you want me to quit I will quit

[Linus Torvalds]

On Sat, 26 Apr 2008, Stefan Richter wrote:
> 
> Well, the need to amend single patches --- and folding the amendment in before
> mainline submission to correct important problems of the first shot --- is
> something which happens all the time.

.. and you simply SHOULD NOT PUBLICIZE the tree before it has gotten to a 
reasonable point.

Keep the rough-and-not-ready thing that is being discussed as patches on 
lkml as your own working tree, and just don't expose it as a public git 
branch. You can't do any sane discussion over git anyway - if things are 
being actively worked-on among people, you'd be passing patches around as 
emails etc.

Yes, people may be (and I would strongly suggest _should_ be) using 
something like git or quilt etc to keep track of the patches that they 
(and others) have been discussing over email, but that has absolutely 
nothing to do with making a public git tree available to others.

So:
 - making things public is *different* from developing them. Don't push 
   out just because you committed something!

 - you shouldn't publicize a tree until it's in reasonable shape. EVER. 
   Even -mm or -next is *not* better off with a pile of sh*t just because 
   you're working in that area. 

   I cannot stress this enough. I think Andrew has been way too polite to 
   some people.

 - and once it is, you generally shouldn't mess with old commits even when 
   you fix things. Full cleanliness or always being able to bisect 
   specific configurations is not an excuse for messing up all the other 
   things, and if this problem happens a lot, I would like to point you to 
   the two previous points.

Really.

		Linus

Re: If you want me to quit I will quit

[Linus Torvalds]

On Sat, 26 Apr 2008, Linus Torvalds wrote:
> 
> So:
>  - making things public is *different* from developing them. Don't push 
>    out just because you committed something!
> 
>  - you shouldn't publicize a tree until it's in reasonable shape. EVER. 
>    Even -mm or -next is *not* better off with a pile of sh*t just because 
>    you're working in that area. 
> 
>    I cannot stress this enough. I think Andrew has been way too polite to 
>    some people.
> 
>  - and once it is, you generally shouldn't mess with old commits even when 
>    you fix things. Full cleanliness or always being able to bisect 
>    specific configurations is not an excuse for messing up all the other 
>    things, and if this problem happens a lot, I would like to point you to 
>    the two previous points.

And btw, a *big* part of the above is also:

 - mistakes happen.

There will be bugs. There will be cases where things aren't bisectable 
(although they should generally be bisectable for *your* configuration, 
because if they aren't, that shows that you didn't even compile the 
commits you made).

And there will be kernels that don't boot. Even expecting people to always 
boot-test every single commit would be unrealistic - let's face it, most 
things look really obvious, and the fact that even obvious fixes can have 
bugs doesn't mean that there should be hard rules about "every single 
commit has to be boot-tested on X machines".

So it's an important part of the process to try to do a good job, and not 
publicizing crap - but it's *equally* important to realize that crap 
happens, and that it's easily *more* distracting to try to clean it up 
after-the-fact than it is to just admit that it happened.

		Linus

Re: If you want me to quit I will quit

[Harvey Harrison]

On Sat, 2008-04-26 at 14:00 +0300, Adrian Bunk 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]
> 

I do generally try to check the mailing list to avoid this...but LKML
tends to be pretty busy.  I also try to check the latest -git devel
tree for the affected area in case it's waiting to be pulled.  In this
case it was so trivial I sent it directly to Linus.

In fact, I concentrate on looking at the sparse output because you
do such a good job of catching unnecessary exports/globals.

> And if you e.g. discover next that our x86 userspace headers in
> 2.6.25 (sic) are fucked 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 look how many of mine have been sitting in -mm for weeks because I
thought they should go through a maintainer/-mm.  This was just annoying
as it was making my sparse builds quit, and I thought others might be in
the same boat.

Cheers,

Harvey

Re: If you want me to quit I will quit

[Adrian Bunk]

On Sat, Apr 26, 2008 at 12:20:55PM -0700, Harvey Harrison wrote:
> On Sat, 2008-04-26 at 14:00 +0300, Adrian Bunk 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]
> 
> I do generally try to check the mailing list to avoid this...but LKML
> tends to be pretty busy.  I also try to check the latest -git devel
> tree for the affected area in case it's waiting to be pulled.  In this
> case it was so trivial I sent it directly to Linus.
> 
> In fact, I concentrate on looking at the sparse output because you
> do such a good job of catching unnecessary exports/globals.
>...

Sorry that my mail was unfriendly, but unfriendly flames are 
unfortunately sometimes the only choice for getting any response
on linux-kernel (and now I've gotten the responses my friendly
mail to Linus did not yield).

> Cheers,
> 
> Harvey

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

Re: If you want me to quit I will quit

[Stefan Richter]

Linus Torvalds wrote:
> On Sat, 26 Apr 2008, Stefan Richter wrote:
>> Well, the need to amend single patches --- and folding the amendment in before
>> mainline submission to correct important problems of the first shot --- is
>> something which happens all the time.
> 
> .. and you simply SHOULD NOT PUBLICIZE the tree before it has gotten to a 
> reasonable point.

I always aim for keeping the one subsystem git tree which I maintain in 
reasonable shape.  Including its -mm and -next feeding branches.

> Keep the rough-and-not-ready thing that is being discussed as patches on 
> lkml as your own working tree, and just don't expose it as a public git 
> branch. You can't do any sane discussion over git anyway - if things are 
> being actively worked-on among people, you'd be passing patches around as 
> emails etc.

Sometimes I want problem reporters to test more than a single patch.  In 
these cases, I refer them to patch kits and quilt queues which I 
maintain independently of linux1394-2.6.git; I almost never ask testers 
to try linux1394-2.6.git.

linux1394-2.6.git has been, and still is, first and foremost my 
submission branch to -mm.  And I have high expectations of what I submit 
to -mm.  But sometimes something turns out to be a bad idea after all 
_long after_ I and the reviewers and testers thought it would be fine.

Besides, the care that I take with my submissions to -mm also does not 
change the fact that I submit in different order to you than to -mm.
(As mentioned, reordering could be done to some degree with a respective 
number of branches.  I don't do it this way currently.)
-- 
Stefan Richter
-=====-==--- -=-- ==-=-
http://arcgraph.de/sr/

Re: If you want me to quit I will quit

[Andrew Morton]

On Sat, 26 Apr 2008 12:18:34 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:

> So it's an important part of the process to try to do a good job, and not 
> publicizing crap - but it's *equally* important to realize that crap 
> happens, and that it's easily *more* distracting to try to clean it up 
> after-the-fact than it is to just admit that it happened.
> 

Often it takes quite a long time for problems to become apparent.  Across a
month or two we end up with things like:

mm-have-zonelist-contains-structs-with-both-a-zone-pointer-and-zone_idx.patch
mm-have-zonelist-contains-structs-with-both-a-zone-pointer-and-zone_idx-fix-memcg-ooms.patch
mm-have-zonelist-contains-structs-with-both-a-zone-pointer-and-zone_idx-just-return-do_try_to_free_pages.patch
mm-have-zonelist-contains-structs-with-both-a-zone-pointer-and-zone_idx-just-return-do_try_to_free_pages-do_try_to_free_pages-gfp_mask-redundant.patch

and

mm-filter-based-on-a-nodemask-as-well-as-a-gfp_mask.patch
mm-filter-based-on-a-nodemask-as-well-as-a-gfp_mask-doc-fixes.patch
mm-filter-based-on-a-nodemask-as-well-as-a-gfp_mask-make-dequeue_huge_page_vma-obey-mpol_bind-nodemask.patch
mm-filter-based-on-a-nodemask-as-well-as-a-gfp_mask-make-dequeue_huge_page_vma-obey-mpol_bind-nodemask-rework.patch

that's two patches, each with three followon fixes.  Very common.

Fact is, this is the way in which developers want to work.  That is their
workflow, and their tools should follow their workflow.  If a tool's
behaviour prevents them from implementing their desired workflow, it isn't
the workflow which should be changed ;)

Re: If you want me to quit I will quit

[Linus Torvalds]

On Sat, 26 Apr 2008, Andrew Morton wrote:

> On Sat, 26 Apr 2008 12:18:34 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> > So it's an important part of the process to try to do a good job, and not 
> > publicizing crap - but it's *equally* important to realize that crap 
> > happens, and that it's easily *more* distracting to try to clean it up 
> > after-the-fact than it is to just admit that it happened.
> 
> Fact is, this is the way in which developers want to work.  That is their
> workflow, and their tools should follow their workflow.  If a tool's
> behaviour prevents them from implementing their desired workflow, it isn't
> the workflow which should be changed ;)

But that was exactly my point. Bugs *will* happen. Follow-up patches 
*will* happen. Don't fight it. Do the best you can do - there's no way 
people will ever avoid all bugs to begin with. 

And trying to white-wash things later is just pointless and actively 
*bad*, when others have already seen and merged the original patches.

			Linus

Re: If you want me to quit I will quit

[Stefan Richter]

Andrew Morton wrote:
> Often it takes quite a long time for problems to become apparent.  Across a
> month or two we end up with things like:
[...]
> that's two patches, each with three followon fixes.  Very common.
> 
> Fact is, this is the way in which developers want to work.  That is their
> workflow, and their tools should follow their workflow.  If a tool's
> behaviour prevents them from implementing their desired workflow, it isn't
> the workflow which should be changed ;)

Well, some of the questions here, notably
   - when to fold patch + amendment patch into a single patch
   - when to publish things to whom
are actually about the workflow, not about the tool.

(And it's good to learn of other people's expectations about it.)
-- 
Stefan Richter
-=====-==--- -=-- ==-=-
http://arcgraph.de/sr/

Re: If you want me to quit I will quit

[David Miller]

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sat, 26 Apr 2008 10:31:36 -0700 (PDT)

> 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.

I didn't rebase at all this past cycle for networking, and it
helped the people downstream from me _A LOT_.

Anyone who rebases frequently, like I used to, is an idiot, like
me. :-)

Re: If you want me to quit I will quit

[Jeff Garzik]

On Sat, Apr 26, 2008 at 05:31:29PM -0700, David Miller wrote:
> From: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Sat, 26 Apr 2008 10:31:36 -0700 (PDT)
> 
> > 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.
> 
> I didn't rebase at all this past cycle for networking, and it
> helped the people downstream from me _A LOT_.

The Downstream Collective thanks you!  ;-)

	Jeff

Re: If you want me to quit I will quit

[Richard Purdie]

On Sat, 2008-04-26 at 13:30 -0700, Andrew Morton wrote:
> On Sat, 26 Apr 2008 12:18:34 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > So it's an important part of the process to try to do a good job, and not 
> > publicizing crap - but it's *equally* important to realize that crap 
> > happens, and that it's easily *more* distracting to try to clean it up 
> > after-the-fact than it is to just admit that it happened.
> > 
> 
> Often it takes quite a long time for problems to become apparent.  Across a
> month or two we end up with things like:
> 
> mm-have-zonelist-contains-structs-with-both-a-zone-pointer-and-zone_idx.patch
> mm-have-zonelist-contains-structs-with-both-a-zone-pointer-and-zone_idx-fix-memcg-ooms.patch
> mm-have-zonelist-contains-structs-with-both-a-zone-pointer-and-zone_idx-just-return-do_try_to_free_pages.patch
> mm-have-zonelist-contains-structs-with-both-a-zone-pointer-and-zone_idx-just-return-do_try_to_free_pages-do_try_to_free_pages-gfp_mask-redundant.patch
> 
> and
> 
> mm-filter-based-on-a-nodemask-as-well-as-a-gfp_mask.patch
> mm-filter-based-on-a-nodemask-as-well-as-a-gfp_mask-doc-fixes.patch
> mm-filter-based-on-a-nodemask-as-well-as-a-gfp_mask-make-dequeue_huge_page_vma-obey-mpol_bind-nodemask.patch
> mm-filter-based-on-a-nodemask-as-well-as-a-gfp_mask-make-dequeue_huge_page_vma-obey-mpol_bind-nodemask-rework.patch
> 
> that's two patches, each with three followon fixes.  Very common.
> 
> Fact is, this is the way in which developers want to work.  That is their
> workflow, and their tools should follow their workflow.  If a tool's
> behaviour prevents them from implementing their desired workflow, it isn't
> the workflow which should be changed ;)

Its worth realising that these fix patches contain useful information
too, e.g. they might be by different authors and its also interesting in
some senses to see what fixes were applied to the original patch, why
etc. since it is history and that is what the SCM effectively stores.

This is also happens on larger timescales, a commit goes into some tree,
some regression is found, some future commit fixes that regression,
sometimes over a kernel release or two or more.

My point is that this information can actually be useful and trying to
prune it all out the main tree for aesthetic reasons might not
necessarily be the right thing to do. I agree it can be distracting and
perhaps what we need are tools that can show or hide this kind of
information as an option.

Consider that -stable tree and that if commits were somehow marked as
regression fixes for previous commits, you could run some command and
get a list of regression fixes. I'm a realist and appreciate such output
would need careful manual/human consideration but it would have a real
world use.

On the other hand I agree that the patches in -mm often have stupid
typos etc which aren't interesting in the history but where do you draw
the line?

Cheers,

Richard

Re: If you want me to quit I will quit

[Stefan Richter]

Richard Purdie wrote:
> Its worth realising that these fix patches contain useful information
> too, e.g. they might be by different authors and its also interesting in
> some senses to see what fixes were applied to the original patch, why
> etc. since it is history and that is what the SCM effectively stores.

Important things can be noted in the patch description.  We can also 
refer to mailinglist archives and bug trackers in the patch description.

Caveats:  Changing the patch description means changing the patch 
identity (which different SCMs treat with different rigor).  Also, a 
number of SCM tools assume that there is exactly one author of a patch. 
(Workaround:  Track coauthors informally in the patch description.)

...
> On the other hand I agree that the patches in -mm often have stupid
> typos etc which aren't interesting in the history but where do you draw
> the line?

Indeed.  It's the question of when do I release what to whom.
-- 
Stefan Richter
-=====-==--- -=-- ==-==
http://arcgraph.de/sr/

Re: If you want me to quit I will quit

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 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!).

this is a real problem in practice, so i have a 'merge' repository of 
all published x86.git trees of the past. About a 150 tree rebases later 
it's still only 500 MB - so we know about the precise identity of every 
published commit ID, even long after the fact.

> 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.

if people basing stuff on x86.git becomes common and the rebasing 
becomes an annoyance to them then we'll change this - we already changed 
many other practices we had, according to feedback from developers.

Firstly, an architecture tree is kind of special, in that it's very, 
very easy to introduce a regression that makes systems not boot up at 
all. And that's a showstopper for developers. It's quite different from 
a core kernel tree where we can often limp along with regressions. So by 
far the most important thing that people value about our tree is 
stability (or at least so we think).

So we do have a couple of fundamental things about our workflow that we 
think developers value, and i'm not sure how to do that within Git.

For example the act of 'staging' various fixes, and in essence 
bubble-sorting topics by the amount of fixes/problems they get. The 
lifetime of topics within x86.git is like this, and this roots back to 
the -rt queue which for years we maintained in a similar fashion:

- a new, nontrivial topic comes - say kmemcheck. First it's completely 
  experimental and we dont publish it at all - we keep it observed for a 
  week or so to get a feel of how much we want that topic and how stable 
  it is.

- the topic is in it's first stage, the most experimental 'testing' 
  phase. It's in x86.git/testing branch, right at the tail of every 
  other patch. It is merged after every existing topic and disturbs
  nothing. If it breaks then it's easy to take it out - no harm done to
  any other topic. New topics often bounce out and back 2-3 times before 
  they get past this initial stage of integration.

- the topic is in it's second stage - no high flux development anymore,
  it can get into x86/for-akpm. That means it will go ahead of a lot of 
  other topics and that might mean merging work. It goes through another 
  level of review - Andrew is picky ;-)

- the topic is in its third stage - x86.git/for-linus - preparation for 
  push. It's merged ahead of all other topics, merge conflicts resolved.
  Another, final review as well. We make sure Acks are collected for out
  of tree stuff, etc.

if there's some problem with a topic at any stage, it usually bubbles 
back up a level or two. Sometimes the problem is unknown and unfixed so 
the topic gets removed completely from the tree (temporarily), until the 
problem if found. Since we provide good bisection data, developers can 
find problems fast. Sometimes there's fatal review feedback (say Andrew 
reviews it too and finds it lacking ;) that moves a topic back to the 
'experimental' section completely.

But it gets even more complex: often we append fixes/updates not to the 
topic, but to the tail of the queue. We wait a test cycle (24 hours or 
overnight test) and when the changes look OK for public release we push 
it out. Then when it's OK and enough updates batched up and we trust the 
result we move those changes back to their specific topics - and resolve 
any conflicts if needed. This basically mixes 'clean topic separation 
and ordering' with a short-term 'append only' practice.

but all this inner-queue lifetime is almost invisible to developers - 
all the reshuffling is done in an invariant way and we enforce that the 
end result does not change when we flip around topics. They might see 
topics disappearing occasionally, but given that x86.git carries up to a 
dozen topics at a time or more, it's never a true disruption.

But we dont keep the queue public with a known breakage in it. I.e. we 
merge easily, but we also find bugs agressively and revert easily. And 
an important rule is that the moment we know about a breakage we fix it 
immediately either by resolving the bug or by removing the topic, and 
release a new version right then.

Another benefit to developers is that we do all inter-topic merges 
ourselves. If we picked up two overlapping topics it's our task to 
resolve the inevitable conflicts - we dont push that back to the 
developers.

And the topic sorting of the queue becomes important in the merge window 
as well: that's when the final decision is done whether to merge a topic 
or not. This means that topics will again change order - and if there's 
some dependency between them (which is very common), that dependency is 
resolved.

Quilt gives this sort of workflow flexibility to us - but i never really 
found a good Git workflow that matches this type of maintenance model. 
But we are no Git wizards so suggestions would be welcome.

	Ingo

Re: If you want me to quit I will quit

[Romano Giannetti]

On Sat, 2008-04-26 at 13:35 -0700, Linus Torvalds wrote:

> > Fact is, this is the way in which developers want to work.  That is their
> > workflow, and their tools should follow their workflow.  If a tool's
> > behaviour prevents them from implementing their desired workflow, it isn't
> > the workflow which should be changed ;)
> 
> But that was exactly my point. Bugs *will* happen. Follow-up patches 
> *will* happen. Don't fight it. Do the best you can do - there's no way 
> people will ever avoid all bugs to begin with. 

Sorry if I drop in into a thread that's probably too big for me, but I
was having an idea (probably horribly wrong, but I try... don't beat too
hard). I think the main problem is when a fix to a change occurs quite
after the change went in, creating bisection problems (I've had
something like that bisecting an MMC problems some time ago). 

Wouldn't be nice to have the concept of patch series in git? Maybe the
sha1 of the first commit of the patch? Then a fix on the series can be
marked  as such, and you could teach git bisect to go first series by
series, applying/removing the fix patches as needed... and just at the
end dive into the commits. Maybe it's impossible/too complex/exponntial,
but well, it just a git git idea :-)

Romano

-- 
Sorry for the disclaimer --- ¡I cannot stop it!



--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.

This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation.