Messages in this thread | | | From | "Rafael J. Wysocki" <> | Subject | Re: [Suspend2][ 0/9] Extents support. | Date | Thu, 29 Jun 2006 23:11:51 +0200 |
| |
Hi,
On Thursday 29 June 2006 07:44, Nigel Cunningham wrote: > On Thursday 29 June 2006 15:19, Pekka Enberg wrote: > > On 6/29/06, Nigel Cunningham <nigel@suspend2.net> wrote: > > > Sure, I know where I'd be headed, but it would be a huge waste of time > > > and effort. > > > > Perhaps to you Nigel. For the rest of us reviewing your patches, it's > > much better. I suspect it would be better for the users down the road > > as well. I don't know if you realize it, but what you're doing now > > is, "here's a big chunck of code, take it or leave it". And at least > > historically people have had hard time doing getting stuff merged like > > that. > > I did try really hard not to do that (big chunk of code, take it or leave it). > That's why it's split up into so many little patches. The problem seems to be > that it's not split up in the way some people wanted, rather than not split > up at all. I want to make it easier on you guys, but it just seems to me like > regardless of what I do, it's not the right thing.
I think the problem is that you want it merged all at once, and it's too much code for doing so. The splitting is a separate thing - previously the patches were too big, now they are too small, but from the reviewer's point of view it's about the same: you can't get a grip on what's going on and why.
> I can understand wanting small changes to swsusp to transform it into > suspend2, but I also understand that I've spent approximately 5 years of > developing from the point Pavel forked the code base until today, and part of > that has been two complete reworkings of the way in which the data is stored > and the thing operates - irreducible complexity that just doesn't fit into > the incremental change model. So I'm trying to do what seems to me to be the > next best thing. Having arranged functions that deal with particular parts of > the system into individual files, I've broken the files up into logical parts > and submitted them in groups. If we consider the more primitive parts first, > then move to the increasingly abstract operations (or vice versa), I think > we'll have a good approach with what's already done.
No. The additional work on your part _is_ _needed_ so that _other_ _people_ may feel comfortable with your code in the kernel. Now, apparently, they are not, for various reasons, and you're just refusing to help them.
Greetings, Rafael - 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/
| |