Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Changing how we develop Ladybird

ladybird.org

Post reply on HN
Print view View original

301–310 of 602 posts

Re: Changing how we develop Ladybird

#301

Post by jeltz »

jeremyjh wrote: post #226
nh2 wrote: post #63

> There will not be a [..] process for submitting patches by [any] means > 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…

> 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. You state these things as if they are facts, but they are completely contrary to the liv…

Yeah, I am employed by an open source company (to be clear not open core) and most of the external code contributions we get are a net cost for us. It takes more time to review than it would have taken for our team to code and review.

The real value we get from being open source is high quality bug reports and trust from our customers, not the external contributions. The only reason we welcome external contributors is marketing and generally being welcoming. If LLMs make this cost even higher for us then we might have to stop accepting external PRs.

Re: Changing how we develop Ladybird

#302

Post by skydhash »

torben-friis wrote: post #118
Fraterkes wrote: post #66

I've been looking a lot at Godot (another big open source project) PRs lately, and there's been kind of a surge of wholy ai-generated PRs (both code and description). This is agains project-policy, so people creating these PRs usually get mildly told off. What's surprising is that while many submitters take that fairly well, some people get really indignant, essentially calling the maintainers ungrateful. It's kinda…

There is certainly a certain... entitlement? (It's not the perfect word, but I fail to find a proper term) from some of the vibe crowd. Like an attachment to the output and refusal to accept that most of the work was not theirs. It is seen in the way they approach contributions but also in regular language. I created X, insistence that their 'curation' was very influencial to the output, difficulty to mention LLM con…

> It is surprisingly different to what I'm used to from senior devs, which behave like they always suspect their own work is flawed and half assed

I never trust my own code. And one of the motivations of trying to be fluent with my editor, is to be able to quickly look at it when a bug is reported. I also don’t trust another person with their description of their code. Any surprise, and I’m looking at the source if it’s a available.

Re: Changing how we develop Ladybird

#303

Post by mistersquid »

shinryuu wrote: post #286
thedevilslawyer wrote: post #276

Earlier quoted context omitted.

I sense your comment as saying: "AI is hype, and reality will catch-up.". But the simple fact is there's massive evidence that in skilled hands 10x or 100x engineers are possible. We're seeing evidence of it across major open source project as well. And definitely behind closed doors across companies. Reality will catch-up with that too, once the other smoke clears.

100x is achieving something in two days, what it took an entire year before. I strongly doubt that is happening for an individual.

> 100x is achieving something in two days, what it took an entire year before.

Reduce your scale: "100x achieves in 1 hour what used to take 1 week."

One year of work could require levels of complexity and human judgement that can't be accelerated past a certain point.

1 week of work can be reduced to an hour and some change.

Re: Changing how we develop Ladybird

#304

Post by Kudos »

shinryuu wrote: post #286
thedevilslawyer wrote: post #276

Earlier quoted context omitted.

I sense your comment as saying: "AI is hype, and reality will catch-up.". But the simple fact is there's massive evidence that in skilled hands 10x or 100x engineers are possible. We're seeing evidence of it across major open source project as well. And definitely behind closed doors across companies. Reality will catch-up with that too, once the other smoke clears.

100x is achieving something in two days, what it took an entire year before. I strongly doubt that is happening for an individual.

The baseline engineer in that case must really be something incompetent.

Re: Changing how we develop Ladybird

#305

Post by grebc »

creesch wrote: post #239
smartmic wrote: post #220

Earlier quoted context omitted.

The path is not closed; it must be earned through trust. It has always been this way. Also, note that "pull requests" are a GitHub invention; the concept is not native to Git or most other SCM systems. Before, you would have to submit your patch by email. It would be reviewed by the "maintainer" (or BDFL), who would then accept or reject it. If your contributions are accepted several times, you may be able to earn th…

In this case they seem to be firmly closing the path though > There will not be a separate process for submitting patches by other means. We do not want to create a shadow contribution system through issues, comments, email, or forks. External code can of course exist under the terms of the license, but we will not treat forks or patch dumps as a review queue for upstream Ladybird. This does raise the question on how…

They don’t even have an alpha product yet. This used to be called vaporware but I’ll give them the benefit of the doubt that something will come in the future and they’re just focusing on fixing their own crappy code.

Re: Changing how we develop Ladybird

#306

Post by leoc »

dwaite wrote: post #212
leoc wrote: post #166

Earlier quoted context omitted.

That's not really right, though the license is still Open Source compliant. Linux was practising an open, patches-welcome developement style before the forges existed, on its mailing list. This did indeed contrast with how eg. the FSF was running its projects, though even in those the door wasn't shut as hard on people wanting to contribute as Ladybird's now is, I think. Then Eric Raymond wrote "The Cathedral and the…

"The Cathedral and Bazaar" is orthogonal to open source. Its argument is that open source is most valuable when paired with the bazaar model, not that the cathedral model cannot be considered open. The open source definition was created in that mind. It does not state or imply open development or a community are requirements.

CatB and Open Source aren't coaxial, but there wasn't a very clean separation between them either: https://www.free-soft.org/literature/papers/esr/cathedral-ba... https://web.archive.org/web/20021001164015/http://www.openso... . "[T]he same pragmatic, business-case grounds that motivated Netscape" was CatB. Even now OSI doesn't emphasise any separation: https://opensource.org/about . You are correct: the Open Source Definition does not mandate an open development model. However that's probably at least in a small part because, well, how would one craft a legal requirement for open development in a software license that wasn't either unenforceable or very burdensome and abusable? It's also quite definitely because the expectation was that forks and/or the threat of forks would in practice enforce a certain level of open development on OSD-compatibly-licensed software: this was in fact what ended up happening to GCC at least once https://en.wikipedia.org/wiki/GNU_Compiler_Collection#EGCS_f... . If software projects all largely go the way Ladybird is going now, and stay that way, then it's a crushing (though not total) defeat for what the Open Source movement promoted and what it hoped to achieve; but sure, to be clear, Ladybird remains OSD-compliant. (Not total because at least the source remains available, without paying or signing anything, for bug-hunting.)

Re: Changing how we develop Ladybird

#307

Post by koonsolo »

thedevilslawyer wrote: post #276
torben-friis wrote: post #251

Earlier quoted context omitted.

>But all now seems like a transition phase. Transition to f-ing what though? It feels like being in the middle of a tornado. But I think it helps to turn off screens, sit in a desk, and calmly remember first principles and consider them slowly. Quoting obama, "reality has a way of catching up with you". I see a lot of talk, but iOS is not delivering a decade of features and fixes on each yearly release. Literally no…

I sense your comment as saying: "AI is hype, and reality will catch-up.". But the simple fact is there's massive evidence that in skilled hands 10x or 100x engineers are possible. We're seeing evidence of it across major open source project as well. And definitely behind closed doors across companies. Reality will catch-up with that too, once the other smoke clears.

Name a single project that has a 10x increase. I mean real production ready code, not some single person hobby project.

Re: Changing how we develop Ladybird

#308

Post by torben-friis »

thedevilslawyer wrote: post #276
torben-friis wrote: post #251

Earlier quoted context omitted.

>But all now seems like a transition phase. Transition to f-ing what though? It feels like being in the middle of a tornado. But I think it helps to turn off screens, sit in a desk, and calmly remember first principles and consider them slowly. Quoting obama, "reality has a way of catching up with you". I see a lot of talk, but iOS is not delivering a decade of features and fixes on each yearly release. Literally no…

I sense your comment as saying: "AI is hype, and reality will catch-up.". But the simple fact is there's massive evidence that in skilled hands 10x or 100x engineers are possible. We're seeing evidence of it across major open source project as well. And definitely behind closed doors across companies. Reality will catch-up with that too, once the other smoke clears.

I'm not say it's pure hype. Not in the sense of previous hype waves like the metaverse or NFCs. It clearly has uses.

I do think it is hype as a killer of knowledge work. It can certainly remove a lot of friction in the kind of borderline mechanical work that you'd formerly outsource to the lowest priced denominator, serve as an idea bouncer, remove friction for bug tracing, etc.

Attempts to cross the next line ("no need for architecture discussions, ai plans", "no need to read the code, ai reviews", and so on), nope.

As someone else mentioned, 100x is a couple days producing the outcomes (remember, not output) of a year. Or for a team, iOS delivering in a single year ten times as many features as its entire previous existence. It's not something that doesn't get noticed.

Re: Changing how we develop Ladybird

#309

Post by Folcon »

torben-friis wrote: post #251
patates wrote: post #131

When AI first happened, I was afraid I was going to eventually lose my job. And while I've been lucky since, many did, and that hurt a lot. When people are losing something to automation, regardless of the economics of the situation, you cheer for the humans, or at least hope that society keeps being fair to those who are most affected. Now I see communities being affected. When you kill PRs, you not only kill the co…

>But all now seems like a transition phase. Transition to f-ing what though? It feels like being in the middle of a tornado. But I think it helps to turn off screens, sit in a desk, and calmly remember first principles and consider them slowly. Quoting obama, "reality has a way of catching up with you". I see a lot of talk, but iOS is not delivering a decade of features and fixes on each yearly release. Literally no…

I've been thinking a fair bit about what I'm seeing in terms of the output I experience

It's quite hard to quantify, but I think it's one shot nature really makes it hard to gauge it's capability

Friends have spoken of good days and bad coding days with me, and I find it odd nodding along, it's a strange new normal

At times it feels like we're just coding with one-armed bandits, trying to carefully line them up for a jackpot and just discarding and retrying if we don't hit

I think about some of the more complex systems I've built and I wonder how well we can build them like this

And over engineering, there seems to be over engineering everywhere, and yet, more fragility to our systems

It's all a little surreal

Re: Changing how we develop Ladybird

#310

Post by skydhash »

fc417fc802 wrote: post #235
smartmic wrote: post #220

Earlier quoted context omitted.

The path is not closed; it must be earned through trust. It has always been this way. Also, note that "pull requests" are a GitHub invention; the concept is not native to Git or most other SCM systems. Before, you would have to submit your patch by email. It would be reviewed by the "maintainer" (or BDFL), who would then accept or reject it. If your contributions are accepted several times, you may be able to earn th…

The amusing thing is that emailed patches and a listserv aren't actually all that different from github pull requests at the end of the day. In either case you're sending some code you wrote along to a group and asking them to look over it. The only real difference is the lack of a familiar web interface that's uniform across all projects and reduces friction to near zero, but emailing a patch hardly adds much fricti…

It’s really different because there’s no public signal between the email and the project itself. You can maybe search the log and see your patch, but there’s no central identity where you can brag about it. At most you can get a notice in a CONTRIBUTORS text file, or in the copyright header.
Post reply on HN