On Fri, Jul 15, 2022 at 05:23:48PM -0700, Jacob Champion wrote:
> On 7/15/22 16:15, Justin Pryzby wrote:
> > On Fri, Jul 15, 2022 at 03:17:49PM -0700, Jacob Champion wrote:
> >> Also, I would like to see us fold cfbot output into the official CF,
> >> rather than do the opposite.
> >
> > That's been the plan for years :)
>
> Is there something other than lack of round tuits that's blocking
> progress? I'm happy to donate more time in this area, but I don't know
> if my first patch proposal was helpful (or even on the right list --
> pgsql-www, right?).
cfbot is Thomas's project, so moving it run on postgres vm was one step, but I
imagine the "integration with cfapp" requires coordination with Magnus.
What patch ?
> > Similarly, patches could be summarily set to "waiting on author" if they didn't
> > recently apply, compile, and pass tests. That's the minimum standard.
> > However, I think it's better not to do this immediately after the patch stops
> > applying/compiling/failing tests, since it's usually easy enough to review it.
>
> It's hard to argue with that, but without automation, this is plenty of
> busy work too.
I don't think that's busywork, since it's understood to require human
judgement, like 1) to deal with false-positive test failures, and 2) check if
there's actually anything left for the author to do; 3) check if it passed
tests recently; 4) evaluate existing opinions in the thread and make a
judgement call.
> > I didn't know until recently that when a CF entry is closed, that it's possible
> > (I think) for the author themselves to reopen it and "move it to the next CF".
> > I suggest to point this out to people; I suppose I'm not the only one who finds
> > it offputting when a patch is closed in batch at the end of the month after
> > getting only insignificant review.
>
> I think this may have been the goal but I don't think it actually works
> in practice. The app refuses to let you carry a RwF patch to a new CF.
I was able to do what Peter said. I don't know why the cfapp has that
restriction, it seems like an artificial constraint.
https://www.postgresql.org/message-id/8498f959-e7a5-b0ec-7761-26984e581a51%40enterprisedb.com
https://commitfest.postgresql.org/32/2888/
--
Justin