Dessalines: :bugs-no:
I'm sure his ideas have advantages and the lemmy devs can be frustrating to work with but he literally showed up yesterday spamming the matrix chat and now this
[sic]
Hackernews and its consequences
I have no interest in writing Go.
okay then fuck off!!!!! thanks for playin dipshut!
Yeah I'm getting annoyed at all the people posting all their great ideas/suggestions to Lemmy and getting up in Dessalines/nutomic's replies about them.
Like yeah, it's two guys busting ass and trying to keep shit afloat. They've had like half these suggestions in the backlog for a couple years. Contributions fucking welcome, and if you want to contribute ideas/suggestions do it in the GitHub instead of expecting them to read everyone's posts.
Love the "you have to either admit I'm right or acknowledge that you're stupid" approach this nerd has to conflict
seems to be slowly coming around in the more recent posts
dessalines again being a good living example of :sankara-shining: we must never stop explaining
Typical good intentioned contributed couldn't handle that there were also good reasons for not accepting their contributions.
Fast CI is good. Locally runnable CI is basically a necessity if you want keep your CI well maintained. Lemmy's CI sounds like an absolute nightmare to change. If you can't run it locally then you have to commit and push your changes and keep refreshing a website to see if it works. If this takes +40min then you literally can't hack on it for any extended period of time unless you have deep brain understanding of the CI system which basically no one does.
Yeah. The thing was he asked about doing this in the matrix before he put the PR together and was essentially given an unequivocal "no" at that time as well
I don't think the CI is 100% necessary for local development and I think you can run woodpecker locally if you wanted, but yeah the runtimes are dog slow and there's lots of room for improvement, this guy is just being a jerk about it
Local CI only for CI development. You keep your CI simple and use docker and some sort of build scripts like gnu make to do local development.
Never heard of woodpecker though. New thing to read up on.
Edit from woodpecker docs:
Plugins are Docker images with your script as an entrypoint
NOW THIS IS PODRACING
You can build lemmy just fine locally. I think maybe it just doesn't run the test suite unless you use the CI? So I guess the real question is do you need the test suite in the loop for every build. I can see where it'd be nice but I'm barely even a dev so idk
Test suites should be runnable locally. It encourages people to write tests and check then before submitting a pr. But it makes sense for running it in CI to be first priority on an open source project.
Sounds like he's just salty he did work and they won't use it. Could have been solved by simply asking before if they'd be open to changing their CI. At the end of the day the Lemmy devs going to be the ones using and most likely maintaining it so what they're comfortable using is what goes.
Companies do similar shit all the time where they develop something for their specific use case and then fight tooth and nail to upstream it so they don't have to be the ones maintaining it.
Yeah the funny thing is he asked in the matrix chat about GitHub actions and was specifically told "no we don't wanna use Microsoft" before going and putting that PR together, so he doesn't even get that excuse, such as it is
Ah nevermind. Just another programmer with a god complex I guess. Many such cases
If he had better communication skills and made any attempt to tailor his PR to the project's wishes not his own preferred tools it could've been fine and maybe even been used. He's right about much of what he said but he is being inflexible and a dick about the specifics.
Could have been solved by simply asking before
True but I can definitely relate to the hyper focus on building something on a whim and then hope it's useful later approach. Trick is to post the code like it's a pack of crisps "oh does anyone want this? I'm not gonna eat it"
Do organizations like Apache mitigate that? I would assume it helps to have standard ways of contributing, bylaws, documentation, appointed positions, etc. so that there's always a process.
For example, the OpenJDK project (Java) has instructions on how to become a maintainer (someone who can commit changes and so on). The instructions are basically to do some small code changes and work your way up. And they don't really create any illusion that just anyone can waltz in with a big change (you can't even create a bug or feature in the bug tracker, you need to submit your first changes via the mailing list).
I hadn't considered but there is some possibility someone would try to sneak some shit in in a large PR like this
It's only 500 lines
edit: just read all 500 lines and is all pretty basic ci stuff. Just setting up a postgres container, attaching it to Lemmy, and running the tests.
The only big deletion is his removal of woodpecker, which is dumb because that system is maintained by someone else while his homebrew would have to be maintained by the Lemmy team.
shouldn't you be equally wary about hosting the [project] on GitHub as well?
not at all dude. Sucks if you lose issues I guess but a git repository is a git repository.
The problem with non-corporate-supported open source is everyone doing it is either a loser/high schooler with nothing else to do or WEIRD. I can't bear to code outside of work besides some little openSCAD things and that's barely programming.
I love that they ran with that and went "funny that you mention it we actually want to switch away from GitHub too and we have x and y backups"
Honestly the Lemmy devs are saints for putting up with that guy. And I don't think he's even that bad, my guess is that he doesn't have much experience on a software team, just on his own projects. Once he works more with others, he'll figure out that you can't just drop in and get everybody to change to your preferred stack. Then he'll probably be a good open source contributor.
Two different minds, guy is going about it the complete wrong way certainly. Not sure why they went with a CI tool without artifact caching though. If the builds are reproducible, I'm not super familiar but I think Rust at least should be and then the frontend is just JavaScript stuff so that should be too, I'd just take advantage of the faster CI process and do whatever (probably very) small changes are needed in the future to keep the two in sync.
Yeah. I'm a little bit conflicted but the guy is enough of a douchenozzle that it's like no, nobody is going to bow down to your powerful logic brain man, fuck off
He's in the matrix saying "oh its just a proof of concept I wasn't asking them to merge/use it now"
communication skills on redditors; :not-good:
Rust compilation units are much larger than those in C / C++. A C compilation unit is an individual source file. All the source files get compiled, then this is followed by a linking stage. You can edit one C source file, recompile that single source file, then re-link against all the other pre-compiled objects. In Rust, the entire module (library or binary) must be compiled as one unit. There is no distinction between headers and source files, so when you edit a source file, it impacts everything else which imports from it. It is much more convenient to program IMO, but the compilation process is for small changes is notably slower.
Hopefully they're not re-compiling all the dependencies every time though.
Continuous Integration (CI) in today's world essentially means every so often (per code commit, or several times a day, or daily, or whatever other frequency you like) the computer will automatically build the code and run a test suite on it if tests are written, while all the new code gets merged into the main branch. It has multiple advantages, like being able to catch breakage ASAP, and ensuring you don't introduce regressions or performance problems that you don't catch for a long time.
In short, it's a way for developers to not have to waste their time making sure everything works, because the system in place makes sure it works for them. That's especially handy in a team setting.
