Quoting Nathan Lynch (ntl@xxxxxxxxx): > > If it can gain traction > > better than linux-cr, that'd be one thing. But given the amount of > > review and testing the other tree has gotten > > How much traction do you think linux-cr has? It doesn't seem any closer > to mainline than it was a year ago, and it barely has any users. I > don't think posting this little proof-of-concept patch set is disrupting > linux-cr's progress toward mainline. No, I agree with you there. I appreciate your attempt, and it would have been great if it had worked. My comments are only about going forward from today onward. And, going forward, I don't believe that this API simplification (and regression in functionality) is going to pay off the way you'd hoped. > > I'd really prefer that everyone was using the same tree, and sending > > any and all patches which they need, no matter how ugly they fear > > they are, upstream. To that end, I think it would be appropriate > > for you or Dan to get write access to Oren's tree or to move to a > > newly cloned copy of his tree to which one of you has acces. > > Oren and I disagree on some fundamental aspects of how kernel c/r should > be implemented (hence this patch set), so I'm not sure how this would > work. Ok, not you then :) I'm willing to do it, but since I won't be able to spend full time reviewing it, I'd have to set some ground-rules, like: I"ll pull in any patch as soon as it has an ack from (Oren, Dan Smith, Matt Helsley) which is not also from the submitter. Any regression in automated tests cause the patch which caused it to get kicked out. If you want to discuss the technical advantages of not allowing a task to call checkpoint on another task, let's start a new thread to do that. So far, I'm against it. thanks, -serge
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
