Andy Green wrote: > I think we need to change the way we are working to conform with how > other projects handle merging.
I wouldn't mind having to spend less time editing patches :-) I'm doing this because we had major complaints in the past that people felt that unfavourable or "picky" reviews kept their work from the mainline tree, which then resulted in the fragmentation into "private" trees we've seen in the past months (and which are now hopefully disappearing). So all this is in the name of speedy integration. It's not my intention to "own" other people's code, and I try to clearly indicate (in my replies) where and why I've made changes that could break functionality. Another reason why some editing it needed is that we still have a large amount of patches that should have been merged upstream long ago, but this hasn't happened yet for a number of reasons. For upstream merging, since they are first submissions, they should be structured by function, e.g., patch #1 infrastructure-this, patch #2 feature-this, patch #3 feature-that, etc. However, for on-going maintenance, patches should contain the incremental change, possibly crossing functional blocks. Most of the patches I get are of the second type, while our mainline patch collection is of the first. Is fine for me to get patches of that second type, since this is how patches are normally done, and I don't want to introduce a different structure while we're in this anomalous state. Thus, I have to break each patch into pieces and apply each piece to the functional block it touches. (A typical example being gta02-core.patch and smedia-glamo.patch. I'm not very happy with the split there either, but restructuring this would be too much of an effort at the present time.) But I'm glad that you don't see meticulous reviews as an obstacle and don't mind if your patches might get bounced back a number of times. And having to do less editing also saves me from introducing typos ;-) So, how shall we proceed ? Do you want to be the only person who edits your patches ? Or to you want me to: - do any restructuring at the file/hunk level ? - do trivial edits (whitespace, typos, etc.) - do minor edits, e.g., to accommodate overlapping changes - fix obvious bugs (e.g., uninitialized variables) Also, please bear in mind that this is ultimately a globally shared tree, with many more maintainers in the food chain until the plain vanilla kernel, and that changes will happen to the code you wrote without your consent. I'm merely the first person to get their hands on it ;-) Regarding the changes I made to patch 1/2, i.e., "IRQ_GLAMO(0) + x" -> "IRQ_GLAMO(x)" and the voltage calculation, could you please indicate whether you agree with my analysis ? (See the questions in my previous mail.) I'd also appreciate feedback from other submitters of patches what extent of editing they expect from me, i.e., whether they prefer the current "drop and forget" model or rather have strict admission control. - Werner
