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

41–50 of 157 posts

Re: Debian Git Monorepo

#41

Post by Cu3PO42 »

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 isn't wrong, but somewhat orthogonal. Yes, I "published" it on our package registry, but it wasn't public. Access was still scoped to the team developing the application I was speaking about.

Re: Debian Git Monorepo

#42

Post by XorNot »

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.

You should check out dgit[1] which pretty much does exactly what you're looking for. It's an excellent way (with a little bit of pbuilder scripting) to patch Debian packages in place with sensible version numbering.

[1] https://wiki.debian.org/DgitFAQ

Re: Debian Git Monorepo

#43

Post by sjducb »

Repulsion9513 wrote: post #27
The_Colonel wrote: post #24

Earlier quoted context omitted.

This is exactly the friction/overhead the other person means and what monorepo works around. (but also keep in mind this is an internal library for likely a couple of internal apps, supporting BC for 2 years is in most cases unwarranted)

Monorepo doesn't "work around" it, it means you have to support everything (including migrating/BC) on the current version, instead of having to support old stuff on the old version.

You can see where the “library” is used. Often the bit you want to change is only used by your project so you can change it freely. If someone else is using it you know who to talk to about changing it.

Re: Debian Git Monorepo

#44

Post by thegeekpirate »

paulgdp wrote: post #9
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?

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 only the latter you have to worry about ;)

Re: Debian Git Monorepo

#45

Post by Double_a_92 »

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 much nicer to have everything you could ever need in one place, instead of having to know what is in what repo. Especially when you have versions that need to correspond in the different repos...

Re: Debian Git Monorepo

#46

Post by ninjin »

daghamm wrote: post #34
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 think of the openbsd model? It has a mono repo for the os and a ports repo for everything else (I think)

Yes and no. OpenBSD uses four primary repositories: ports, src, www, and xenocara. CVS change announcements are merged for all but ports and go out on two mailing lists: source-changes@ and ports-changes@. Patches are discussed on tech@ and ports@ (sometimes also on bugs@). Also, some key software such as OpenSSH, OpenSMTPD, etc. is developed out-of-tree and lifted into the main train when appropriate. I am not a developer, but I do follow development somewhat closely.

Re: Debian Git Monorepo

#47

Post by gtirloni »

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 to handle and use

Quite the opposite, IMHO. Juggling dozens of PRs across many repos for a simple change is the definition of a nightmare.

Re: Debian Git Monorepo

#49

Post by codesnik »

dijit wrote: post #2

I was always surprised that Perforce didn't have anything for open source, Git is basically eating their lunch because monorepo's suck so much with git; so people do things in a more fragmented and git-friendly way. Not that I really want to see a proprietary product succeed, but it's somewhat surprising that: A) We don't have anything better B) Perforce isn't trying to gain adoption by giving its software for free t…

from what I've heard, git become much friendlier with monorepos in recent years because of microsoft involvement. Windows repo, pretty sizeable, is now using git, and it supposedly works even without strange things like vfs for git.
Post reply on HN