On the one hand, if you grew up in the baazzar, moving to the cathedral might feel like the "death of open source" even if it is really just a return to an earlier way of working. On the other hand, while not accepting external code contributions will certainly improve their security posture it will also make it more difficult to identify who to invite to join the priesthood.
Changing how we develop Ladybird
61–70 of 602 posts
Re: Changing how we develop Ladybird
#62Sometimes the discussions on PRs are equally valuable to see how a commit was arrived at, and I'd be sad if that got lost in this change.
Re: Changing how we develop Ladybird
#63> Outside involvement still matters: clear bug reports
So I can find a bug, I can fix it, but I am not allowed to tell them how exactly I did it.
Instead they have to re-figure it out. The team must be thrilled to re-do work they know was already put in by others, repeatedly.
As a user-and-eveloper, why would I sink time into a project with such rules that put a barrier to improving my life with the software? It seems much easier to use Firefox or Chromium, where my fixes actually meet open ears.
It was very useful for me in the past when a new Chromium version crashed on my product, that I could go and suggest a fix to V8, and it was rolled out in the next Chromium release so my product worked again (https://github.com/v8/v8/commit/4f8a70adca01c). Without this, maybe Chromium developers would have never bothered to fix it because of lack of time to figure it out.
> a pull request no longer tells us as much as it used to about the person submitting it
Nobody should need to know anything about any person submitting a pull request. Hopefully whether code that makes it into Firefox or Chromium was never based on the "effort" or "faith" of the submitter, but based on the correctness of the code in review.
Reviewing code fixes is strictly easier than coming up with them yourself.
This holds true automatically: In any situation where it isn't, you can just write the code yourself and done.
As a project you can always ignore or close a PR you want to write yourself instead. But it seems unwise to bar yourself from the _option_ of reviewing an outside contribution, or using it as input for your own re-write.
Re: Changing how we develop Ladybird
#64Surely you can just autoclose any PRs from 1. People you don't know and 2. That are over 100 or even 50 lines? That way new contributors are forced to start small.
I think it's not the issue with the added PR count, but the fact they have to review them. 1 big PR review is the same as 5 small PR reviews if you have to look at how it holds, edge cases and what not...
Re: Changing how we develop Ladybird
#65Earlier quoted context omitted.
> Whether code was typed by hand is beside the point. What matters is who is responsible for it once it enters the browser. Ladybird is becoming a browser for real users. The people introducing changes to it must be the people who decide those changes belong in the project, and who will answer for the consequences. It probably accelerated the decision, but I don't think that's all of it. I think they're moving in the…
It's still open source, but not open for public contributions. That's pretty much how it was before the advent of these forges.
This is the first time I've seen a project with this much history in community contributions close down, though. I suspect AI will cause more projects to follow in Ladybird's footsteps.
Re: Changing how we develop Ladybird
#66It's kinda surprising to me that even the people who are all in on ai haven't internalized that there's no inherent value in producing a big lump of code. They've massively decreased the work they put in but still expect the same pre-ai reaction/gratitude when submitting a big PR.
Re: Changing how we develop Ladybird
#67Stuff like this makes me wish AI had never happened. An open-source projects losing the ability to find and mentor new maintainers is so disappointing.
Re: Changing how we develop Ladybird
#68Re: Changing how we develop Ladybird
#69While I understand the motivation for this change, I have to highlight something: GitHub's slogan 'social coding' is becoming more and more true these days. Now opensource will become a thing that only "influential" people can contribute to. We're back to nepotism, not meritocracy. Down hill we go.
Or people can just start their own projects instead of working on someone else's. Many projects instead of potential large points of failure.
Re: Changing how we develop Ladybird
#70We need stricter verifications / credentials behind GitHub accounts and PRs. And this we should have had already before AI.
How does that help? People gladly post slop PRs under their real names.
If you see a PR and the guy is verified, you can check his name, his linkedin and where he works, at least there is some accountability if he introduces malicious code.
If the goal is to reduce slop, define slop. As a maintainer of a project you should be able to tell if something is slop.
If you don't have time to read PRs (which is the real issue here) that's fine too.
My guess is they want to reduce the amount of PRs, and ensure that the quality of the PRs passes an extremely high bar.