au0828: debug is a poor global identifier

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

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

index e65d564..9b7a4d7 100644
@@ -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");

index 0200b9f..8344c45 100644
@@ -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

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

Hi Adrian.

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

Hi Sam,

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.

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.

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

It's because I hate you.

Oh, no, wait.

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

Linus

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

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

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

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?

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

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

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

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

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.

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

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

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

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

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

Absolutely.

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

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

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

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/

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

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

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

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

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. 

[...]

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/

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

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

...

Indeed. It's the question of when do I release what to whom.

Stefan Richter
-=====-==--- -=-- ==-==
http://arcgraph.de/sr/

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

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/

From: Linus Torvalds <[email protected]>
Date: Sat, 26 Apr 2008 10:31:36 -0700 (PDT)

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

The Downstream Collective thanks you! ;-)

Jeff

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.

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

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)

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

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

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

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

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

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