Attendees: @tomberek @roberth @fricklerhandwerk @edolstra @Ericson2314 @Dmills27
Notes: @fricklerhandwerk @Dmills27
-
@fricklerhandwerk: concerned with growing number of issues, especially security and bugs
- sorry for asking disruptive questions again
- @edolstra: rate of creation is higher than what we can even triage
- @fricklerhandwerk: would be great if we could be a bit more strategic and focused about how we approach things
- @tomberek: the hope was to get separation of concerns far enough to actually distribute code ownership
-
@fricklerhandwerk: what exactly can we do? options:
- focus on testing and infra to improve quality
- pay for a review and overhaul of issue backlog
- pay for developer experise to make progress
- hard feature freeze
-
@fricklerhandwerk: boundary conditions are that we’re hard time-constrained, and soft-limited by motivation to do particular things
- no one can’t tell anyone what to do
-
@fricklerhandwerk: do we even agree there is a problem?
-
@Ericson2314: it’s not great, but every software has bugs
- @edolstra: it’s a sign of success; only software that isn’t used doesn’t have bugs
-
@tomberek: it’s a problem; we’re trying to do too many things at once
- @roberth: many things can be solved without breaking things
-
@edolstra: given the number of incoming issues, no one manages to look at all of them
- we should spend the time doing actual triage to see if something needs immediate action
- @fricklerhandwerk: arguably that will only postpone dealing with the underlying issues by a week
- @roberth: agreed, meta-discussion is expensive but needed to resolve structural problems
-
@Ericson2314: it’s not great, but every software has bugs
- @tomberek: other portions of the ecosystem have scaled (Nixpkgs, users, features, demands on Nix), without Nix itself scaling
- (some discussion about test coverage)
-
@fricklerhandwerk: really all of this boils down to cutting scope (or playing divide and conquer) or increasing resources
-
@roberth: we can’t really cut scope, so we have to increase resources
-
@fricklerhandwerk: disagreed; we already cut scope implicitly.
- instead we should clearly no to things instead of ignoring problems arbitrarily and constantly taking on new things that happen to be on the top of the pile
- things being unpredictable is the main source of frustration for users and contributors
-
@fricklerhandwerk: disagreed; we already cut scope implicitly.
-
@tomberek: resource acquisition, allocation, and assosiated tasks require an organisation around that
- foundation board has been busy, no progress was made on requests for funding
-
@fricklerhandwerk: whether we can acquire more resources is primarily of a matter of will, and that requires some alignment on what we want
- when the team started, we did not manage to converge on a vision statement
- what do we want for Nix, from Nix?
-
@tomberek: Nix should become indispensable, and its concepts not foreign to software developers; if replaced, it would be replaced by essentially the same thing
- @fricklerhandwerk: one could say that’s already the case for 2-10k people
- @roberth: (paraphrased) it should work, support large-scale use cases
- @edolstra: Nix should be used. But it’s not finished, needs more features
- @ericson2314: (paraphrased) it should be the smallest thing required to do the job; portability is important so it can’t easily replaced
- (post meeting) @fricklerhandwerk: Nix already solves a big annoying problem that should never have existed; it should do that more reliably, efficiently, and flexibly, and not introduce new problems
-
@tomberek: Nix should become indispensable, and its concepts not foreign to software developers; if replaced, it would be replaced by essentially the same thing
-
@roberth: we can’t really cut scope, so we have to increase resources
- (some discussion on competition; docker, conda, ansible, …)
-
@edolstra: not clear why the foundation should pay for development of any particular thing. why would it be exactly testing, for instance?
-
@Ericson2314: Nix is not large enough to have big corp fund dedicated time for their developers to do things.
- once “immortal” it is easier to get ongoing investments from industrial users
-
@fricklerhandwerk: we’re aleady there, and effectively unable to accomodate contributions, which are another form of donation
- the team is already in the singular privileged position, and implicitly trusted, to spend such resources. the question is what we do with them
-
@Ericson2314: Nix is not large enough to have big corp fund dedicated time for their developers to do things.
- @fricklerhandwerk: when we focused on specific efforts, progress was made. but every time we ran into hard questions that required making serious decisions, it fizzled out
-
@tomberek: on additional contributions
- large resource+time just to onboard and establish working relationship
- should spend more time talking to the people, to mentor and empower to contribute
- @fricklerhandwerk: must align such that these engagments are productive. but what to align with?
-
@fricklerhandwerk: on team resources
- funding of projects: takes time to orchestrate
- accomodate both new contributor and existing maintainer time into estimates and planning
-
@Ericson2314: GSoC is an example of how to start
- established project
- limited scope
- budget
- extranal administration
-
@Dmills27: Working on Nix has been difficult to debug, new sets of tools, coming from Haskell. Would want to work on Nix issues, but has been hard to onboard.
- playlist of videos to approach a general problem
- pairing doesn’t scale
- attempted doc videos
-
@raitobezarius: example from systemd maintenance
- multiple generations of maintainers
- pairing IRL/sprints/events are very powerful to share knowledge and build working relationships
- async… much harder
-
@fricklerhandwerk: here’s a challenge where we can measure the result:
- each committer onboards another committer within 6 months
- can pick an area of responsibility within their specialty
- find people, try things out, later exchange what went well
- @tomberek @roberth agree to try
-
@edolstra: skeptical, it’s easy to break things
- @fricklerhandwerk: minimum requirement should be that new people take responsibility to clean up their own messes