On Tue, 2008-08-19 at 08:53 +0200, Arnaud Simon wrote: > On Mon, 2008-08-18 at 23:06 +0100, Robert Greig wrote: > > 2008/8/18 Aidan Skinner <[EMAIL PROTECTED]>: > > > > > That's why having a pool is better, if one person is busy with other > > > stuff then others can pick up the load. If everybody is crunching like > > > a maniac, it's probably a sign that careful review is even more > > > necessary - I know the quality of my patches has an inverse > > > relationship to the amount of Irn Bru consumed. ;) > > > > I don't like the idea of a pool basically because of the lack of > > accountability. > > > > > I don't think there's a significant difference in the toolset between > > > commit-then-review and review-then-commit, and certainly not a > > > compelling one that outweighs the other advantages of reviewing first. > > > > OK, FWIW here's what I would do. No review board, just: > > > > 1) work on issue and commit changes > > 2) mail or IM someone asking if he would mind reviewing it > > 3) assign issue to person doing review and move on until issue is > > either reopened by reviewer or resolved (or whatever state comes next) > > 4) run jira report regularly of issues in "pending review" state with > > no activity for 5 days. For those issues go back to step (2) with > > alternative reviewer if necessary. > > > > I think it would be useful to get some of the other committers' views > > on what would work for them. > > > > RG > > +1 to this suggestion > Big +1 from me.
Speaking from my current immersion in cluster performance issues, having 2 asynchronous streams of activity that don't block each other is the Only Way, every time you put a synchronous bubble in the workflow performance goes straight down the toilet. It's driving me crazy.
