Re: Last gasp - Mailing list pgsql-hackers

Christopher Browne wrote:
> On Thu, Apr 12, 2012 at 6:11 PM, Jay Levitt<jay.levitt@gmail.com>  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.
> <http://kerneltrap.org/node/4966>

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<http://code.google.com/p/gerrit/>  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.:

https://github.com/rails/rails/pull/5730

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.

Jay