6 ms·

plain emailed diffs? this isn't LKML

exBarrelSpoiler 9y ago
The primitive state of tooling in some corners of a sprawling corporate empire would make your head spin.
bri3d 9y ago
There have existed teams at every company I have ever worked for who argue that this is the Very Best Way (tm) to develop code. It allows for the True Gatekeepers to keep their hold over the perceived software quality and quickly routs any sort of outside interest from modifying the project in any way the True Gatekeepers don't desire. In entirely broken organizations this is an effective way to allow 2-3 good developers to produce software in spite of the culture. In any organization beyond entirely broken, this prohibits a team from scaling beyond 2-3 key core members and tends to allow that small group to become the BOFH, maintaining a reign of terror over all non-blessed developers, regardless of seniority or title, who dare contribute to the product. In some senses this is the Linus "benevolent dictatorship," but in most, it's a despotic system that collapses as soon as one of the core contributors moves on or retires. In my experience most attempts to move these sorts of teams towards real revision control and development practice lead to an extinction event in which they practice every form of hazing possible to maintain control, requiring careful management. Think extreme code-format nitpicking (combined with a lack of automated tooling or a styleguide that would let "others" get it right), followed by appeals to whichever authority maintained their team, outright hostility, and eventually ultimatum or holding the code hostage.
- chopin 9y ago
  But how is emailing different from something like eg. Gerrit or pull requests. Ultimately, it's always the maintainers who get to decide what gets into the repo. What you describe is a problem occurring independent of the way changes are merged. I agree that it can be a real problem.
  - claudex 9y ago
    You can allow multiple person to accept a pull request. So you don't have "a" maintainer but some.
  - bri3d 9y ago
    I think your sibling post is similar in sentiment and it comes down to transparency. In the "patches-to-a-list" model, there's no running status page or record of exactly what patches were rejected or ignored, and by whom. Anyone wanting that information would have to go to a lot of work parsing, searching, and analyzing the mailing list. With Gerrit or pull requests, reviewers are clearly assigned and patch states are managed in a centralized dashboard. This makes it a lot easier for external stakeholders (managers, other development staff, etc.) to gain insight into how a team's working and whether or not they're being accepting or effective. And that's why, to me, these kinds of toxic maintainers seem to suffer an extinction event when moved to a more transparent system. The maintainers are the same, but their tool - quietly rejecting patches with little accountability - is taken away from them.
- avar 9y ago
  Git itself is developed this way, so saying it could be fixed by "real revision control" is silly. Maybe you worked with someone who misused this model, but there's good reason Git and Linux use it.
  - oillio 9y ago
    I think the OP covered this argument with is comment about Linus' "benevolent dictatorship." That is an extreme outlier. If your organization is run by someone like Linus, it can work, maybe.
    - avar 9y ago
      Git hasn't been run by Linus for over 10 years, and uses this workflow. Is it flawed in some ways? Sure, but it works and has its advantages. Furthermore the way patches are submitted, discussed and reviewed has little to do with the process by which they're eventually accepted or rejected by a BFDL maintainer, unlike what the GP is claimnig. If the kernel used say Github pull requests you'd just have Linus rejecting some of those instead of refusing to accept patch serieses submitted by E-Mail. The GP is just railing against some bad experience with the "True Gatekeepers", as if a company that was dysfunctional enough to use E-mailed patches as some unreasonable filtering mechanism wasn't able to do so via other methods. The advantages of the E-Mail workflow is that it's fully distributed (aside from the ML hosting), bug/patch discussion can naturally flow into one another, everyone can use their favorite client that they can script etc., and you don't need an active network connection to participate (do all your patch review on the plane), all as opposed to using some opaque web UI.
      - 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.
rwmj 9y ago
What's not to like? Lightweight, multiple interoperable tools (MUAs and editors), no barrier to entry, easy to review and comment. Compared to shitshows like Gerrit and the awful clunky workflow of Github, I'll take an emailed patch every time. Does it scale to huge patchsets? ... well not so much. However Gerrit is not the answer to that (in fact, no tool I've found provides a good answer).
- pm215 9y ago
  The major problem with the email-patches workflow is that it is a pretty poor experience for the new and occasional contributor, who will generally find that their email client makes a complete pig's ear of their patch. What I'd really like to see is a web UI that seamlessly interacted with the trad email workflow, so people who prefer a web UI and especially people who are just making a single drive-by contribution could work that way without having to start by setting up git-send-email. You could also make the web interface keep track of which patches are still unreviewed so things drop through the cracks less often...

The primitive state of tooling in some corners of a sprawling corporate empire would make your head spin.

There have existed teams at every company I have ever worked for who argue that this is the Very Best Way (tm) to develop code. It allows for the True Gatekeepers to keep their hold over the perceived software quality and quickly routs any sort of outside interest from modifying the project in any way the True Gatekeepers don't desire. In entirely broken organizations this is an effective way to allow 2-3 good developers to produce software in spite of the culture. In any organization beyond entirely broken, this prohibits a team from scaling beyond 2-3 key core members and tends to allow that small group to become the BOFH, maintaining a reign of terror over all non-blessed developers, regardless of seniority or title, who dare contribute to the product. In some senses this is the Linus "benevolent dictatorship," but in most, it's a despotic system that collapses as soon as one of the core contributors moves on or retires. In my experience most attempts to move these sorts of teams towards real revision control and development practice lead to an extinction event in which they practice every form of hazing possible to maintain control, requiring careful management. Think extreme code-format nitpicking (combined with a lack of automated tooling or a styleguide that would let "others" get it right), followed by appeals to whichever authority maintained their team, outright hostility, and eventually ultimatum or holding the code hostage.

chopin 9y ago
But how is emailing different from something like eg. Gerrit or pull requests. Ultimately, it's always the maintainers who get to decide what gets into the repo. What you describe is a problem occurring independent of the way changes are merged. I agree that it can be a real problem.
- claudex 9y ago
  You can allow multiple person to accept a pull request. So you don't have "a" maintainer but some.
- bri3d 9y ago
  I think your sibling post is similar in sentiment and it comes down to transparency. In the "patches-to-a-list" model, there's no running status page or record of exactly what patches were rejected or ignored, and by whom. Anyone wanting that information would have to go to a lot of work parsing, searching, and analyzing the mailing list. With Gerrit or pull requests, reviewers are clearly assigned and patch states are managed in a centralized dashboard. This makes it a lot easier for external stakeholders (managers, other development staff, etc.) to gain insight into how a team's working and whether or not they're being accepting or effective. And that's why, to me, these kinds of toxic maintainers seem to suffer an extinction event when moved to a more transparent system. The maintainers are the same, but their tool - quietly rejecting patches with little accountability - is taken away from them.
avar 9y ago
Git itself is developed this way, so saying it could be fixed by "real revision control" is silly. Maybe you worked with someone who misused this model, but there's good reason Git and Linux use it.
- oillio 9y ago
  I think the OP covered this argument with is comment about Linus' "benevolent dictatorship." That is an extreme outlier. If your organization is run by someone like Linus, it can work, maybe.
  - avar 9y ago
    Git hasn't been run by Linus for over 10 years, and uses this workflow. Is it flawed in some ways? Sure, but it works and has its advantages. Furthermore the way patches are submitted, discussed and reviewed has little to do with the process by which they're eventually accepted or rejected by a BFDL maintainer, unlike what the GP is claimnig. If the kernel used say Github pull requests you'd just have Linus rejecting some of those instead of refusing to accept patch serieses submitted by E-Mail. The GP is just railing against some bad experience with the "True Gatekeepers", as if a company that was dysfunctional enough to use E-mailed patches as some unreasonable filtering mechanism wasn't able to do so via other methods. The advantages of the E-Mail workflow is that it's fully distributed (aside from the ML hosting), bug/patch discussion can naturally flow into one another, everyone can use their favorite client that they can script etc., and you don't need an active network connection to participate (do all your patch review on the plane), all as opposed to using some opaque web UI.
    - 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.

rwmj 9y ago

What's not to like? Lightweight, multiple interoperable tools (MUAs and editors), no barrier to entry, easy to review and comment. Compared to shitshows like Gerrit and the awful clunky workflow of Github, I'll take an emailed patch every time. Does it scale to huge patchsets? ... well not so much. However Gerrit is not the answer to that (in fact, no tool I've found provides a good answer).

pm215 9y ago
The major problem with the email-patches workflow is that it is a pretty poor experience for the new and occasional contributor, who will generally find that their email client makes a complete pig's ear of their patch. What I'd really like to see is a web UI that seamlessly interacted with the trad email workflow, so people who prefer a web UI and especially people who are just making a single drive-by contribution could work that way without having to start by setting up git-send-email. You could also make the web interface keep track of which patches are still unreviewed so things drop through the cracks less often...