On Fri, May 8, 2009 at 4:30 PM, Nigel Cunningham <nigel@xxxxxxxxxxxx> wrote:> > First, because it is technically too difficult to have all of the code reviewed> > and _agreed_ _upon_ by everyone at once. And if it's not agreed upon, you'll> > have to modify it and it won't be the same thing any more once you've done> > that. Which I'd say is guaranteed, having had a quick look at the code.>> I think you're putting unrealistic barriers in the way. Does all code> that goes into the kernel get "reviewed and agreed upon by everyone at> once"? No! Actually, yes. Any code that touches a subsystem has to get signed offby that subsystem's maintainers. Witness any of the long series ofpatches that touch all arches, or change out all drivers from onemethod to another. Even Andrew Morton, the guy who's the declared 2.6kernel maintainer, has to split his patches up by subsystem orlieutenant and push them forward via them and their trees. You are being treated no differently than anyone else on here, otherthan Linus himself who has the power to merge into his tree at a whim,but even he does so very reluctantly without a signoff from theaffected subsystem people. TuxOnIce is in a harder position than most patches, as for it to workit needs to touch so many subsystems. Is this annoying? I'm sure. But that's why Rafael is offering to dothe annoying part for you, the part that has never worked in the pastwhen your patches have been posted for comment and hopeful merging:He's offering to be the social glue between your code and the formsthat are accepted and followed here on LKML. Taking things apart fromthe whole, finding the pieces that are non-controversial or easilyargued for, getting them merged upstream with a user, and then movingon to the rest. This way, the external TuxOnIce patch set shrinks and shrinks, untilit's eventually gone, with all functionality merged into the kernel inone form or another. Is your code better than uswsusp? Almost certainly. This isn't aboutthat. This is about making your code better than what it is today, bygoing through the existing review-and-merge process. IBM had to do it with their Device Mapper feature set they tried todrop into the kernel, and the community said "Whoa" the same waythey're reacting to TuxOnInce (Note: Not you, the code.) IBM went off,wrote things that intergrated in with the existing codebase, and gotit merged with the signoffs of the subsystems affected. They're a bigcorp, and even they had to play by the existing rules. Everybody does this here, it's the way things work, because the process *works*. I personally want to see a better hibernation system in the kernel,and I personally think it's going to be substantially similar to whatyou have today. I also personally have no control over what getsmerged, so hopefully you'll read the above with some care and thought. Please stick at this._______________________________________________linux-pm mailing listlinux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx://lists.linux-foundation.org/mailman/listinfo/linux-pm
