Goals:
- Rework roadmap
- Deciding on scope of Aux
Attending:
- @jakehamilton (Jake Hamilton)
- @skyler (Skyler Grey, @minion on the forums)
- @isabel (Isabel Roses)
Minutes
Going over the website…
- @jakehamilton: let’s figure out the roadmap
- @jakehamilton: right now the website still mentions the nixpkgs fork
- @isabel: we should commit to not forking Nix, only packages
- @skyler: agreed, we should let Lix do their stuff
- @jakehamilton: agreed
- @jakehamilton: it means we can’t enable flakes, etc. on our timeline, we have to settle to what Lix is doing. We should enable experimental features OOTB
- @skyler: I think Lix was planning to do something similar to us on the timeline
- @isabel: also: flake melt exists as a proof of concept, it’s the opposite of flake-compat. It’s experimental and we’ve been heavily advised not to use it
- @jakehamilton: maybe that could be useful in the future, as it aligns with our support goals for both flakes/nonflakes
- @jakehamilton: Do we like the values on the website
- @isabel: yes, they look fine
- @skyler: I agree, I can get behind them
- @jakehamilton: how about the goals?
- @skyler: independent is confusing, “fork” is quite loaded and I think it’s unhelpful given where we’re trying to go
- @jakehamilton: I was seeing fork as nixpkgs under our org then building up a replacement, that’s the concept that you and getchoo are describing - we only disagree on the nixpkgs clone. The confusion comes from the communication
- @jakehamilton: maybe we should say we’re building a replacement instead
- @isabel: how about “alternate” instead?- @skyler: for independent we should remove nix
- @jakehamilton: agreed
- @skyler: for independent we should remove nix
- @isabel: I think we should abandon the nixpkgs fork, and go all-in on the multi-repo idea
- @skyler, @jakehamilton: agreed
- @jakehamilton: We shouldn’t have manual work for trivial updates. Ever.
- @isabel: We’re not dependent
- @jakehamilton, @skyler: do we want to be?
- @isabel: probably, I think it would be good, some of those library changes might be good to pull in
- @jakehamilton: I would like to eventually be able to remove dependence on nixpkgs. You don’t have to avoid it, but it feels like a worthwhile goal to be able to use us on our own
- @isabel: yeah
- @skyler: yes
- @jakehamilton: How is governance
- @jakehamilton: are SIGs and Committees fine?
- @isabel, @skyler: as ideas for what we are aiming for yes
- @jakehamilton: no issues with committees, SIGs, etc.
- @jakehamilton: How about elections
- @jakehamilton: K8S does 2-year terms, and some term limits, etc.
- @skyler: terms of 2 years seem very long for the current project speed
- @jakehamilton: sure, but this is a longer-term goal
- @isabel: I think debian also does 2-year terms
- @jakehamilton: K8S does 2-year terms, and some term limits, etc.
- @jakehamilton: does the wording need to change
- @skyler: I think linking to the wiki, etc., could avoid people not knowing what we mean here…
- @isabel: I think it’s generally fine
- @jakehamilton: are SIGs and Committees fine?
- @isabel: we need to remove stabilization, it’s all Lix’s thing
- @jakehamilton: infrastructure needs to stay a thing, should we collapse it
- @isabel: definitely collapse
- @skyler: if we collapse it, we need to still call it out as a thing
- @jakehamilton: any feelings on education?
- @jakehamilton: I think the reason we’re calling it out is because Nix has poor docs, I wanted to make it core to the project as a whole. I think it’s important for people to be able to learn and develop with it if we want it to succeed
- @skyler: you’re going to hear no dissent from me on making docs a core part of the project
- @jakehamilton: so, what about the wording?
- @skyler: I wonder if we can add something about how we’re documenting the process of contributing
- @skyler: independent is confusing, “fork” is quite loaded and I think it’s unhelpful given where we’re trying to go
- @jakehamilton: what about the roadmap?
- @skyler: I think we should cut soft fork
- @isabel: Agreed
- @jakehamilton: It it worth having a setup phase?
- @isabel: I think it’s worth saying so, people are very excited for hard fork
- @skyler: we should replace soft fork with setup, then
- @jakehamilton: the stuff that we’ve done so far makes sense
- @skyler: call the phase “setup and planning” maybe?
- @jakehamilton: sure
- @jakehamilton: we should call out that nothing is set in stone, groups are quite loose, no charters, etc.
- @jakehamilton: the purpose is to “get started” [i.e. not to be perfect]
- @isabel: how about funding?
- @skyler: call the phase “setup and planning” maybe?
- @jakehamilton: should we have some outputs for each phase? “Planning is done when you’ve planned it” but maybe that isn’t tangeable enough
- @jakehamilton: “this phase is complete once we have a clear plan for managing core and how the other SIGs will integrate”
- @isabel: how about proof of concept repos?
- @jakehamilton, @skyler: seems good
- @isabel: how about proof of concept repos?
- @jakehamilton: “this phase is complete once we have a clear plan for managing core and how the other SIGs will integrate”
- @jakehamilton: “hard fork” is poor wording here, maybe “implementation” is closer
- @jakehamilton: the purpose is “building the alternative”
- @skyler: I wonder if we should do infrastructure in this phase? If we’re not forking nixpkgs we can do it
- @jakehamilton: I think the costs will grow over time…
- @jakehamilton: could we use detsys cache as an interim?
- @skyler, @isabel: I think that this could cause people to lose trust in us following values
- @skyler: detsys is kind of at the core of a lot of the current stuff. I don’t know if we should accept this from them
- @jakehamilton: so we want CI, it would be nice to have a binary cache, currently we have an offer from detsys to run that for us… but we may want to deny it
- @isabel: security committee should probably have a say on caching
- @jakehamilton: how about we say no-to-maybe for binary cache for implementation
- @minion: probably we have to for now
- @jakehamilton: what other phases do we need?
- Infrastructure was consumed, I don’t think we need a whole phase for that now
- Organization phase mentions more full establishment of SIGs and Committees
- @isabel: I’m not sure organization fits there
- @skyler: agreed, organization feels more like the earlier bit
- @jakehamilton: at some point we need to have SIG and Committee charters… when should that happen
- @skyler: I wonder if a timeline would be better… I see this as happening alongside some of the later implementation… we continue building stuff but we also solidify some of these SIGs/Committees
- @jakehamilton: so this would encompass continued implementation and solidifying SIGs and Committees
- @skyler: yes
- @jakehamilton: so this would encompass continued implementation and solidifying SIGs and Committees
- @isabel: I’m not sure organization fits there
- Solidification…
- @jakehamilton: what about the CLI?
- @skyler: this is still important to me. We’re not lix, but nixos-rebuild, etc. are
- @isabel: could we provide something like this with a justfile?
- @skyler: no, that doesn’t work there… that would only be usable in your config/anywhere you could convince to add your justfile
- @isabel: so, similar to nh then?
- @skyler: yes
- @jakehamilton: how about flakes?
- @skyler: we can’t stabilize them, but we should enable them in our installer…
- @jakehamilton: what do Lix do?
- @jakehamilton: looks like they don’t enable them by default but they ask when you install… which is easy enough
- @jakehamilton: what about the CLI?
- How about the final phase?
- @skyler: I don’t want it to feel like the end
- @jakehamilton: how about we call out that we’re continuing at the end of the phase
- @jakehamilton: what do we need to do here?
- documentation
- branding
- @jakehamilton: lots of this stuff could be done earlier… but they must be done by now
- @jakehamilton: are secrets an important thing to have as part of this? They’re required for deployment
- @isabel: what secrets thing would we use
- @isabel: age has to be the default… sops doesn’t work properly on darwin
- @jakehamilton: how about something like gokey
- @isabel: I think anything that’s on the roadmap has to be certain…
- @isabel: maybe we can put something more fluffy in wikijs?
- @skyler, @isabel: we need to talk to COMSEC about this instead
- @isabel: what secrets thing would we use
- @skyler: I don’t want it to feel like the end
- @skyler: I think we should cut soft fork
Other bits
- @isabel: in our repositories can we do some metric for popularity like homebrew?
- @skyler: some metric is important, we can’t let a github stars be the be-all-end-all
- @isabel: vikunja is hosted on its own private gitea…
- @jakehamilton: maybe we could have people vote?
- @skyler: I want people to be sure that it’ll get in if they make a pull request…
- @jakehamilton: I meant prior to pull request, e.g. as issues
- @skyler: I’m trying to use this as a proxy for if it’s maintained
- @jakehamilton: “add everything” leads to lots of churn
- @isabel: and is more than 1 person going to use it?
- @jakehamilton: can we delegate this to SIGs?
- @isabel: SIGs probably have more of an idea what makes sense … e.g. Gnome might have looser or stricter guidelines, depending on their stance at packaging even more calculators