5 ms·

I deeply appreciate the great care that Postgres committers take in writing their merge messages. I think of it as a sign of respect for future developers to t

I deeply appreciate the great care that Postgres committers take in writing their merge messages. I think of it as a sign of respect for future developers to take the time to write a clear account of what has happened.

anarazel 10y ago
Being one of them, though not a native speaker which is more than sometimes noticeable, I'd not even describe it as caring for future developers. It's self-care. I've spent enough time staring at code changes made long ago, trying to understand the reasoning, that providing enough context for my future self is justification enough.
- jacques_chester 10y ago
  I agree with that sentiment. I consider my future self to be an example of "other developers". When I am working with peers on writing a commit message, I sometimes use the analogy of a newspaper. Any given newspaper is out of date very quickly. But we keep newspaper archives and store copies of every single newspaper. Why? Because we don't know when we will need to refer to them, or which ones we will refer to. All that we know is that some of them will vital in future, as the journal of record. And so it is with commit messages. We owe readers the courtesy of explaining our thinking.
atombender 10y ago
Postgres is one of the few projects that still use a strict patch-oriented development process that's based almost entirely around mailing-list communication. While core team members can commit directly to the repo, everyone else must submit the code changes for review to the pgsql-hackers mailing list as a clean, self-contained patch, where it's discussed and considered for inclusion. An accepted patch might be committed right away, or it will be queued up for the next scheduled "commitfest" [2], when patches are reviewed and finally committed to mainline. (I don't know how the commitfest interacts with git exactly; the commitfest database doesn't even link to git, only to email discussions.) From the outside it seems a bit antiquated, but it's apparently been working well for them. The Postgres team is a pretty conservative bunch; they only switched from CVS to git in late 2010, for example. They also really care about code quality, getting the design right early, and covering all possible edge cases. As a result, Postgres solid, clean, has unusually few legacy oddities, and almost never any subtle, suprising breaking changes. If you read the MySQL manual, it's absolutely littered with sloppy little breakages throughout its history: Like how, until 5.0.something, when comparing a "date" value with a "datetime" value, the time portion would be silently ignored and ('2017-04-08 14:04' = '2017-04-08') would return true; but they fixed that, and broke a lot of client code because they didn't stop to realize that a lot of developers depended on that behaviour. [1] https://wiki.postgresql.org/wiki/Submitting_a_Patch https://wiki.postgresql.org/wiki/Submitting_a_Patch [2] https://commitfest.postgresql.org https://commitfest.postgresql.org
- scrollaway 10y ago
  Wine is another such project :) But I gotta say it's only working for those projects because they have an extremely high barrier of entry to the code itself in the first place (working on projects like Wine and Postgres is scary, even though you can get started with easy stuff). It also works for them because they have maintainers and core committers used to the workflow, already tooled on the workflow etc. But I wonder how much productivity would be gained by using a github-like flow maybe enhanced a bit.
  - anarazel 10y ago
    In my opinion github isn't quite ready for more complex things: - Lengthy reviews yield PRs that measure many megabytes, become unusably slow - There's no reasonable way to do PRs based on other PRs, without closing and reopening then when the underlying branch is merged - large changes can't even be displayed - doesn't work offline. I do a fair amount of review while traveling, and not being able to do reviews while offline would prevent me from doing so Then there's political issues: there's absolutely no guarantee github will be around in a few years. Postgres is old, and will hopefully live long into three future. When it started there was no sourceforge, and now there's again no sf. I very regularly look back into old development discussions...
    - scrollaway 10y ago
      Yeah absolutely, hence why I said github-like. What I mean by that is something more modern, that supports such review style. If only Github supported mailing lists...
      - pgaddict 10y ago
        There's still the aspect of handing over the control to a third party that may disappear next month, discontinue the features you rely on, etc. FWIW, I don't think the workflow is a major barrier. Do 'git format-patch' and submit it to mailing list is about as simple as it can be. It's all the other stuff (complex code-base, going through review, ...) and fairly high bar for quality that makes it challenging.

anarazel 10y ago

Being one of them, though not a native speaker which is more than sometimes noticeable, I'd not even describe it as caring for future developers. It's self-care. I've spent enough time staring at code changes made long ago, trying to understand the reasoning, that providing enough context for my future self is justification enough.

jacques_chester 10y ago
I agree with that sentiment. I consider my future self to be an example of "other developers". When I am working with peers on writing a commit message, I sometimes use the analogy of a newspaper. Any given newspaper is out of date very quickly. But we keep newspaper archives and store copies of every single newspaper. Why? Because we don't know when we will need to refer to them, or which ones we will refer to. All that we know is that some of them will vital in future, as the journal of record. And so it is with commit messages. We owe readers the courtesy of explaining our thinking.

atombender 10y ago

Postgres is one of the few projects that still use a strict patch-oriented development process that's based almost entirely around mailing-list communication. While core team members can commit directly to the repo, everyone else must submit the code changes for review to the pgsql-hackers mailing list as a clean, self-contained patch, where it's discussed and considered for inclusion. An accepted patch might be committed right away, or it will be queued up for the next scheduled "commitfest" [2], when patches are reviewed and finally committed to mainline. (I don't know how the commitfest interacts with git exactly; the commitfest database doesn't even link to git, only to email discussions.) From the outside it seems a bit antiquated, but it's apparently been working well for them. The Postgres team is a pretty conservative bunch; they only switched from CVS to git in late 2010, for example. They also really care about code quality, getting the design right early, and covering all possible edge cases. As a result, Postgres solid, clean, has unusually few legacy oddities, and almost never any subtle, suprising breaking changes. If you read the MySQL manual, it's absolutely littered with sloppy little breakages throughout its history: Like how, until 5.0.something, when comparing a "date" value with a "datetime" value, the time portion would be silently ignored and ('2017-04-08 14:04' = '2017-04-08') would return true; but they fixed that, and broke a lot of client code because they didn't stop to realize that a lot of developers depended on that behaviour. [1] https://wiki.postgresql.org/wiki/Submitting_a_Patch https://wiki.postgresql.org/wiki/Submitting_a_Patch [2] https://commitfest.postgresql.org https://commitfest.postgresql.org

scrollaway 10y ago
Wine is another such project :) But I gotta say it's only working for those projects because they have an extremely high barrier of entry to the code itself in the first place (working on projects like Wine and Postgres is scary, even though you can get started with easy stuff). It also works for them because they have maintainers and core committers used to the workflow, already tooled on the workflow etc. But I wonder how much productivity would be gained by using a github-like flow maybe enhanced a bit.
- anarazel 10y ago
  In my opinion github isn't quite ready for more complex things: - Lengthy reviews yield PRs that measure many megabytes, become unusably slow - There's no reasonable way to do PRs based on other PRs, without closing and reopening then when the underlying branch is merged - large changes can't even be displayed - doesn't work offline. I do a fair amount of review while traveling, and not being able to do reviews while offline would prevent me from doing so Then there's political issues: there's absolutely no guarantee github will be around in a few years. Postgres is old, and will hopefully live long into three future. When it started there was no sourceforge, and now there's again no sf. I very regularly look back into old development discussions...
  - scrollaway 10y ago
    Yeah absolutely, hence why I said github-like. What I mean by that is something more modern, that supports such review style. If only Github supported mailing lists...
    - pgaddict 10y ago
      There's still the aspect of handing over the control to a third party that may disappear next month, discontinue the features you rely on, etc. FWIW, I don't think the workflow is a major barrier. Do 'git format-patch' and submit it to mailing list is about as simple as it can be. It's all the other stuff (complex code-base, going through review, ...) and fairly high bar for quality that makes it challenging.