Re: Avoid a possible out-of-bounds access (src/backend/optimizer/util/relnode.c) - Mailing list pgsql-hackers
From | David Rowley |
---|---|
Subject | Re: Avoid a possible out-of-bounds access (src/backend/optimizer/util/relnode.c) |
Date | |
Msg-id | CAApHDvpckqFg3pqrDXKRZ6g0LL_t7LTRcEDjdc=dgeCPf5irCA@mail.gmail.com Whole thread Raw |
In response to | Re: Avoid a possible out-of-bounds access (src/backend/optimizer/util/relnode.c) (Ranier Vilela <ranier.vf@gmail.com>) |
List | pgsql-hackers |
On Fri, 29 Sept 2023 at 01:00, Ranier Vilela <ranier.vf@gmail.com> wrote: > Perhaps, and using your own words, the leaders on this project seem > to be against reviewers armed with blunderbuss, too. I don't have any ideas on what you're talking about here, but if this is a valid concern that you think is unfair then maybe the code of conduct team is a more relevant set of people to raise it with. My mention of the scattergun approach to writing patches was aimed at helping you have more success here. I'd recommend you resist the urge to change unrelated code in your patches. Your experience here might improve if you're able to aim your patches at resolving specific issues. I know you'd love to see commit messages that include "In passing, adjust a random assortment of changes contributed by Ranier Vilela". That's just not going to happen. You might think the committer's job is just to commit patches contributed by contributors, but what you might not realise is that we're also trying to maintain a codebase that's over 3 decades old and will probably outlive most of its current contributors. Making things easy both for ourselves in several years time and for our future counterparts is something that we do need to consider when discussing and making changes. The mail archives and commit messages are an audit trail for our future selves and future counterparts. That's one of the main reasons why we tend to not like you trying to sneak in assortments of random changes along with your change. If you can understand this and adapt to this way of thinking then you're more likely to find yourself feeling like you're working with committers and other contributors rather than against them. I say this hoping you take it constructively, but I find that you're often very defensive about your patches and often appear to take change requests in a very negative way. On this thread you've demonstrated to me that by me requesting you to remove an unrelated change in the patch that I must not care about code quality in PostgreSQL. I personally find these sorts of responses quite draining and it makes me not want to touch your work. I would imagine I'm not the only person that feels this. So there's a real danger here that if you continue to have too many negative responses in emails, you'll find yourself ignored and you're likely to find that frustrating and that will lead to you having a worse experience here. This does not mean you have to become passive to all requests for changes to your patches, but if you're going to argue or resist, then it pays to politely explain your reasoning so that the topic can be discussed constructively. > I confess that some "in pass", "while there", and some desire to enrich the patch, clouded my judgment. I'm glad to see you're keen to make improvements to PostgreSQL, however, I'd like to suggest that you channel that energy and aim to produce patches targeted in those areas that attempt to resolve a series or perhaps all problems of that particular category in isolation. If it's a large patch then it's likely best to get consensus first as having lots of work rejected is always more painful. > So it seems that we have some consensus, I propose version 2 of the patch, > which I hope we will have to correct, perhaps, the words of the comments. I've pushed this patch after making an adjustment to the comment to shorten it to a single line. Thank you for working on this. David
pgsql-hackers by date: