[PATCH 1/2] Effective Maintainer Work Flow

[Werner Almesberger]

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