On Tue, Apr 17, 2012 at 4:15 PM, Jay Levitt <jay.levitt@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?"