4 ms·

Instead, currently, all packages become lint-unclean, all maintainers need to read up on what the new thing is, how it might break, whether/how it affects them,

by chubot 8y ago

Instead, currently, all packages become lint-unclean, all maintainers need to read up on what the new thing is, how it might break, whether/how it affects them, manually run some tests, and finally decide to opt in. This causes a lot of overhead and manually executed mechanical changes across packages. I always wondered if Debian/Ubuntu could benefit from a "monorepo". It seems to work for other distributions, e.g. Alpine Linux and Homebrew. https://github.com/alpinelinux/aports/tree/master/main https://github.com/alpinelinux/aports/tree/master/main Right now every Debian package lives in a separate repo, or it doesn't even have to live in a repo at all AFAIK. I think Debian has the most packages because their process is very loose and decoupled (as well as it being one of the oldest distros). But having tighter integration does help move things forward faster.

JoshTriplett 8y ago
I don't think it necessarily needs a monorepo, but having every package on Salsa (Debian's GitLab installation) would help.
- thiscommuni 8y ago
  thiscomm ent juat for this comment this account password is cator but they needed 8 lettera so I added a F U C K at the tail Like country Joe at Woodstock live added It on the Head with trhee hundred thousans you fuckers out there eehhha! woodstock!!! whatever forgot what I was going to say againnn thata rhw problem with explanatioua offtopics going and with iphone fckn5 fckn typing shit (sont call it a aystem nor a keyboard fuck) anaway... id is a public open aource repo or repos or whatever you put it all in neaby place for easiness and selfcompletion righ but a private business is fucked anyway, even separaring all in diferent repos like the ancient naval fighting weapon named greek fire anyfuckingway they see everyfuckingahit and anyshit ans anyfuckingthing you fucking programm my friend So qhats the fuxking point of givimg fuxking free away fucking texhnology ??? if you know what I fucking mean righ... thanks
- andrewharvey 8y ago
  The move to GitLab was a glimmer of hope that one day I'll be able to help contribute to the project which I'm a heavy user. I wish they went all in and used GitLab Issues for bugs and GitLab CI/CD to auto-build packages for both validation and pushing new packages into the Debian repositories.
  - h1d 8y ago
    I'm not following the situation but what's stopping them from improving their packaging system, except for being complicated?
    - genghizkhan 8y ago
      If the systemd discussion has taught me anything about Debian governance, getting everyone to agree is going to be a pain. Far easier to let it be.
      - debiandev 8y ago
        Loud minorities and trolls on public mailing lists are not representative of the community of DDs and DMs.
        JoshTriplett 8y ago
        No, but they're representative of the decision process. "Should we do A or B" results in people popping up supporting A, B, C, D, and E, and the decision tends to be "let's support them all". And as the original article we're commenting on discusses, that "support" comes in the form of "hey package maintainers, here's what you have to deal with".
        debiandev 8y ago
        This is a misunderstanding of how Debian works.
samdoshi 8y ago
Nix / NixOS[1], and Gentoo[2] also use monorepos with some provision for overlays. 1: https://github.com/NixOS/nixpkgs https://github.com/NixOS/nixpkgs 2: https://github.com/gentoo/gentoo https://github.com/gentoo/gentoo
rleigh 8y ago
Likewise for the BSD ports. There are advantages to both ways. However, a single repository permits changes to multiple packages in a single change. In Debian, simple transitions which affect multiple packages can take months or even years to fully propagate through the entire system. Not due to technical difficulty, but the logistics of coordinating the change. Debian's approach made sense at the time. Developers who were widely distributed, communicating sporadically using dial-up internet connections, needed to be able to work independently and changes which had wide-ranging effects needed discussion and coordination. Nowadays, that can happen on a single merge request on GitLab. Homebrew can do such changes in a single pull request.
- wbl 8y ago
  We've had CVS for years.
  - mruts 8y ago
    And CVS is clearly the cutting edge of source control.
  - rleigh 8y ago
    True, but it's not just the version control that's the important part. It's the infrastructure around it. Today, when you submit e.g. a homebrew PR, it gets comprehensively tested by CI builds, including rebuilding and testing all reverse dependencies on every supported platform version. The BSD ports changes are backed by poudriere builds of the entire collection, again on multiple versions. Services like GitHub and GitLab allow one to hook in all sorts of stuff and greatly improve the ease of submission of large- and small-scale changes, as well as making thorough testing and review both possible and accessible. Older projects are stuck with older entrenched tools and infrastructure, and haven't taken advantage to newer ways of doing things which newer projects have been able to adopt wholesale. The Debian tooling and infrastructure is certainly dated, but it's also of extremely high quality and very robust.
tgsovlerkhgsel 8y ago
Wouldn't even need to be a monorepo. As a first step, ensuring that all packages use the same system, e.g. git, and one authoritative repository (e.g. a debian-maintained gitlab) would be a great start.
- sytse 8y ago
  https://salsa.debian.org/ https://salsa.debian.org/ is a Debian maintained GitLab
tbodt 8y ago
Reading between the lines I see "wouldn't it be nice if Debian's repository was like Google's repository"
vbernat 8y ago
A mono repo is not needed. Some teams are able to push changes to all the packages of the team without it and without much effort (for example, the Debian Python Modules Team does that quite often). It's more a social problem: all packages should be maintained in the same way and people should be allowed to do global changes. This is true for some teams, not for some others.
bregma 8y ago
Yes, a monorepo for all software with a single soviet to oversee it with a good five-year plan for rollout. We have plenty of historic examples of such centralized control.

by chubot 8y ago

JoshTriplett 8y ago

I don't think it necessarily needs a monorepo, but having every package on Salsa (Debian's GitLab installation) would help.

thiscommuni 8y ago
thiscomm ent juat for this comment this account password is cator but they needed 8 lettera so I added a F U C K at the tail Like country Joe at Woodstock live added It on the Head with trhee hundred thousans you fuckers out there eehhha! woodstock!!! whatever forgot what I was going to say againnn thata rhw problem with explanatioua offtopics going and with iphone fckn5 fckn typing shit (sont call it a aystem nor a keyboard fuck) anaway... id is a public open aource repo or repos or whatever you put it all in neaby place for easiness and selfcompletion righ but a private business is fucked anyway, even separaring all in diferent repos like the ancient naval fighting weapon named greek fire anyfuckingway they see everyfuckingahit and anyshit ans anyfuckingthing you fucking programm my friend So qhats the fuxking point of givimg fuxking free away fucking texhnology ??? if you know what I fucking mean righ... thanks
andrewharvey 8y ago
The move to GitLab was a glimmer of hope that one day I'll be able to help contribute to the project which I'm a heavy user. I wish they went all in and used GitLab Issues for bugs and GitLab CI/CD to auto-build packages for both validation and pushing new packages into the Debian repositories.
- h1d 8y ago
  I'm not following the situation but what's stopping them from improving their packaging system, except for being complicated?
  - genghizkhan 8y ago
    If the systemd discussion has taught me anything about Debian governance, getting everyone to agree is going to be a pain. Far easier to let it be.
    - debiandev 8y ago
      Loud minorities and trolls on public mailing lists are not representative of the community of DDs and DMs.
      - JoshTriplett 8y ago
        No, but they're representative of the decision process. "Should we do A or B" results in people popping up supporting A, B, C, D, and E, and the decision tends to be "let's support them all". And as the original article we're commenting on discusses, that "support" comes in the form of "hey package maintainers, here's what you have to deal with".
        debiandev 8y ago
        This is a misunderstanding of how Debian works.

samdoshi 8y ago

Nix / NixOS[1], and Gentoo[2] also use monorepos with some provision for overlays. 1: https://github.com/NixOS/nixpkgs https://github.com/NixOS/nixpkgs 2: https://github.com/gentoo/gentoo https://github.com/gentoo/gentoo

rleigh 8y ago

Likewise for the BSD ports. There are advantages to both ways. However, a single repository permits changes to multiple packages in a single change. In Debian, simple transitions which affect multiple packages can take months or even years to fully propagate through the entire system. Not due to technical difficulty, but the logistics of coordinating the change. Debian's approach made sense at the time. Developers who were widely distributed, communicating sporadically using dial-up internet connections, needed to be able to work independently and changes which had wide-ranging effects needed discussion and coordination. Nowadays, that can happen on a single merge request on GitLab. Homebrew can do such changes in a single pull request.

wbl 8y ago
We've had CVS for years.
- mruts 8y ago
  And CVS is clearly the cutting edge of source control.
- rleigh 8y ago
  True, but it's not just the version control that's the important part. It's the infrastructure around it. Today, when you submit e.g. a homebrew PR, it gets comprehensively tested by CI builds, including rebuilding and testing all reverse dependencies on every supported platform version. The BSD ports changes are backed by poudriere builds of the entire collection, again on multiple versions. Services like GitHub and GitLab allow one to hook in all sorts of stuff and greatly improve the ease of submission of large- and small-scale changes, as well as making thorough testing and review both possible and accessible. Older projects are stuck with older entrenched tools and infrastructure, and haven't taken advantage to newer ways of doing things which newer projects have been able to adopt wholesale. The Debian tooling and infrastructure is certainly dated, but it's also of extremely high quality and very robust.

tgsovlerkhgsel 8y ago

Wouldn't even need to be a monorepo. As a first step, ensuring that all packages use the same system, e.g. git, and one authoritative repository (e.g. a debian-maintained gitlab) would be a great start.

sytse 8y ago
https://salsa.debian.org/ https://salsa.debian.org/ is a Debian maintained GitLab

tbodt 8y ago

Reading between the lines I see "wouldn't it be nice if Debian's repository was like Google's repository"

vbernat 8y ago

A mono repo is not needed. Some teams are able to push changes to all the packages of the team without it and without much effort (for example, the Debian Python Modules Team does that quite often). It's more a social problem: all packages should be maintained in the same way and people should be allowed to do global changes. This is true for some teams, not for some others.

bregma 8y ago

Yes, a monorepo for all software with a single soviet to oversee it with a good five-year plan for rollout. We have plenty of historic examples of such centralized control.