In reply to @delroth:delroth.net
do you think nlnet is properly aware of what they're getting out of SoN?

First of all to be fully transparent: I'm one of the facilitator for this year and thus have a financial tie to this project.

• In the end this is an NLnet project, not a NixOS foundation project, so their own pressure on setting their own objectives has to be taken into account.

that's not entirely true, since it's a project in colab with the nixos foundation and all the financial stuff and contracts are handled through the foundation.

In reply to @delroth:delroth.net
also, low efficiency isn't really debatable when you take groups of 5 participants and they end up having lower output (even after months of being in the program) than I'd expect a single nixpkgs committer would have in the same unit of time

In reply to @janik0:matrix.org

First of all to be fully transparent: I'm one of the facilitator for this year and thus have a financial tie to this project.

• In the end this is an NLnet project, not a NixOS foundation project, so their own pressure on setting their own objectives has to be taken into account.

that's not entirely true, since it's a project in colab with the nixos foundation and all the financial stuff and contracts are handled through the foundation.

In reply to @alejandrosame:matrix.org
So then why ngipkgs exists to begin with?

In reply to @alejandrosame:matrix.org
My comment of being debatable is more on the point of under which constraints are we talking about. Aka, I'm willing to talk specifics in detail to understand myself whenever I ran projects like this, but also I'm not a person with any decision making impact in any of this.

In reply to @alejandrosame:matrix.org
So then why ngipkgs exists to begin with?

Full disclosure: I was a SoN 2023 participant.

i think its pertinent to remember SoN is primarily about facilitating students. Low productivity, and low follow up aren't necessarily red flags even together imo. Lots of the packages in ngipkgs havent been packaged for nixpkgs precisely because of the difficulty in packaging them in nix, and that they landed in ngipkgs at all (flaws and all) by students speaks highly of the capabilities of mob programming.

In reply to @janik0:matrix.org
btw, most builds of ngipkgs just straight up fail and don't seem to be maintained while lots of the packages would not be mergeable to nixpkgs because of a low quality and in general things that would be catched in a nixpkgs review https://hydra.ngi0.nixos.org/jobset/ngipkgs/main

none of the packages has a vmtest or module from what I could tell in the ngipkgs repo which is also quiet sad, since vmtests are what (imho) differentiates good from very nix packages.

to be transparent, i participated as a group member in SON 2023 and also now a facilitator in 2024 and thus have a financial tie to the project.

i'd like to make two points from my perspective, both related to communication between NGI and nixpkgs efforts:

1. NGI funding packaging with nix is not funding of nixpkgs, but when they do there should be mutual expectations about finalizing that work
2. i think with those mutual expectations clarified, i fully agree probing how well the mob format performs is worth discussion.

first, i'd like to clarify some of the differences in scope between ngipkgs and nixpkgs: the packages under consideration, via the selection of NGI funding, are often not subject to the general OSS popularity marketplace and are often research-quality software.
(i'm a research engineer, this is not meant to be derogatory, there are simply different motivations involved in research efforts.)
while nixpkgs was encouraged as the end home for packages when possible, upstreaming required some level of indefinite commitment which can be a hard ask when members have no lasting personal vested interest in the NGI projects for themselves.
my 2023 SON group decided to collectively maintain our librecast work that currently exists upstreamed into nixpkgs, because we ended up finding it useful, for example.
some of the packages under ngipkgs's scope are not mature and ready for broad adoption in a high-quality well-maintained package set, however, that shouldn't be just some person's decision on a case-by-case basis, closing the conversation, which i think is kind of the problem here!

as an example of what i mean on the extreme research side, take this NGI project PR: https://github.com/ngi-nix/ngipkgs/pull/168
Libre-SOC is a large project in the libre hardware world, it requires many of its own bespoke tools to compile an ASIC.
the result/ is a (reproducible, cached, lengthy) build with an artifact not standard for packages or services distributed in nixpkgs (that I'm aware of.)
this involves tools based on python 2 (electrical engineers broadly do not care about supply chain security), lots of patching, and generally lack the polish of software intended for distribution.
in this case, the project had an initial pass of packaging by a SON 2021 participant and had since bitrotted, however from that starting work, it took me a relatively quick pass to revive that work to the current release and enable all of the verification suites.
that is to say, ending up in nixpkgs is not the be-all and end-all of the packaging work being funded; it is absolutely worth having as an independent repository with its own standards of inclusion (not unlike the NUR, i figure.)

to be transparent, i participated as a group member in SON 2023 and also now a facilitator in 2024 and thus have a financial tie to the project.

i'd like to make two points from my perspective, both related to communication between NGI and nixpkgs efforts:

1. NGI funding packaging with nix is not funding of nixpkgs, but when incentives align there should be mutual expectations about finalizing that work
2. i think with those mutual expectations clarified, i fully agree probing how well the mob format performs is worth discussion.

delroth I‘m confused about all this. Why don’t you ask me directly if you see issues? I’m online and responsive essentially every day. This can happen in public if you feel like it. There are no secrets around what’s happening, sometimes merely lack of communication.

It’s a bit much to unpack right now, and I’ll reply in detail when I’m back at a keyboard. But I reject the claim that I ever said anything even close to “everything is amazing”. Getting this stuff right is hard, I’m very critical about the outcomes, and I highly appreciate any feedback and tips on how to do it better.

Procedural note: Maybe we can find a better venue for such a discussion? This already completely occupies the channel and prevents other subjects from getting attention.