Re: [PATCH] powerpc/ibmveth: fix multiple errors withdma_mapping_error conversion

[Andrew Morton]

On Mon, 28 Jul 2008 11:07:40 +1000 (EST) James Morris <jmorris@xxxxxxxxx> wrote:

> On Mon, 28 Jul 2008, Stephen Rothwell wrote:
> 
> > I hope that we all can discuss procedures for API changes at the Kernel
> > Summit ...
> 
> "all" as in, whoever was invited (the only transparent aspect of was a 
> silly count of # of commits for the initial shortlist), or was on the 
> committee, or bought seats via sponsorship.
> 

Yeah.

We do all our work via email.  If there's some particular issue that we
feel cannot be resolved effectively via email then I'd really like to
know what that issue is, and why.

> - James (co- maintainer/author of several kernel subsystems over 8+ years 
> and apparently not invited, because ?)

- Andrew, who asked everyone two years ago whether we can justify
annual kernel summits, and who still awaits a convincing answer.


But for this particular problem I don't think there's much to be
discussed.  It should have been implemented as
s/dma_mapping_error/dma_mapping_error2/g with eventual removal of
dma_mapping_error().  But I failed to appreciate how many
dma_mapping_error()s there are and I failed to predict how many _new_
dma_mapping_error()s would turn up across the -rc phase.  So I suck,
what's new?


otoh, I don't reeeeeeealy worry too much about compile errors during
the merge window.  People get all hot under the collar and shout at
each other, but they're trivial to find (the compiler tells you!) and
almost always trivial to fix and they are almost always trivially
worked around via config if you hit one during a bisect.  Shrug, fix
them and move on.

It's the runtime errors which are far, far, far more of a problem for us.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/