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

371–380 of 602 posts

Re: Changing how we develop Ladybird

#371

Post by nh2 »

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…

> Would you mind sharing a link to one of the open source project you've been maintaining and reviewing contributions on for years

Github is in my profile; I am nixpkgs committer for ~10 years (which is one of the most active projects on Github with 450000 merged PRs).

There is no way I could have possibly written and (pre-tested, to arrive at the eventual code submitted) all the code that I have reviewed.

From the other side, I have spent thousands of hours debugging and writing PRs to over 100 FOSS projects (e.g. glibc, busybox, util-linux, lz4, GHC and tens of Haskell packages, Jenkins, Chromium, GTK, Consul, OpenCV, Signal, many more).

Many of them are small or medium fixes ("drive-by fixes"), where you propose a PR, the owner reviews, says "great, thanks", and the bug gets fixed.

This is a fundamental workflow for open source work. The project gets free contributions and time investment outsourced to "the community" who fix its bugs, the developer-users/community get their problems fixed upstream, permanently.

This not possible for projects that don't have an easy way to submit code with low effort for both sides.

Accepting drive-by fixes is what clears up developer time and helps clear out the countless small issues in software.

If AI slop PRs are a problem, it seems better to establish clear rules and reject contributions that don't follow them with a single click, rather than banning developer contributions altogether. It seems to work acceptably for nixpkgs so far.

Re: Changing how we develop Ladybird

#372

Post by dcrazy »

Klonoar wrote: post #360
lucideer wrote: post #87

Earlier quoted context omitted.

The pre-ai reaction was also unwarranted: committing a massive amount of potentially unmaintainable handwritten code isn't a necessarily positive contribution and any decent engineer (or person tbh) would understand that & not expect gratitude, no matter how concerted their effort. In that context, I wouldn't expect an idiot (of which there has always been far too many in this industry) to change their behaviour in a…

> Fwiw, a non-technical employee in my workplace has begun submitting ai-generated prs to internal repos I maintain & they're of excellent quality, with review feedback graciously received & expediently addressed, so this isn't a matter of the idiots not being technical, it's an attitude problem. It is hard for me to imagine another engineering discipline that would be totally fine accepting work from those who don't…

Man, you must hate those handymen who put up YouTube videos showing how to do basic home maintenance. A truly class-conscious handyman would insist that the homeowner hire them to replace a light switch.

Re: Changing how we develop Ladybird

#373

Post by thegrim33 »

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…

"I was afraid" .. "hurt a lot" .. "I hope that" .. "that feels" .. "I'm conflicted" .. "I'm confused" .. "I'm afraid" .. "human touch" .. "I liked" .. "I feel so stupid".

Maybe, just maybe, you're not thinking rationally/logically about the situation and instead are mostly operating on emotion and feelings?

Re: Changing how we develop Ladybird

#374

Post by f17428d27584 »

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.

AI is turning 1x engineers into 0.3x engineers claiming to be 100x engineers.

Re: Changing how we develop Ladybird

#376

Post by js8 »

I am old enough to remember what happened to GCC. It was also developed by a closed group of maintainers, because "it couldn't work" as a bazaar-style development. Then EGCS fork happened and became more successful.

I think closing contributions (due) to AI will be looked at in a similar way. Forks open to AI will appear, and take over. And people will return to the open model. I think it needs more proliferation of AI coding and reviewing tools, so that AI contributions can be automatically independently reviewed for quality.

Re: Changing how we develop Ladybird

#377

Post by nunez »

pianopatrick wrote: post #352
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.

I can believe that the difference between the slowest programmer in the world and the fastest AI aided programmer in the world is now 100x in terms of lines of code output. Like I can imagine a programmer writing 250 lines of code per week by hand and I can imagine an AI powered person writing 25,000 lines of code per week.

But we spent decades as an industry trying to dispel of the notion that SLOC/KLOC does not matter.

I still believe that. 250 lines of tight code that solves a specific problem in a way that others can maintain will always be better than 25k lines of code that's difficult to review and consume (and, therefore, becoming a liability).

Re: Changing how we develop Ladybird

#378

Post by dcrazy »

Sharlin wrote: post #356
cpcallen wrote: post #42

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.

I’m never getting accustomed to the fact that there’s now an entire generation of coders who have never seen a world where "everything" is open-source and developed in the bazaar style (are people these days even aware of the metaphor or Raymond’s book?), a world in which the frigging Microsoft is a major OSS vendor and in charge of facilitating most of the open-source programming on the planet. Try explaining that t…

I’m confused, when has “everything” been a bazaar, and when did that cease to be?

Re: Changing how we develop Ladybird

#379

Post by abustamam »

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…

> iOS is not delivering a decade of features and fixes on each yearly release

This is insinuating that code was the bottleneck in the first place, or that every line of code is to build a new feature and not fixing existing bugs, or that apple didn't lay off enough engineers and reallocate resources to other departments to make up for the productivity boost.

I do think that companies with poor AI practices will eventually pay the piper in the form of technical debt or debilitating bugs. But let's not equate a productivity boost with a boost in releasing features, because there's plenty of business reasons to not release thousands of new features every year.

I agree with you on the rest of your points. Eventually the smoke will clear. What awaits to be seen is who is left standing when it does? I don't think I like the answer to that question.

Re: Changing how we develop Ladybird

#380

Post by cestith »

justin66 wrote: post #336
hypfer wrote: post #281

Earlier quoted context omitted.

Just uh.. build your own thing? Boom. Maintainer. Easy. Why would normal people even want to become an unpaid janitor for someone else's stuff?

> Why would normal people even want to become an unpaid janitor for someone else's stuff? Social validation. Or, to be slightly more generous, sort of a compulsory way to force someone more experienced to provide some mentorship, by compelling them to review your pull requests.

That’s the point here, though. The maintainers of Ladybird don’t want to be compelled to mentor people making throwaway contributions without a commitment to the project. It’s pretty frustrating to try to mentor an absentee mentee who isn’t actually ready to learn from you.
Post reply on HN