On Fri, Feb 04, 2011 at 09:17:34AM -0800, Daniel Walker wrote: > On Wed, 2011-02-02 at 16:47 -0500, Nicolas Pitre wrote: > > The actual problem here is that some people, notably the msm folks, > > are > > bypassing the maintainer hierarchy and going straight to Linus for > > their > > pull requests instead of asking RMK to pull. We once debated this at > > I don't think it's fair to single out MSM here. Going straight to Linus > was discussed at one point, as I recall, and Russell didn't oppose it at > the time. There are a number of ARM sub-architecture maintainers that do > this.. None of that is related to the rejects created here, those would > happen no matter who we submitted pull requests to. > > I think the issue is more that MSM is actively being cleanup , and > Russell is touching code that we're working on also. So we need a way to > work together .. In this case the collision is so simple that either > Linus or Russell would just fix it up while pulling, and both would > likely be fine with that. In the past I've tried to fix up these issues, > but now I think maybe it's doesn't matter. > > In terms of Russell rebasing, I don't really like that. I've based MSM > trees on Russell's stable branch and it's worked in the past. If > Russell's rebasing then we can't really do that, so one tool to fix > these problems is gone. The alternative is that I don't publish patches in git form. Or do I publish patches in git form and never add any acks or tested-by information to them ever. It's really no skin off my nose if I never add any acks, tested-by or reviewed-by tags to my patches - it actually means _less_ work for me. I'd prefer to give credit where credit is due, but if idiotic rules mean that I can't, that's really not my problem. Goody, I can spend that time doing more productive work. So, here's a questionaire: 1. Would it be acceptable to keep the p2v changes hidden from public view via git for months, and only available in patch form as I'm waiting for acks from people? 2. Would you have found this if these changes weren't in linux-next? 3. Would you have found it by applying my patches from the mailing list to your tree? 4. Is it acceptable not to acknowledge people who've tested and reviewed? The answers are most probably: no, no, no and no. And now you see my dilema: 1 is incompatible with 4. I argue that you're better off _seeing_ the changes via git and linux-next because then linux-next can pick up these conflicts when they happen and we can sort out the resulting mess when that happens. I've no problem _eventually_ freezing the p2v branch, but the p2v stuff is currently in flux: althrough I've requested acks from Nicolas, none are forthcoming yet - and there's going to be some further work: | > Thanks, merged those in. Can I have new acks for the p2v branch please? | | Yes, hopefully soon. I should also restore Thumb2 | support in the process. So you tell me - do I take the p2v stuff out of public view tonight because it's not stable, and therefore you don't even know about the conflict? Or do I continue publishing the unstable changes so that people have the ability to see what's going on in my tree and find potential conflicts? I really don't care which - but I'll warn you that keeping changes hidden will result in a reduction of patch quality, and much much much less testing of those changes. And I won't care at all when you complain that MSM's broken because of one of my patches. Exactly what would you prefer? -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- 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
