Re: [GENERAL] C++ port of Postgres - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [GENERAL] C++ port of Postgres
Date
Msg-id 21444.1473546008@sss.pgh.pa.us
Whole thread Raw
In response to Re: [GENERAL] C++ port of Postgres  (Christian Convey <christian.convey@gmail.com>)
List pgsql-hackers
Christian Convey <christian.convey@gmail.com> writes:
>    If that's correct, then it sounds like the only way Joy's commit has
>    a chance of acceptance is if Peter's commit is rejected.
>    Because Peter's commit might be merged as part of the 2016-09
>    commitfest, but Joy's can show up until 2016-11 at the earliest.

No, we're not that rigid about it.  The commitfest mechanism is really
mostly meant to ensure that every submission does get looked at within a
reasonable amount of time and doesn't get forgotten about.  (We do tend
to be willing to tell new patches they've got to wait till the next fest,
but that's mainly when we're already feeling overloaded by what's in the
current queue.)  In this case it would be nonsensical to consider only
Peter's submission and not Joy's, because part of the issue is whether
one's better than the other.

> There seems to be a little ambiguity regarding the exact version of
> the code to be reviewed.  This is true for both Joy's and Peter's
> submissions:
>    * Joy's email provides a link to a Github repo, but does not specify
>      a particular commit (or even branch) in that repo: [2]
>    * In the email thread, Peter did provide a patch set: [3]
>      but the corresponding commitfest entry references a github branch: [4]

Well, at the point we're at here, it's probably not that important exactly
which version of a patchset you're looking at; I'd take the latest.

> Q4) Do we require that any submitted patches appear as attachments on
> the pgsql-hackers email list, or is a github URL good enough?

Actually, we *do* require that, mainly as a formality to show that the
author intended to submit it for inclusion in Postgres.  (We don't want
people coming back later and saying "hey, you ripped off this code from
my github repo without my permission".)  If we were seriously considering
adopting Joy's version then that would have to happen before anything got
merged.  But at this point it seems like we're in a very exploratory
phase and there's no need for legal niceties yet.

> Q5) (This question is more generic.)  I'm accustomed to using Github's
> pull-request system, where I can engage in dialog regarding specifc
> lines of a patch.  I haven't noticed anything similar being used for
> PG code reviews, but perhaps I'm just looking in the wrong places.
> Are all PG code reviews basically just back-and-forth email
> conversations on the pgsql-hackers list?

Yup, that's how we roll ... it's ancient habit from before there was
such a thing as git, let alone github, but we've not seen fit to change.
It does have the advantage that it's about equally amenable to high-
level discussions and line-by-line issues.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robins Tharakan
Date:
Subject: Re: High-CPU consumption on information_schema (only) query
Next
From: Christian Convey
Date:
Subject: Re: [GENERAL] C++ port of Postgres