Christopher Browne wrote:
On Thu, Apr 12, 2012 at 6:11 PM, Jay Levitt<>  wrote:
Rather than extend the CF app into a trivial-patch workflow app, it might be
worth looking at integrating it with github.

There's a reluctance to require a proprietary component that could
disappear on us without notice.

Excellent point. I was thinking that GitHub's API would allow archival exporting to counter that, along the lines of "let's take advantage of it for the next five years until it goes south, and THEN we could write our own". But I can see how that might not be the best choice for a project that expects to preserve history for a few decades.

GitHub does offer an "enterprise version" that you can self-host, but it seems to be priced per-user and intended for solely intranet use.

If the feature set is desirable, though, I wonder if Postgres is big/high profile enough for them to figure out some sort of better arrangement. They *love* it when big open-source projects use GitHub as their public repo - they'll email and blog announcements about it - and if there's interest I'd be happy to open a conversation with them.

The existence of git itself is a result of *exactly* that
circumstance, as Linux kernel developers had gotten dependent on
BitKeeper, whereupon the owner decided to take his toys home, at which
point they were left bereft of "their" SCM tool.

Good history lesson there, with a great outcome.

I expect that it would be more worthwhile to look into enhancements to
git workflow such as<>  Gerrit.  I
don't know that Gerrit is THE answer, but there are certainly projects
that have found it of value, and it doesn't have the "oops, it's
proprietary" problem.

I've looked at it in conjunction with Jenkins CI; it looked nice but was way too heavy-weight for a four-person startup (what's code review?). It's probably much more suitable for this sized project.

Gerrit's a full-featured code review app with a tolerable UI; I was thinking of GitHub more as a great lightweight UI for doc patches and other trivial patches where you might have lots of casual review and comments but no need for, say, recording regression tests against each patch version. e.g.:

Also, for doc patches, GitHub has the great advantage of in-place editing right from the web UI.

Peter mentioned the desire to bring more eyes and hands onto these type of patches - I think the phrase was "enthusiast power users who wouldn't really consider themselves hackers." The advantage of GitHub here would be its (current) widespread adoption; the perceived barrier to entry is far lower and the workflow is far more obvious than a mailing list, formatting patches by email, not quite knowing what the process is.

I mention all this not to try to push GitHub specifically, but to say "these are the types of features that modern, open-source collaborative systems offer, and could improve community involvement".

From a human- rather than technology-oriented perspective: I was shocked to find that you folks *WANT* reviews from non-contributors. It was my assumption as a newcomer that if I don't feel well-versed enough to submit patches yet, the last thing you'd want me to do was to look over someone else's patch and say "Yeah, that looks good", any more than I care if my mom thinks my latest web app is "very nice".

I see now that the "Reviewing a Patch" wiki page explains this, but maybe this info should be pushed higher into the docs and web site; a "How can I contribute" page, open calls for reviewers on the non-hackers mailing lists, things like that. Or maybe just make the wiki page bright red and blink a lot.


Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to