4 ms·

> Can you make a recommendation of a process which doesn't involve cherry-pick commits (or more often patch-sets)? Thank you! You just made me realize that the

> Can you make a recommendation of a process which doesn't involve cherry-pick commits (or more often patch-sets)? Thank you! You just made me realize that there some ambiguity in the original article and thus in my reply; I have nothing against cherry-pick in git and first thought the original article was using the phrase idiomatically, as in "developers picked specific commits with their personal judgment." The rest of this response will be written with that idiomatic reading in mind since that's what I originally intended with my criticism. > I suspect one of the problems here is a lack of bug tracker, which would have associated the fix to the merge and the fix itself together. I agree with this. This would make it immediately obvious that there were multiple fixes for one issue, which should be strange. I also think there should be an overall review process where both: 1. Commits that have been chosen are reviewed by the group 2. Commits that have NOT been chosen should be reviewed by the submitters -- if there's something critical being left out, this is the time to speak up They may already be doing something like this, for all I know, and there may be other reasons that this happened. Additionally, I'm only coming to this conclusion because of the way it was presented in the article; the people involved may have a different view of why this happened entirely. But for me, the way it was presented in the article, it definitely looks like a process failure.

Jach 7y ago
You can only have so much process before you're too far out of the bazaar. This isn't to bring up the relative value tradeoffs of that old split, just to highlight that one shouldn't expect a 'process adjustment' reaction from a fundamentally anti-process collective or for members to even view it primarily through the lens of a process failure. (I'd sooner expect a rant on basic C coding competence even though those days are gone.) That's even if the LKML reflects on this particular timeline of patches much at all; there's no good reason to, really, it's a curiosity. And unlike those of us in a proprietary enterprise no one expects or can insist on an RCA doc with promises to do better backed by planned process tweaks (what issues can't ultimately be recast as process failures?) or new processes.

Jach 7y ago

You can only have so much process before you're too far out of the bazaar. This isn't to bring up the relative value tradeoffs of that old split, just to highlight that one shouldn't expect a 'process adjustment' reaction from a fundamentally anti-process collective or for members to even view it primarily through the lens of a process failure. (I'd sooner expect a rant on basic C coding competence even though those days are gone.) That's even if the LKML reflects on this particular timeline of patches much at all; there's no good reason to, really, it's a curiosity. And unlike those of us in a proprietary enterprise no one expects or can insist on an RCA doc with promises to do better backed by planned process tweaks (what issues can't ultimately be recast as process failures?) or new processes.