On Tue, Apr 17, 2012 at 4:15 PM, Jay Levitt <jay.lev...@gmail.com> wrote: > That's a great point. Both GitHub and git itself have no real concept of > releases, and can't tell you when a commit made it in.
Those factors likely play together in this. Git is a tool, not a workflow, and intentionally allows its users to use it in a variety of ways. (Which includes some very interesting pathologies visible with stuff like git-annex, git-mail.) It's not a bug that git can do things differently than the Postgres project wants things done. Likewise, it's not a bug that github, which intends to support all kinds of users using git, does not enforce the preferred Postgres workflow. I think it's pretty *normal* that we'd need tooling that won't be identical to (say) GitHub, and we shouldn't get too exercised about this. I wonder if our "fix" instead involves: a) Adding an ArchiveOpteryx instance to archive mailing list traffic; http://archiveopteryx.org/ b) A bit more tooling to make it easier to link to threads in that instance c) Perhaps some management tools based on debbugs to ease scripting of issues being tracked That's not prescriptive; just ideas. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?" -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
