Messages in this thread | | | From | Ray Lee <> | Date | Fri, 8 May 2009 16:44:22 -0700 | Subject | Re: [TuxOnIce-devel] [RFC] TuxOnIce |
| |
On Fri, May 8, 2009 at 4:30 PM, Nigel Cunningham <nigel@tuxonice.net> 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 off by that subsystem's maintainers. Witness any of the long series of patches that touch all arches, or change out all drivers from one method to another. Even Andrew Morton, the guy who's the declared 2.6 kernel maintainer, has to split his patches up by subsystem or lieutenant and push them forward via them and their trees.
You are being treated no differently than anyone else on here, other than 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 the affected subsystem people.
TuxOnIce is in a harder position than most patches, as for it to work it needs to touch so many subsystems.
Is this annoying? I'm sure. But that's why Rafael is offering to do the annoying part for you, the part that has never worked in the past when your patches have been posted for comment and hopeful merging: He's offering to be the social glue between your code and the forms that are accepted and followed here on LKML. Taking things apart from the whole, finding the pieces that are non-controversial or easily argued for, getting them merged upstream with a user, and then moving on to the rest.
This way, the external TuxOnIce patch set shrinks and shrinks, until it's eventually gone, with all functionality merged into the kernel in one form or another.
Is your code better than uswsusp? Almost certainly. This isn't about that. This is about making your code better than what it is today, by going through the existing review-and-merge process.
IBM had to do it with their Device Mapper feature set they tried to drop into the kernel, and the community said "Whoa" the same way they're reacting to TuxOnInce (Note: Not you, the code.) IBM went off, wrote things that intergrated in with the existing codebase, and got it merged with the signoffs of the subsystems affected. They're a big corp, 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 what you have today. I also personally have no control over what gets merged, so hopefully you'll read the above with some care and thought.
Please stick at this. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |