* James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > On Tue, 2009-06-09 at 22:21 +0200, Ingo Molnar wrote: > > * James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > Could you add this (as a postmerge tree) somewhere after the x86 > > > trees, please (it depends on the auto-x86-next branch). > > > > > > I'll be sending the pull request for it to Linus somewhere in the > > > next merge window (probably towards the end) and if he takes it, > > > linux-next inclusion for a small number of patches it contains > > > will probably be a recurring feature. > > > > Sigh. > > > > This code has been NAK-ed by the x86 maintainers: > > > > - Due to the absurd irrelevance of Voyager/x86/Linux hardware > > > > - Due to the thousands of lines of of code it adds to arch/x86 > > to support a 486/P5 era piece of hardware > > > > - and due to its negative track record of: > > > > v2.6.27.0: Voyager was broken - it did not even build. (!) > > v2.6.28.0: Voyager was broken - it did not even build. (!) > > v2.6.29-rc5: Voyager was broken - it did not even build. (!) > > > > [ ... which was the point when we yanked it from the x86 devel > > tree. Then you suddenly found interest in it again. But it was > > too little, too late. Voyager is irrelevant and we've really > > got better things to do than to worry about ancient, completely > > irrelevant hardware. ] > > > > And you were very much aware of its controversial nature and you > > were aware of the NAK, still you sent this mail to Stephen without > > Cc:-ing the x86 maintainers or without Cc:-ing lkml. > > > > You did this on one of the last days of the development window - > > generally the most impossibly busy days for upstream maintainers who > > prepare for the next merge window. > > > > I've Cc:-ed Linus - he might want to overrule our judgement and pull > > this from you directly or tell us to pull it - but this should be > > done above board, not below the radar on the last day of the > > development window. > > > > I made it quite clear to you why i object to this code, didnt I? See > > the (long) thread at: > > > > http://lkml.org/lkml/2009/4/15/299 > > > > James, it also would have been really honest from you to Cc: us to > > this mail. I am not pushing SCSI changes into linux-next either, > > against your NAKs, behind your back. I'd have expected the same of > > you. > > > > So i strongly object against this tree being included in linux-next. > > Your actual statement was that I should take this to Linus, which > I will. [...] My statement was: " [...] Meanwhile if James does not want to maintain it out of tree he can ask Linus to overrule our NAK, but i'd like to ask him to quote this NAK paragraph from me in his mail to Linus. " http://lkml.org/lkml/2009/4/19/181 > However, procedurally, I need it through linux-next first before I > can send a pull request, otherwise I'm asking for code which > hasn't been through the usual integration testing to be included, > which is dangerous. How about the old fashioned way of interpreting my words directly, not twisting them like a laywer? Wasnt it clear from my objections that i ... object? Firstly, it is a misunderstanding (at best) on your part that patches that are sent to Linus must "procedurally" go through linux-next. The stuff from maintainers, the stuff that is not controversial, that bit should go into linux-next. The 90% stuff. The 10% stuff that is disputed and controversial (like kmemcheck which was excluded from linux-next for a few weeks in this cycle due to an objection, or like perfcounters which was disputed and is thus not included) it doesnt and shouldnt go into linux-next. It can be sent to Linus on its own right (declaring its controversial nature), or if you can convince Andrew to put it into linux-mm. Does this make it harder to merge controversial bits? Absolutely. That's one of the points really. Does this make it impossible to merge controversial bits, if the maintainer is on crack? Not at all - it just raises the bar. linux-next is not there to include all random stuff intended by all kernel developers on the planet to be sent to Linus, IMHO. It is there to _help Linus_ to merge the 90% bulk more easily, to handle conflicts between the routine stuff that nobody objects to and to test them together. It is there to free up time to handle the _10%_. And i think linux-next is currently largely fulfilling that purpose and role of detecting and excluding/resolving conflicts early on - both technical conflicts and conceptual/maintenance conflicts. If there are long arguments about linux-next that is _bad_. It should be a routine medium of friendly conflict resolution and "oh, I didnt really mean to push that patch, sorry" type of cross-maintainer realizations and cooperation - heavy arguments are for other forums such as lkml. Read the _name_ of linux-next. It's the stuff that is intended to be in Linux by maintainers in the next merge window, on a best effort basis. Surprises, trickeries and friction are bad. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
