From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Mitar <mmitar(at)gmail(dot)com> |
Cc: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: commitfest: When are you assigned patches to review? |
Date: | 2019-01-09 07:38:26 |
Message-ID: | 20190109073826.GA29923@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jan 08, 2019 at 10:56:32PM -0800, Mitar wrote:
> I see that some patches were sent to bugs mailing list, not hackers
> [1]. I thought that all patches have to be send to the hackers mailing
> list, as per this wiki page [2]. Moreover, because they were send to
> the bugs mailing list, I am unsure how can it be discussed/reviewed on
> hackers mailing list while keeping the thread, as per this wiki page
> [3]. Furthermore, I thought that each commitfest entry should be about
> one patch, but [1] seems to provide 3 patches, with multiple versions,
> which makes it a bit unclear to understand which one and how should
> they apply.
That's not a strict process per se. Sometimes when discussing we
finish by splitting a patch into multiple ones where it makes sense,
and the factor which mainly matters is to keep a commit history clean.
Keeping that point in mind we may have one commit fest entry dealing
with one of more patches depending on how the author feels things
should be handled. My take is that additional CF entries make sense
when working on patches which require a different audience and a
different kind of reviews, while refactoring and preparatory work may
be included with a main patch as long as the patch set remains in
roughly the same area of expertise and keeps close to the concept of
the thread dealing with a new feature.
Bugs can be added as CF entries, posting patches on a bug ticket is
also fine. If a bug fix needs more input, moving it to -hackers can
also make sense by changing on the way its subject. This depends on
the circumstances and that's a case-by-case handling usually.
> [1] https://commitfest.postgresql.org/21/1924/
This item is fun to work with, though all of them apply to unaccent
and are not that invasive, so a single entry looks fine IMO.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Mi Tar | 2019-01-09 07:40:57 | Re: [PATCH] Allow UNLISTEN during recovery |
Previous Message | Fabien COELHO | 2019-01-09 07:16:48 | Re: [HACKERS] pgbench - allow to store select results into variables |