RussellSpitzer commented on PR #3256:
URL: https://github.com/apache/polaris/pull/3256#issuecomment-3774110829
> @RussellSpitzer I understand where you are coming from. I just want to
note that the size of this PR has already increased by 500 LoC since it was
opened because the dependency to a Nessie library was considered as a blocker.
And I think it would be unusual to first block a PR because it depends on an
external library, then request the code to be pulled into Polaris, and then
block it again because it became too big.
>
That's unfortunately how it goes some times with large changes to the code
base or the addition of new dependencies. I probably should have specified that
the Nessie code should come in a different PR (or PRs) as a prerequisite for
this one is based on, so sorry if that wasn't clear. **(Also i'm not blocking,
just trying to encourage what I think are healthier community behaviors)**
> I think I have seen multiple PRs in the project where contributions,
however imperfect, are welcome, with the request that things are quickly fixed
in follow-up PRs. I am sure I can do some digging to find examples. Isn't that
a normal thing in OSS projects?
This is my personal opinion but I am strongly against "fix in a followup"
and I agree it's happened many times in this project. I'm saying I don't like
that. Follow ups should be
- planned (this is pr is an independent part of a larger whole),
- issues discovered while reviewing that weren't previously known (another
bug is discovered for example)
- refactors (i'm fixing a bug and it would be great if the class structure
was different but not necessary for fixing the bug).
Ideally PRs are small, self contained, complete and have addressed all
concerns. The biggest problem with "fix in a followup" is that it makes the
community look like we don't have an equal playing-ground for all contributors.
We should always be asking is this something we would accept from an unknown
contributor?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
