Live data from Hacker News

FFmpeg moves to Forgejo

code.ffmpeg.org

241–250 of 374 posts

Re: FFmpeg moves to Forgejo

#241
post #233

It's interesting (and a little sad) how all git "forges" (for want of a better word) converge on the same layout. An alphabetical list of files, when they were last modified, and an expanded readme file. IMO a list of recent commits would be more useful as a landing page, or maybe even just the readme. When checking out a new project, I'm interested in what it does, not in its folder structure when its LICENSE.md was…

I agree. My ideal forge would be SourceHut but with GitHub style PR workflow (as opposed to email).

Re: FFmpeg moves to Forgejo

#242
post #233

It's interesting (and a little sad) how all git "forges" (for want of a better word) converge on the same layout. An alphabetical list of files, when they were last modified, and an expanded readme file. IMO a list of recent commits would be more useful as a landing page, or maybe even just the readme. When checking out a new project, I'm interested in what it does, not in its folder structure when its LICENSE.md was…

Pick one of the open source forges that takes MRs (not using the giant's terminology, hardly ever calling git pull either...) and contribute your ideas.

That said, it's a bit like QWERTY. Maybe a bit weird, but it eases quick orientation on a new keyboard or repo if everyone uses the same layout.

Re: FFmpeg moves to Forgejo

#243

It's cool to see such an impactful project choose sovereignty. I hope more projects follow their example. If you're a backbone-of-the-internet project like FFmpeg is, living on GitHub seems horrible. You will be subjected to thousands of low quality pull requests and issues from people searching for typos to fix, adding a line of white space for a contrived reason, or similar nonsense changes. Just so they can put "F…

I have to say you're exaggerating, ignoring prs isn't such a chore.

Re: FFmpeg moves to Forgejo

#244

Earlier quoted context omitted.

Rejecting useless or white space-only PRs is quick and easy. It’s not as big of a problem as you’re suggesting. I’ve gone through a few projects and updated the documentation as I explored the codebase. Reception ranges from thankful to people scorning me for attempting to make contributions that weren’t code changes. It’s frustrating when maintainers are more interested in keeping people out than in considering actu…

It’s all in the approach: start with a “thank you for the project”, and a “hope you don’t mind but I’ve corrected a few typos” and nobody will shout you down. Only go with a blank PR description and it’ll come across as arrogant and spammy.

There are people hunting double spaces or typos in code? For what contributor credits?

Re: FFmpeg moves to Forgejo

#245
post #155

Earlier quoted context omitted.

[flagged]

The bit about the name seems to be a complete hallucination / tokenization error. The project's docs say: "Forgejo (pronounced /forˈd͡ʒe.jo/ (hear an audio sample)) is inspired by forĝejo, the Esperanto word for forge." I would expect the rest of the AI summary to be similarly unreliable / hallucinated—I compared the test directories for both projects and they both seemed to have about the same amount of activity.

Thank You for pointing this out. Although I am not entirely why my comment was downvoted into oblivion .

Re: FFmpeg moves to Forgejo

#246

Earlier quoted context omitted.

Yes, Issue with GitLab is their "Enterprise" maximalist feature set. Seems like they want to be the solution for the entire SDLC for every conceivable team. I remember thinking a decade ago "wow these guys are biting off a lot to chew, maybe in a decade they'll be able to tackle all these things in a comprehensive way" and my opinion now is they are still probably a decade out. I appreciate their ambition and wish th…

A decade out? They do Code, Artifacts and CI basically that all works. What missing sdlc features are going to take them a decade to write?

It's not about features or if they work it's about the conceptual load presented to the user by the quality of how those features are integrated, how much configuration they require to do only what you want them to, ask of you only what you want them to, and no more.

When I'm interacting with a maximalist system designed to be everything to everyone, I still only want to have to worry about the things I care about.

They do seem to hold this as a value, but it's secondary to the maximalism.

Re: FFmpeg moves to Forgejo

#247
post #152

It's cool to see such an impactful project choose sovereignty. I hope more projects follow their example. If you're a backbone-of-the-internet project like FFmpeg is, living on GitHub seems horrible. You will be subjected to thousands of low quality pull requests and issues from people searching for typos to fix, adding a line of white space for a contrived reason, or similar nonsense changes. Just so they can put "F…

Typos may be quite impactful, don't discount them. My only contribution to node-grpc fixed missing quotes, but only because that produced real crashes.

In my previous work we were strict about typos, whitespace and general consistency in reviews. And even fixed them later if they slipped through. I found it a bit ridicolous a times.

In my current company nobody cares. It can be seen in the whole code quality. Full of smaller and bigger bugs as well as horrible hacks. It can be seen whether coders look twice or more at their own stuff before putting it to review or not, just trying to avoid ridicolous comments. It's a whole attitude. I write good code in a messy source base is unlikely to work in practice.

That said, I have submitted cleanup commits to open source projects only in the same MR with a real code change I wanted to make and only in vincinity of that change.

Re: FFmpeg moves to Forgejo

#248

The comments on this page are a complete cesspool. A full third of them complaining about the anti-bot protection mascot (yes, it's a cartoon character; get over it), others splitting the finest of hairs over software development groups and company politics, and more. Self-hosting is generally good, well done to FFmpeg. Many large projects self-host, and my own ex-company has physical servers in the city we work at t…

Cesspool is pretty strong language, dawg. They're critical and opinionated, sure, but so are your own comments. None of it is empirical, just personal opinion. I personally couldn't give a rat's ass how it's hosted. Still uses a protocol there's open source clients for? Cool. Not that I have pulled the ffmpeg source more than once in my life (which I suspect's the same for 99% of the people here). I'll continue to ge…

> Cesspool is pretty strong language, dawg. They're critical and opinionated, sure,

There's nothing wrong about critical and opinionated but respectful, but the comments that are now flagged, and some of the downvoted ones are very low quality, not just critical and opinionated.

Re: FFmpeg moves to Forgejo

#250

Earlier quoted context omitted.

Yes, Issue with GitLab is their "Enterprise" maximalist feature set. Seems like they want to be the solution for the entire SDLC for every conceivable team. I remember thinking a decade ago "wow these guys are biting off a lot to chew, maybe in a decade they'll be able to tackle all these things in a comprehensive way" and my opinion now is they are still probably a decade out. I appreciate their ambition and wish th…

A decade out? They do Code, Artifacts and CI basically that all works. What missing sdlc features are going to take them a decade to write?

In fairness, I've not used GL in a couple of years, but before that I used it a lot, and it all worked, but it never worked very well. Issue organisation was painful, and there was always some new trick that made it slightly easier but never enough (boards, nested workspaces, sprint tools, etc). CI had about a hundred different ways of doing the same thing, because every so often the GL devs would realise their current system wasn't quite general or powerful enough, and add a new way of defining DAGs, or a new way of sharing jobs, or a new way of managing environments. You didn't need to switch, but trying to figure out how all these different approaches interacted by reading the docs was a nightmare.

In general, the documentation and UI were painful, and trying to figure out how to do something usually took me to a GL issue that would describe my problem but either be closed (with little indication of whether the feature was added or what form it had taken in the end), or open with no discussion apart from a bunch of comments from a community manager saying "a bronze supporter said that this is a blocker for them". Trying to figure out where features or configuration lived in the UI was also like pulling teeth, especially with GL's love of icons to explain what everything is.

So it's not that the features are missing, it's that they're all half-baked, and it would take Gitlab another ten years to polish them off and round them out.

Post reply on HN