Android, forking, and control

Posted Jun 7, 2011 15:59 UTC (Tue) by swetland (guest, #63414)
In reply to: Android, forking, and control by lmb
Parent article: Android, forking, and control

One of the most frustrating parts of interacting with the upstream kernel community is the seemingly-infinite number of people who can say "no" or can at least cause enough noise to derail forward progress.

To take the wakelock situation as an example, every time things were explained, patches were rewritten (10+ times with massive discussion and often extensive arguments about naming, etc, which we weren't terribly picky about), some other group of people jumped in and suddenly there were *different* objections or requirements.

Finally, a "solution" that doesn't actually address our concerns is pushed through, which *nobody* uses because it doesn't meet our needs (so we use our existing one) and nobody else appears to be interested, and now we're simply told "oh the problem has been solved, go rewrite your userspace to use this new interface".

At a certain point, it's easy to get the impression that your time is intentionally being wasted by people who have no interest in ever accepting your work.

On the upside, though the userspace interface for the code that eventually hit mainline doesn't meet our needs, a kernel API now exists that we can make use of to communicate with our own userspace interface without needing #ifdefs or a non-mainline API in drivers. So, that's progress at least.

Android, forking, and control

Posted Jun 7, 2011 17:53 UTC (Tue) by dunlapg (guest, #57764) [Link]

> At a certain point, it's easy to get the impression that your time is intentionally being wasted by people who have no interest in ever accepting your work.

This. There's certainly a lot of good engineering work done in the kernel community, and it's good that there are people who care about code quality and can say 'no' to stuff which is no good. But after working with the community for a while, you can't help but get the feeling that many of the people saying 'no' *also* enjoy just exercising their ability to say 'no'.

Android, forking, and control

Posted Jun 9, 2011 10:09 UTC (Thu) by modernjazz (guest, #4185) [Link] (1 responses)

> At a certain point, it's easy to get the impression that your time is intentionally being wasted by
> people who have no interest in ever accepting your work.

For what it's worth, this isn't unique to kernel patch review: I suspect that almost anyone who has been in academia long enough has a story about how one of their papers has been "held hostage" by a reviewer who appears to be motivated by delaying its publication. And while I'm sure there are cases where that's really true, I think more commonly the true source of "obnoxious" reviews are people not understanding or appreciating what you're trying to do. Perhaps the main culprit is lack of time: if you aggregate all the different forms of review together (student exams and presentations, papers, grants, and administrative proposals), a typical academic may spend more time evaluating other people's work than doing his/her own research. That adds a lot of time pressure to get reviews done quickly, and contributes to occasional sloppiness. It's the dark underbelly of a system that, despite its warts, is basically necessary for any large undertaking to make progress.

I'm not saying this is what happened in the case of Android (I don't know enough about the details to know), but just a bit of outside perspective on the weaknesses of review processes in general. I suspect there's no way to avoid problems altogether, but one positive step might be more recognition for people who do a good, conscientious job of reviewing.

Android, forking, and control

Posted Jun 9, 2011 15:47 UTC (Thu) by PaulMcKenney (✭ supporter ✭, #9624) [Link]

Heh! It did take me about ten years from first submission to high-end-academic conference acceptance of an RCU-related article. The first article in a high-end academic journal giving a detailed description of RCU will likely appear within a year or so, about 15 years after first submission.

About five years of that time was due to me learning how to describe RCU coherently to an academic audience. For the rest of the time spent, the issues described in the parent article apply, particularly the part about lack of time. All too often academics are doing their review in the wee hours of the morning, which makes it hard for them to wrap their heads around something truly new and foreign. So a successful academic paper needs to be sailing some place new, but it had better be sailing really close to shore.

So again, this comes down to communication: papers where the reviewer can quickly and easily understand what is new and interesting about the submission are more readily accepted than papers that cover less-familiar material. So in that sense, yes, this problem is inherent in review in general, not just review of kernel patches.