Re: [GENERAL] C++ port of Postgres

From: Christian Convey <christian(dot)convey(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Joy Arulraj <jarulraj(at)cs(dot)cmu(dot)edu>, Fabrízio Mello <fabriziomello(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [GENERAL] C++ port of Postgres
Date: 2016-09-10 21:12:22
Message-ID: CAPfS4ZySQ9gAxOZ6inZEtBUgxWypD2kDDGnRnSbjSWoGdK+WQg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

> Thanks. It sounds like worst-case scenario, I perform an unneeded
> review. I'll give it a shot.

Hi guys,

Apologies for more boring process-related questions, but any pointers
would be greatly appreciated...

I'm a bit confused about how PG's code-review process is meant to
handle this C++ port. My confusion may stem from the combination of
my inexperience with the process, and there being two competing patch
sets.

Here's some background:

* My intention was to review Joy's patch.

* On "commitfest.postgresql.org" (for 2016-09), the only C++
-related patch I found was Peter's: [1]

* I wrongly assumed that the commitfest entry would be for
Joy's patch, not Peter's, so I signed up as its reviewer.
(That's fine - I don't mind reviewing both authors' patch
sets.)

But here are my questions:

Q1) My understanding of PG's code-review process is that it's a pipeline:
Step 1. The discussion starts on the pgsql-hackers mailing list, where
the author posts a patch. He/she may also post revised patches
based on the discussion.

Step 2. A subset of those discussions are modeled by new entries in
the commitfest website.

Step 3. A subset of those commitfest items get merged.

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.

Is my understanding correct?

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]

So I have a few questions here:

Q2) Are authors expected to submit an unambiguous patch to frame the
discussion? (I.e,. a specific patch file, or a specific git commit
hash, as opposed to a github repo or a github branch.)

Q3) Are authors expected to submit a single patch/commit, or is it
acceptable / desirable for a large patch to be broken up as Peter has
done?

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

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?

Thanks,
Christian

[1] https://commitfest.postgresql.org/10/776/
[2] https://www.postgresql.org/message-id/CABgyVxDBd3EvRdo-Rd6eo8QPEqV8%3DShaU2SJfo16wfE0R-hXTA%40mail.gmail.com
[3] https://www.postgresql.org/message-id/bf9de63c-b669-4b8c-d33b-4a5ed11cd5d4%402ndquadrant.com
[4] https://github.com/petere/postgresql/tree/commitfest/c%2B%2B

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2016-09-10 21:18:28 Re: Trigger is not working for Inserts from the application
Previous Message Kiran 2016-09-10 21:09:27 Re: Trigger is not working for Inserts from the application

Browse pgsql-hackers by date

  From Date Subject
Next Message Robins Tharakan 2016-09-10 21:25:38 Re: High-CPU consumption on information_schema (only) query
Previous Message Tom Lane 2016-09-10 20:35:48 Re: High-CPU consumption on information_schema (only) query