On Mon, 28 Jul 2008 11:07:40 +1000 (EST) James Morris <[EMAIL PROTECTED]> 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. _______________________________________________ Linuxppc-dev mailing list [email protected] https://ozlabs.org/mailman/listinfo/linuxppc-dev
