Re: Last gasp

On Sat, Apr 14, 2012 at 2:28 PM, Jay Levitt <jay(dot)levitt(at)gmail(dot)com> wrote:
> Christopher Browne wrote:
>>
>> On Thu, Apr 12, 2012 at 6:11 PM, Jay Levitt<jay(dot)levitt(at)gmail(dot)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.

I don't know if GitHub's pull request or Gerrit is a good tool (I
doubt, actually), but I've been thinking how we could improve our
review process in terms of both of human process perspective and tool
process. As we have our simple CF app (while there are a bunch of
tools like JIRA or something), I'd think we could have our own review
UI connected to the rest of our toolset including CF app. I know we
want the mail archive history of the whole discussion, but still
giving feedback to the submitter via email is hard-work and the
successors cannot read it entirely.

> 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.

I found myself enjoying reviewing other patches where I don't have
strong knowledge. I strongly believe we should encourage more and
more people who haven't worked particular patches in that area, to
review patches. The more eyeballs there are, the more quality we get.

Thanks,
--
Hitoshi Harada