Re: Commitfest problems - Mailing list pgsql-hackers

On 14/12/14 20:07, Craig Ringer wrote:

> On 12/15/2014 02:46 AM, Mark Cave-Ayland wrote:
>> Interestingly enough, I tend to work in a very similar way to this. When
>> submitting patches upstream, I tend to rebase on a new branch and then
>> squash/rework as required.
> 
> Same here, and I find it works really well ... when I do it properly.
> 
> I usually have a private development branch that's full of "fixup! "
> commits, WIPs, awful commit messages, etc.
> 
> Then I have the tree that's been rebased, squashed, and tided up.
> 
> I periodically tidy my latest work and replace the old clean tree with
> it, then start my new development branch on top of the new clean tree.
> 
> This gives me a somewhat nice looking, well ordered patch series to work
> on top of, while retaining the flexibility to do lots of quick fixes etc.
> 
> Admittedly, sometimes the development tree gets a bit large and it takes
> a while before I give it a proper cleanup. My current project being very
> much in that category. Still - it works well in general.

That describes my workflow fairly well too.

>> I find that this isn't too bad in practice. If you think about
>> monolithic patches during a commitfest, you can imagine that most of
>> them will touch one of the core .h files which will require most things
>> to be rebuilt once applied during bisection.
> 
> It's not build time, it's test-run time. Especially if you can't
> automate the test, or it isn't practical to.
> 
> That's a legitimate concern - but I don't think we'd see a blowout of
> patch counts to quite the same degree.

At the end of the day, each project finds its own level as to how
complex individual patches should be and what should comprise a
patchset. Over the past couple of years the QEMU process has evolved
into its current form as maintainers and developers have figured out
what works best for them, and I don't see that PostgreSQL would be any
different in this respect - it takes time to adapt to a new workflow and
get it right.

Having worked on various parts for PostGIS for around 10 years, I've had
my head stuck into various parts of the GiST code and have got to know a
few parts of it really well.

What I find frustrating is that I've come back from a workflow where
I've been reviewing/testing patches within months of joining a project
because the barrier for entry has been so low, and yet even with much
longer experience of the PostgreSQL codebase I feel I can't do the same
for patches submitted to the commitfest.

And why is this? It's because while I know very specific areas of the
code well, many patches span different areas of the source tree of which
I have little and/or no experience, which when supplied as a single
monolithic patch makes it impossible for me to give meaningful review to
all but a tiny proportion of them.

I believe that this is one of the main reasons why people struggle to
find patch reviewers, with the consequence being that the majority of
work falls back onto the CF manager and the committers which is why we
have the current situation.


ATB,

Mark.