NixOS RFC 0046

# NixOS RFC 0046 ## Participants 2019-11-21 * Michael * Ryan * Zimbatm ## Decisions * Tell John to call for RFC FCP ## Chatlog Ryan * the updates mostly match what we had talked about Zimbatm * I thought we wanted to extend the motivation a bit Zimbatm * Four angles of motivation 1. Common language 2. Clarifies what to users what will work 3. What should the infrastructure support? 4. Maintainers need to know whether their package should work Michael * Require platform maintainer groups? * Darwin has 4 maintainers, one is maybe inactive RyanTM * RFC 54 would say Darwin's support would be restricted by the maintainer number Zimbatm * Lets limit prescribing rules because this is open source Michael * Should we have a ARM{6,7,8} maintainers group? Zimbatm * No * What is the form the team should take? RyanTM * It would be nice to know how to get access to teams Zimbatm * Does a team have IRC? * Looks like the RFC is in a pretty good state Michael * Can I reuse stuff from 54? RyanTM * The license is CC-SA Michael * Maybe copying stuff sometimes is a passive agressive thing Zimbatm * Ryan what do you think about the RFC? RyanTM * I'm happy with it and would vote in favor of RFC entering FPC with disposition to merge Zimbatm * I would too Michael * I don't have pending edits to do Ryan * What did you want to take from 54? Michael * Maybe something about package guidelines * Let's not do that now. * I'd help with 54 after 46 is wrapped up (but right now I'm a little biased) Zimbatm * Instead of hard requirements, we should try to have tooling * Once we have a good way of managing teams, we could make an RFC to make that more clear Michael * I think it is OK to have an RFC to create new guidance, if people are allowed not to change their current practice ## Participants 2019-11-14 * Graham * Ryan * Michael * zimbatm * John ## Decisions * Explicitly say that the only immediate outcome of RFC process is an update to the Nixpkgs manual * (well, we do need to update Nixos.org/nixpkgs to not claim i686-linux is better supported than aarch64-linux) * Make Tiers centered around impact, the rest are requirements * Slightly edit the procedure descriptions for changing tiers * 1.5 → 2, 2 → 3… * We want to invite CrystalGamma to the next meeting ## Chatlog Zimbatm * this is partly about maintainer responsibilities. * complexity in number of tiers Michael * much of the complexity might be inherent * platform support is not binary Zimbatm * can we move the platform support tier into the package and make it the package maintainer's responsibility? Graham * talk of adding risc-v or power9 builder or arm-v7 * "when it gets to it" support tier for builder (maybe weekly) Zimbatm * pull model vs push model * push: for officially supported, ideally merges only happen when the CI is green * pull: maintainers fix packages asychronously * add actionable items to the RFC? Graham * glibc musl - willdietz argued that getting musl in would help improve glibc too People's experience with porting to other platforms * Zimbatm: not exotic ones * Graham: not much * Ryan: not much Zimbatm * The RFC does not appear to have much of a roadmap Michael * It has a bit of a procedure Ryan * RFC will be something to point to in PRs & have a common vocabulary Zimbatm * Might be useful to have a guide from the perspective of someone who is adding platform support Ryan * Tiers maybe should be the top-level thing John arrived Zimbatm * Can we get rid of the 0.5 tiers by renumbering? Graham * Let's get rid of epsilon Zimbatm * We need to clarify what a maintainer means because maintainers cannot support all the different platforms. Maybe out of scope from this RFC. John * Would like to see it possible to add a platform without resistance as long as it does not pose a maintenance burden. * Windows is difficult because of no bash, so definitely OK with requiring community agreement first * Maybe there is less resistance to adding platforms now Graham * It would be nice to have intermediate goals for progressing up support tiers. Michael * How long should be people wait to merge as non-platform user/maintainer? John * Requirements for tier *n* vs maintenance burden of tier *n* * Tolerance/Impact is the output of the tier, Tooling and number of working packages in the input RyanTM * seems like this could simplify it a lot by saying that the only tiers we externally communicate are the impact/tolerance with the other ones being requirements of that Michael * Higher impact/tolerance tiers probably require RFCs * The outcome of the RFC is accepted is to add a section to the manual for what platforms support what tiers and definitions of tiers Zimbatm * We should update the website to talk about the platform Michael * https://nixos.org/nixpkgs/ is not up to date and indicates i686 is our main platforms RyanTM * of course we should get something on the website because marketing this will make it better for all of us Michael * nixpkgs on non-NixOS platforms (and NixOS.org homepage) We are planning to meet at the same time next week (John might not be there.)

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.