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

Debian Git Monorepo

blog.liw.fi

Post reply on HN
Print view View original

111–120 of 157 posts

Re: Debian Git Monorepo

#111

Post by JackSlateur »

Archelaos wrote: post #18
Cu3PO42 wrote: post #16

Earlier quoted context omitted.

There are real, tangible benefits to monorepos. And real, tangible downsides, too. Like everything else, it's a tradeoff. I'm sure people advocating for them have brought up some benefits. But in case they haven't, here's an example I recently encountered at work: for an application we are developing, we needed functionality X. We knew that we'd need X in other projects, too, so we made it a library. I published it t…

> Turns out, feature X wasn't as well understood as we thought it was and we are still changing things around all the time. If you publish something as a library for someone else, you should generally commit to supporting the public interface of that library as if it were a long-term support release. Exactly how long that should be depends on many factors, of course. But as a rule of thumb, I would recommend supporti…

This is exactly why monorepo is advised : you do not need to keep and maintain useless code for years. Instead, you can "git grep", then write and submit MR to quickly change all users.

I have never encounter this use case, tho

Re: Debian Git Monorepo

#113

Post by ownagefool »

bluGill wrote: post #86
ownagefool wrote: post #33

Earlier quoted context omitted.

It depends. If you drop a library for internal usage only and you want to change the contract, and the tests, library, and api are all in the same repo, you just change them in a single PR and that's done. This works because the single commit hash contains all information. It requires people put their code in the monorepo and hookup their tests, but assuming they do, you can build a reasonable degree of confidence on…

If the same problem doesn't exist in a monorepo in a different form then your project is not large enough to be in this discussion in the first place.

It's actually just trade offs that we should be able to have professional discussions about, otherwise your advocating for "always use a monorepo" unless your library is for public consumption.

The reality is, at some point, having repos that are hundreds of GB with hundreds of active PRs also has its own downsides that requires tooling and workflows to combat. Meanwhile, splitting it all up introduces integration problems.

It's definitely pick your poison, though specific requirements and circumstances make specific paths more or less potent.

Re: Debian Git Monorepo

#114

Post by zer00eyz »

jorvi wrote: post #52
xprn wrote: post #15

Earlier quoted context omitted.

I would actually think that monorepos suck with Github and others like that. Looking at the Linux kernel for example, that seems to me like a well executed monorepo outside of Github. From what I’ve heard and read, they specifically use Git and mailing lists instead of Github or others because Github wouldn’t work for what Linux is (aside from as a mirror). There might very well be some context I’m missing, but that’…

Github / Gitlab would work great and reduce friction for kernel contribution. The refusal to switch or provide the alternate path is mostly inertia.

I think you have a story eyed view of github... You might want to go read Linus own thoughts on the matter in the linux GitHub backup repo

Git is a tool built for a project of the kernels scope, scale and organization.

Github is a thin web interface over top of that, it cuts some corners here and there and gets opinionated about how you should manage code (pull requests).

Think of it this way: most git hub projects end up with a monotonic output... the kernel isnt that. Between the current version someone is using, the next version that is being developed and the older versions getting back ports there's a lot going on there. Much more than GitHub and a pull request would cover.

Re: Debian Git Monorepo

#115

Post by paulgdp »

viraptor wrote: post #63
paulgdp wrote: post #9

Earlier quoted context omitted.

NixOS uses a monorepo and I think everyone loves it. I love being able to easily grep through all the packages source code, and there's regularly PRs that harmonizes conventions across many packages. Nixpkgs doesn't include the packaged software source code, so it's a lot more practical than what Debian is doing. Creating a whole distribution often requires changes synchronized across many packages, so it really make…

Is nixpkgs really a monorepo as usually discussed? It's got packages, os modules, and some supporting scripts. Nix itself lives in a different place, so does the RFC planning, system artwork and a few other things. I would expect it all together to become a monorepo. > even though they have far fewer maintainers than Debian. Debian has ~1.5k contributors, nixpkgs lists >3.5k maintainers. (Although that list is not pr…

> Is nixpkgs really a monorepo as usually discussed? It's got packages, os modules, and some supporting scripts. Nix itself lives in a different place, so does the RFC planning, system artwork and a few other things. I would expect it all together to become a monorepo.

I think we can say it's a monorepo of packages in this context. Not everything from the Nix ecosystem is there. It could also bundle the website, wiki, doc etc but I don't think it matter too much.

> Debian has ~1.5k contributors, nixpkgs lists >3.5k maintainers. (Although that list is not pruned over time)

Thanks for the info, I heard that a long time ago and never checked myself! It's probably less as you say but still probably bigger than Debian.

I guess it makes sense because it's so much easier to contribute there than to Debian.

Re: Debian Git Monorepo

#116

Post by paulgdp »

thegeekpirate wrote: post #44
paulgdp wrote: post #9

Earlier quoted context omitted.

NixOS uses a monorepo and I think everyone loves it. I love being able to easily grep through all the packages source code, and there's regularly PRs that harmonizes conventions across many packages. Nixpkgs doesn't include the packaged software source code, so it's a lot more practical than what Debian is doing. Creating a whole distribution often requires changes synchronized across many packages, so it really make…

> I think it's important to add that they both have the biggest number of packaged software and the most up-to-date software of all distributions even though they have far fewer maintainers than Debian. Only because of https://www.reddit.com/r/NixOS/comments/zp95a2/comment/j5ko9... I also had plenty of issues with either packages not being available or not building, last I tried. At least with the AUR, it's generally…

Yeah, automation in Nixpkgs is crazy and goes far beyond any other distros (that I know of).

Why spend manual time when it can be automated?

Re: Debian Git Monorepo

#117

Post by kijin »

rkeene2 wrote: post #101
nolist_policy wrote: post #3

April fool aside, what I really want is a Debian git monorepo of submodules, where each submodule points to the upstream git repository.

What do you do about upstream projects that don't use Git ?

Most non-git projects have git mirrors these days, even if they're not official.

If upstream only releases tarballs, you can still untar them and create a commit for each version so you can easily compare them and merge any additional patches you need.

Re: Debian Git Monorepo

#118

Post by mhh__ »

jorvi wrote: post #52
xprn wrote: post #15

Earlier quoted context omitted.

I would actually think that monorepos suck with Github and others like that. Looking at the Linux kernel for example, that seems to me like a well executed monorepo outside of Github. From what I’ve heard and read, they specifically use Git and mailing lists instead of Github or others because Github wouldn’t work for what Linux is (aside from as a mirror). There might very well be some context I’m missing, but that’…

Github / Gitlab would work great and reduce friction for kernel contribution. The refusal to switch or provide the alternate path is mostly inertia.

Github and gitlab are both deeply, fundamentally, flawed because the unit of contribution is the branch rather than the commit.

Other than the UI not being very good, the code review experience is fundamentally hampered unless you enable squashing but that's a bit shit for different reasons.

On a purely UX level too the velocity of getting patches in is terrible. They're designed for ad-hoc open source contribution, not tight-loops of consistent work. People put up with the slowness because they know no difference but I promise its slow. You shouldn't need to go and get a coffee to wait for something to get merged and start coding again.

Re: Debian Git Monorepo

#119

Post by mhh__ »

G3rn0ti wrote: post #7

I know it‘s an April‘s fool. But I don’t get this recent trend of people arguing in favor of a monorepo (at my work place, too). It’s a nightmare to handle and use. What gives?

All of the fastest moving, easiest to contribute to, projects I've seen use monorepos or at least understand the basic principle that things that are released together and ship together (and probably depend on eachother) should be developed together)

So many of the supposed problems with monorepos (other than those of pure scaling) seem to basically boil down to "Dr Dr it hurts when I do this"

For example:

"What happens if two teams depend on different versions of the same internal library" - sounds like a reasonable concern no? No! This situation is fundamentally a disaster. On many levels.

Re: Debian Git Monorepo

#120

Post by mhh__ »

jmmv wrote: post #85
G3rn0ti wrote: post #7

I know it‘s an April‘s fool. But I don’t get this recent trend of people arguing in favor of a monorepo (at my work place, too). It’s a nightmare to handle and use. What gives?

It’s a nightmare only if you think of the monorepo as just throwing everything in one place (aka just a technical choice). A monorepo requires org changes. It requires staffing teams to handle processes and tooling for everyone else. (And it may require something else than git… but git will work OK for reasonably large ones anyway.) I wrote about some of this here: https://jmmv.dev/2023/08/costs-exposed-monorepo-mult…

FWIW "Monorepo requires people to work on it" is organisationally a bit of a cop out because everything requires this kind of work, its just a difference between each team dedicating some time to it in there little bubble (in which they do things slightly differently) versus doing it once at a larger scale centrally - this requires some investment in the form of salary but you would still spend this money in the first place, you just don't notice.

Boiling frogs and all that.

You'd also be surprised just how little work this actually is if you get it right, versus having to fix 50 different hacked up solutions across your company. It does put strain onto some tooling, but these days git seems to be fine well beyond kernel-scale - when you are this size you have "made it" anyway.

Post reply on HN