3 ms·

The advantage of the Pull Request system is that it lends transparency. Especially in a corporate environment, a team can easily ignore and reject a lot of code

by bri3d 9y ago

The advantage of the Pull Request system is that it lends transparency. Especially in a corporate environment, a team can easily ignore and reject a lot of code sent to a mailing list. When each patch is tracked using tooling built for that purpose, this gets a lot harder. Yes, the BFDL maintainers can continue to operate in whatever system they're given, but the more transparent the system is, the more likely they are to be discovered and the issue corrected. I do agree that the E-mail workflow offers (a few) advantages, but the lack of inherent transparency in the tooling tends to be quite troublesome. It also doesn't inherently offer easy integration with automated testing systems or easy audit and compliance logging.

avar 9y ago
I certainly wouldn't recommend it for most situations, especially something like a corporate environment where most people have problems with basic E-Mail workflows like inline quoting and preserving In-Reply-To headers. It's more suited for free software projects like Linux & Git where the participants don't want to be locked out of all their historical discussions just because some company does badly in the stock market, as opposed to being 100% archived in hundreds of places via an open protocol, and trivial to migrate somewhere else. I'm just saying the problems you had with it seem to come down to a completely dysfunctional corporate culture, not patches over E-Mail. Sure if you're working with such monumental assholes that they're just going to passive-aggressively and conveniently discard whatever you tell them over E-Mail / IM / at the water cooler that's pertinent to their work area and need to essentially CC their manager on all correspondence, and are using PRs as a way to do that. Then sure, then an E-Mail-based workflow probably isn't for you, although you could use git-format-patch to CC both your and their manager on every patch you send to achieve similar results.

by bri3d 9y ago

avar 9y ago

I certainly wouldn't recommend it for most situations, especially something like a corporate environment where most people have problems with basic E-Mail workflows like inline quoting and preserving In-Reply-To headers. It's more suited for free software projects like Linux & Git where the participants don't want to be locked out of all their historical discussions just because some company does badly in the stock market, as opposed to being 100% archived in hundreds of places via an open protocol, and trivial to migrate somewhere else. I'm just saying the problems you had with it seem to come down to a completely dysfunctional corporate culture, not patches over E-Mail. Sure if you're working with such monumental assholes that they're just going to passive-aggressively and conveniently discard whatever you tell them over E-Mail / IM / at the water cooler that's pertinent to their work area and need to essentially CC their manager on all correspondence, and are using PRs as a way to do that. Then sure, then an E-Mail-based workflow probably isn't for you, although you could use git-format-patch to CC both your and their manager on every patch you send to achieve similar results.