|From:||Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: Commitfest statistics|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2020-Dec-07, Tom Lane wrote:
> Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru> writes:
> > Firstly, we use it to track patches that we want to see in the nearest
> > releases and concentrate our efforts on. And current CFM guideline 
> > reflects this idea. It suggests, that after the commitfest closure date
> > we relentlessly throw to RWF patches that got at least some feedback. To
> > be honest, I was reluctant to return semi-ready patches, because it
> > means that they will get lost somewhere in mailing lists. And it seems
> > like other CFMs did the same.
> Yeah, the aggressive policy suggested in "Sudden Death Overtime" is
> certainly not what's been followed lately. I agree that that's
> probably too draconic. On the other hand, if a patch sits in the
> queue for several CFs without getting committed, that suggests that
> maybe we ought to reject it on the grounds of "apparently nobody but
> the author cares about this". That argument is easier to make for
> features than bug fixes of course, so maybe the policy needs to
> distinguish what kind of change is being considered.
Note that this checklist was written in 2013 and has never been updated
since then. I think there is nothing in that policy that we do use.
I'm thinking that rather than try to fine-tune that document, we ought
to rewrite one from scratch.
For one thing, "a beer or three" only at end of CF is surely not
|Next Message||Rémi Lapeyre||2020-12-07 23:40:24||Re: Add header support to text format and matching feature|
|Previous Message||Jeff Davis||2020-12-07 23:24:14||Re: Minor documentation error regarding streaming replication protocol|