Support "NONE" for max-error-lines in robot.toml#609
Conversation
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
4bd4f68 to
43c3f17
Compare
|
Rebased this onto current Focused verification after the rebase:
The PR is now up to date with the current base; remaining gate is review. |
|
Thanks for the contribution. I’m open to reviewing the actual fix on its technical merits, but I’m not going to leave the paid-fix note uncommented. Small fixes are welcome. Drive-by contributions can be welcome too. AI-assisted contributions are not a problem either. But this PR looks like a very low-context, likely AI-generated or agent-assisted micro-fix: a few lines changed, some generated files touched, a narrow test added, and then a payment request attached to the PR. That combination is a big problem. The PR asks for money while still leaving the real verification, integration, trust, and review work to the maintainers. I have now spent around two hours looking into this PR, writing this comment, and frankly getting increasingly frustrated by the whole situation, including finding similar paid-fix style PRs from you in other GitHub projects. On top of that, the patch itself does not follow the project conventions, so I now also need to review the contribution process issues, verify that the change actually behaves correctly end-to-end, understand and validate the generated file changes, and generally do the integration work that should already have been done before submitting a PR with a payment request attached. That is unpaid maintainer time. If I spent the same time on regular client work, my rate would be at least $150/hour, and you are asking for $10 for this issue? But this is not about the $10. It is about the mismatch: asking to be paid for a small patch while shifting much more unpaid work onto the project. I spend a lot of unpaid time keeping RobotCode and parts of the Robot Framework ecosystem alive: maintaining code, helping users, answering questions, preparing talks, looking for sponsorship, going to conferences and user group meetings, and trying to make the project sustainable. Seeing someone unknown to the project show up, apparently pick a small public issue, not follow the documented contribution process, not ask beforehand whether paid work is wanted, and then attach a paid-fix note to the PR is frustrating. To be blunt: this kind of pattern damages the open-source spirit. It turns public issues into monetization opportunities while maintainers are left with the cost, risk, and long-term responsibility. Honestly, it comes across as if you do not really care what open source actually means or what keeps these projects sustainable in the first place. And I am not talking here about huge projects backed by giant companies with effectively unlimited funding. I am talking about the countless smaller open-source projects that are still heavily used everywhere, depend almost entirely on volunteer work, and where almost nobody gives anything back. Anyway, if someone shows up asking for money for a fix, I expect the work to be complete and ready for review according to the project’s standards. If I pay for a burger, I expect to receive an actual finished burger, not just the bun with the expectation that I will cook the meat, add the toppings, and clean up the kitchen myself. Open source is normally different: people contribute imperfect patches, maintainers give feedback, contributors improve things, trust is built over time, and eventually maintainers are comfortable merging contributions quickly because there is already context and collaboration. That is the normal community model. And sometimes, after someone has been around for a while, contributed consistently, helped others, and built trust, they might reasonably say: “Hey, I would like to take two unpaid days off work to focus on solving this problem — is there any sponsorship, bounty, or support available to help offset that?” That is a completely different situation from showing up out of nowhere with a tiny low-context patch and attaching a payment request to it. A paid-fix note changes that expectation. A paid-fix note raises the bar; it does not lower it. That does not mean I am agreeing to pay for this PR if the issues below are fixed. Paid work needs to be discussed and agreed before the work is started. With that context in mind, these are the concrete issues that still need to be addressed before I can review this further:
Again: this is not about whether AI tools were used. To be honest, this PR strongly looks like a low-context AI-generated or agent-assisted patch: a very small change, incomplete verification, generated files touched without explanation, narrow tests, and a payment request attached. This is about the paid-fix note. If this PR had simply been submitted as a normal community contribution without the paid-fix note attached, the tone and expectations here would probably have been very different. I would likely still have pointed out many of the same issues, but I would have done so in a much friendlier way, with genuine appreciation that someone took the time to look into the problem. Depending on the remaining effort, I might even have fixed some of the smaller issues myself just to get the change merged and the problem solved. And another thing: if this had felt like a genuine contribution, the wording and communication around the PR would probably also have been different. Something more along the lines of: “Hey, I’m ..., I noticed this issue and tried to fix it — would this be useful for the project?” Or even just a friendly comment on the original issue discussing the approach. Communication matters. Instead, your message basically comes across as: “Summary... Verification... If you want, you can pay me.” That is simply not a good tone for an open-source contribution. If you are genuinely interested in contributing to this project as part of the open-source community and without expecting payment, then please address the points above. If not, that is also fine. I also have AI agents available. |
Summary
max-error-lines = "NONE"in the RobotCode config model--maxerrorlines NONECloses #606.
Verification
PYTHONPATH=packages/core/src:packages/robot/src uv run --with pytest --with pytest-mock --with pytest-asyncio --with pytest-rerunfailures --with pyyaml --with tomli-w --with typing-extensions --with robotframework --with platformdirs pytest tests/robotcode/robot/config/test_profile.py tests/robotcode/robot/config/test_model.py tests/robotcode/robot/config/test_toml.pyuv run --with ruff ruff check packages/robot/src/robotcode/robot/config/model.py tests/robotcode/robot/config/test_profile.pypython3 -m json.tool docs/public/schemas/robot.toml.json >/dev/null && python3 -m json.tool etc/robot.toml.json >/dev/nullgit diff --checkPaid-fix note
If this closes the config gap and saves maintainer time, I am asking $10 here: https://nicdunz.gumroad.com/l/slop-kill-pass?wanted=true
No issue if this project only handles volunteer contributions; the patch stands either way.