├── 0000-template.md ├── LICENSE.txt ├── README.md └── rfcs ├── 0001-rfc-process.md ├── 0004-replace-unicode-quotes.md ├── 0015-release-manager.md ├── 0023-musl-libc.md ├── 0025-nix-core-team.md ├── 0026-staging-workflow.md ├── 0036-review-process.png ├── 0036-rfc-process-team-amendment.md ├── 0036-rfc-process.png ├── 0039-unprivileged-maintainer-teams.md ├── 0043-rfcsc-rotation.md └── 0044-disband-nix-core.md /0000-template.md: -------------------------------------------------------------------------------- 1 | --- 2 | feature: (fill me in with a unique ident, my_awesome_feature) 3 | start-date: (fill me in with today's date, YYYY-MM-DD) 4 | author: (name of the main author) 5 | co-authors: (find a buddy later to help our with the RFC) 6 | shepherd-team: (names, to be nominated and accepted by RFC steering committee) 7 | shepherd-leader: (name to be appointed by RFC steering committee) 8 | related-issues: (will contain links to implementation PRs) 9 | --- 10 | 11 | # Summary 12 | [summary]: #summary 13 | 14 | One paragraph explanation of the feature. 15 | 16 | # Motivation 17 | [motivation]: #motivation 18 | 19 | Why are we doing this? What use cases does it support? What is the expected 20 | outcome? 21 | 22 | # Detailed design 23 | [design]: #detailed-design 24 | 25 | This is the bulk of the RFC. Explain the design in enough detail for somebody 26 | familiar with the ecosystem to understand, and implement. This should get 27 | into specifics and corner-cases, and include examples of how the feature is 28 | used. 29 | 30 | # Drawbacks 31 | [drawbacks]: #drawbacks 32 | 33 | Why should we *not* do this? 34 | 35 | # Alternatives 36 | [alternatives]: #alternatives 37 | 38 | What other designs have been considered? What is the impact of not doing this? 39 | 40 | # Unresolved questions 41 | [unresolved]: #unresolved-questions 42 | 43 | What parts of the design are still TBD or unknowns? 44 | 45 | # Future work 46 | [future]: #future-work 47 | 48 | What future work, if any, would be implied or impacted by this feature 49 | without being directly part of the work? 50 | -------------------------------------------------------------------------------- /LICENSE.txt: -------------------------------------------------------------------------------- 1 | Attribution-ShareAlike 4.0 International 2 | 3 | ======================================================================= 4 | 5 | Creative Commons Corporation ("Creative Commons") is not a law firm and 6 | does not provide legal services or legal advice. Distribution of 7 | Creative Commons public licenses does not create a lawyer-client or 8 | other relationship. Creative Commons makes its licenses and related 9 | information available on an "as-is" basis. Creative Commons gives no 10 | warranties regarding its licenses, any material licensed under their 11 | terms and conditions, or any related information. Creative Commons 12 | disclaims all liability for damages resulting from their use to the 13 | fullest extent possible. 14 | 15 | Using Creative Commons Public Licenses 16 | 17 | Creative Commons public licenses provide a standard set of terms and 18 | conditions that creators and other rights holders may use to share 19 | original works of authorship and other material subject to copyright 20 | and certain other rights specified in the public license below. The 21 | following considerations are for informational purposes only, are not 22 | exhaustive, and do not form part of our licenses. 23 | 24 | Considerations for licensors: Our public licenses are 25 | intended for use by those authorized to give the public 26 | permission to use material in ways otherwise restricted by 27 | copyright and certain other rights. Our licenses are 28 | irrevocable. Licensors should read and understand the terms 29 | and conditions of the license they choose before applying it. 30 | Licensors should also secure all rights necessary before 31 | applying our licenses so that the public can reuse the 32 | material as expected. Licensors should clearly mark any 33 | material not subject to the license. This includes other CC- 34 | licensed material, or material used under an exception or 35 | limitation to copyright. More considerations for licensors: 36 | wiki.creativecommons.org/Considerations_for_licensors 37 | 38 | Considerations for the public: By using one of our public 39 | licenses, a licensor grants the public permission to use the 40 | licensed material under specified terms and conditions. If 41 | the licensor's permission is not necessary for any reason--for 42 | example, because of any applicable exception or limitation to 43 | copyright--then that use is not regulated by the license. Our 44 | licenses grant only permissions under copyright and certain 45 | other rights that a licensor has authority to grant. Use of 46 | the licensed material may still be restricted for other 47 | reasons, including because others have copyright or other 48 | rights in the material. A licensor may make special requests, 49 | such as asking that all changes be marked or described. 50 | Although not required by our licenses, you are encouraged to 51 | respect those requests where reasonable. More_considerations 52 | for the public: 53 | wiki.creativecommons.org/Considerations_for_licensees 54 | 55 | ======================================================================= 56 | 57 | Creative Commons Attribution-ShareAlike 4.0 International Public 58 | License 59 | 60 | By exercising the Licensed Rights (defined below), You accept and agree 61 | to be bound by the terms and conditions of this Creative Commons 62 | Attribution-ShareAlike 4.0 International Public License ("Public 63 | License"). To the extent this Public License may be interpreted as a 64 | contract, You are granted the Licensed Rights in consideration of Your 65 | acceptance of these terms and conditions, and the Licensor grants You 66 | such rights in consideration of benefits the Licensor receives from 67 | making the Licensed Material available under these terms and 68 | conditions. 69 | 70 | 71 | Section 1 -- Definitions. 72 | 73 | a. Adapted Material means material subject to Copyright and Similar 74 | Rights that is derived from or based upon the Licensed Material 75 | and in which the Licensed Material is translated, altered, 76 | arranged, transformed, or otherwise modified in a manner requiring 77 | permission under the Copyright and Similar Rights held by the 78 | Licensor. For purposes of this Public License, where the Licensed 79 | Material is a musical work, performance, or sound recording, 80 | Adapted Material is always produced where the Licensed Material is 81 | synched in timed relation with a moving image. 82 | 83 | b. Adapter's License means the license You apply to Your Copyright 84 | and Similar Rights in Your contributions to Adapted Material in 85 | accordance with the terms and conditions of this Public License. 86 | 87 | c. BY-SA Compatible License means a license listed at 88 | creativecommons.org/compatiblelicenses, approved by Creative 89 | Commons as essentially the equivalent of this Public License. 90 | 91 | d. Copyright and Similar Rights means copyright and/or similar rights 92 | closely related to copyright including, without limitation, 93 | performance, broadcast, sound recording, and Sui Generis Database 94 | Rights, without regard to how the rights are labeled or 95 | categorized. For purposes of this Public License, the rights 96 | specified in Section 2(b)(1)-(2) are not Copyright and Similar 97 | Rights. 98 | 99 | e. Effective Technological Measures means those measures that, in the 100 | absence of proper authority, may not be circumvented under laws 101 | fulfilling obligations under Article 11 of the WIPO Copyright 102 | Treaty adopted on December 20, 1996, and/or similar international 103 | agreements. 104 | 105 | f. Exceptions and Limitations means fair use, fair dealing, and/or 106 | any other exception or limitation to Copyright and Similar Rights 107 | that applies to Your use of the Licensed Material. 108 | 109 | g. License Elements means the license attributes listed in the name 110 | of a Creative Commons Public License. The License Elements of this 111 | Public License are Attribution and ShareAlike. 112 | 113 | h. Licensed Material means the artistic or literary work, database, 114 | or other material to which the Licensor applied this Public 115 | License. 116 | 117 | i. Licensed Rights means the rights granted to You subject to the 118 | terms and conditions of this Public License, which are limited to 119 | all Copyright and Similar Rights that apply to Your use of the 120 | Licensed Material and that the Licensor has authority to license. 121 | 122 | j. Licensor means the individual(s) or entity(ies) granting rights 123 | under this Public License. 124 | 125 | k. Share means to provide material to the public by any means or 126 | process that requires permission under the Licensed Rights, such 127 | as reproduction, public display, public performance, distribution, 128 | dissemination, communication, or importation, and to make material 129 | available to the public including in ways that members of the 130 | public may access the material from a place and at a time 131 | individually chosen by them. 132 | 133 | l. Sui Generis Database Rights means rights other than copyright 134 | resulting from Directive 96/9/EC of the European Parliament and of 135 | the Council of 11 March 1996 on the legal protection of databases, 136 | as amended and/or succeeded, as well as other essentially 137 | equivalent rights anywhere in the world. 138 | 139 | m. You means the individual or entity exercising the Licensed Rights 140 | under this Public License. Your has a corresponding meaning. 141 | 142 | 143 | Section 2 -- Scope. 144 | 145 | a. License grant. 146 | 147 | 1. Subject to the terms and conditions of this Public License, 148 | the Licensor hereby grants You a worldwide, royalty-free, 149 | non-sublicensable, non-exclusive, irrevocable license to 150 | exercise the Licensed Rights in the Licensed Material to: 151 | 152 | a. reproduce and Share the Licensed Material, in whole or 153 | in part; and 154 | 155 | b. produce, reproduce, and Share Adapted Material. 156 | 157 | 2. Exceptions and Limitations. For the avoidance of doubt, where 158 | Exceptions and Limitations apply to Your use, this Public 159 | License does not apply, and You do not need to comply with 160 | its terms and conditions. 161 | 162 | 3. Term. The term of this Public License is specified in Section 163 | 6(a). 164 | 165 | 4. Media and formats; technical modifications allowed. The 166 | Licensor authorizes You to exercise the Licensed Rights in 167 | all media and formats whether now known or hereafter created, 168 | and to make technical modifications necessary to do so. The 169 | Licensor waives and/or agrees not to assert any right or 170 | authority to forbid You from making technical modifications 171 | necessary to exercise the Licensed Rights, including 172 | technical modifications necessary to circumvent Effective 173 | Technological Measures. For purposes of this Public License, 174 | simply making modifications authorized by this Section 2(a) 175 | (4) never produces Adapted Material. 176 | 177 | 5. Downstream recipients. 178 | 179 | a. Offer from the Licensor -- Licensed Material. Every 180 | recipient of the Licensed Material automatically 181 | receives an offer from the Licensor to exercise the 182 | Licensed Rights under the terms and conditions of this 183 | Public License. 184 | 185 | b. Additional offer from the Licensor -- Adapted Material. 186 | Every recipient of Adapted Material from You 187 | automatically receives an offer from the Licensor to 188 | exercise the Licensed Rights in the Adapted Material 189 | under the conditions of the Adapter's License You apply. 190 | 191 | c. No downstream restrictions. You may not offer or impose 192 | any additional or different terms or conditions on, or 193 | apply any Effective Technological Measures to, the 194 | Licensed Material if doing so restricts exercise of the 195 | Licensed Rights by any recipient of the Licensed 196 | Material. 197 | 198 | 6. No endorsement. Nothing in this Public License constitutes or 199 | may be construed as permission to assert or imply that You 200 | are, or that Your use of the Licensed Material is, connected 201 | with, or sponsored, endorsed, or granted official status by, 202 | the Licensor or others designated to receive attribution as 203 | provided in Section 3(a)(1)(A)(i). 204 | 205 | b. Other rights. 206 | 207 | 1. Moral rights, such as the right of integrity, are not 208 | licensed under this Public License, nor are publicity, 209 | privacy, and/or other similar personality rights; however, to 210 | the extent possible, the Licensor waives and/or agrees not to 211 | assert any such rights held by the Licensor to the limited 212 | extent necessary to allow You to exercise the Licensed 213 | Rights, but not otherwise. 214 | 215 | 2. Patent and trademark rights are not licensed under this 216 | Public License. 217 | 218 | 3. To the extent possible, the Licensor waives any right to 219 | collect royalties from You for the exercise of the Licensed 220 | Rights, whether directly or through a collecting society 221 | under any voluntary or waivable statutory or compulsory 222 | licensing scheme. In all other cases the Licensor expressly 223 | reserves any right to collect such royalties. 224 | 225 | 226 | Section 3 -- License Conditions. 227 | 228 | Your exercise of the Licensed Rights is expressly made subject to the 229 | following conditions. 230 | 231 | a. Attribution. 232 | 233 | 1. If You Share the Licensed Material (including in modified 234 | form), You must: 235 | 236 | a. retain the following if it is supplied by the Licensor 237 | with the Licensed Material: 238 | 239 | i. identification of the creator(s) of the Licensed 240 | Material and any others designated to receive 241 | attribution, in any reasonable manner requested by 242 | the Licensor (including by pseudonym if 243 | designated); 244 | 245 | ii. a copyright notice; 246 | 247 | iii. a notice that refers to this Public License; 248 | 249 | iv. a notice that refers to the disclaimer of 250 | warranties; 251 | 252 | v. a URI or hyperlink to the Licensed Material to the 253 | extent reasonably practicable; 254 | 255 | b. indicate if You modified the Licensed Material and 256 | retain an indication of any previous modifications; and 257 | 258 | c. indicate the Licensed Material is licensed under this 259 | Public License, and include the text of, or the URI or 260 | hyperlink to, this Public License. 261 | 262 | 2. You may satisfy the conditions in Section 3(a)(1) in any 263 | reasonable manner based on the medium, means, and context in 264 | which You Share the Licensed Material. For example, it may be 265 | reasonable to satisfy the conditions by providing a URI or 266 | hyperlink to a resource that includes the required 267 | information. 268 | 269 | 3. If requested by the Licensor, You must remove any of the 270 | information required by Section 3(a)(1)(A) to the extent 271 | reasonably practicable. 272 | 273 | b. ShareAlike. 274 | 275 | In addition to the conditions in Section 3(a), if You Share 276 | Adapted Material You produce, the following conditions also apply. 277 | 278 | 1. The Adapter's License You apply must be a Creative Commons 279 | license with the same License Elements, this version or 280 | later, or a BY-SA Compatible License. 281 | 282 | 2. You must include the text of, or the URI or hyperlink to, the 283 | Adapter's License You apply. You may satisfy this condition 284 | in any reasonable manner based on the medium, means, and 285 | context in which You Share Adapted Material. 286 | 287 | 3. You may not offer or impose any additional or different terms 288 | or conditions on, or apply any Effective Technological 289 | Measures to, Adapted Material that restrict exercise of the 290 | rights granted under the Adapter's License You apply. 291 | 292 | 293 | Section 4 -- Sui Generis Database Rights. 294 | 295 | Where the Licensed Rights include Sui Generis Database Rights that 296 | apply to Your use of the Licensed Material: 297 | 298 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right 299 | to extract, reuse, reproduce, and Share all or a substantial 300 | portion of the contents of the database; 301 | 302 | b. if You include all or a substantial portion of the database 303 | contents in a database in which You have Sui Generis Database 304 | Rights, then the database in which You have Sui Generis Database 305 | Rights (but not its individual contents) is Adapted Material, 306 | 307 | including for purposes of Section 3(b); and 308 | c. You must comply with the conditions in Section 3(a) if You Share 309 | all or a substantial portion of the contents of the database. 310 | 311 | For the avoidance of doubt, this Section 4 supplements and does not 312 | replace Your obligations under this Public License where the Licensed 313 | Rights include other Copyright and Similar Rights. 314 | 315 | 316 | Section 5 -- Disclaimer of Warranties and Limitation of Liability. 317 | 318 | a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE 319 | EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS 320 | AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF 321 | ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS, 322 | IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION, 323 | WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR 324 | PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS, 325 | ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT 326 | KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT 327 | ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU. 328 | 329 | b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE 330 | TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, 331 | NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT, 332 | INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES, 333 | COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR 334 | USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN 335 | ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR 336 | DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR 337 | IN PART, THIS LIMITATION MAY NOT APPLY TO YOU. 338 | 339 | c. The disclaimer of warranties and limitation of liability provided 340 | above shall be interpreted in a manner that, to the extent 341 | possible, most closely approximates an absolute disclaimer and 342 | waiver of all liability. 343 | 344 | 345 | Section 6 -- Term and Termination. 346 | 347 | a. This Public License applies for the term of the Copyright and 348 | Similar Rights licensed here. However, if You fail to comply with 349 | this Public License, then Your rights under this Public License 350 | terminate automatically. 351 | 352 | b. Where Your right to use the Licensed Material has terminated under 353 | Section 6(a), it reinstates: 354 | 355 | 1. automatically as of the date the violation is cured, provided 356 | it is cured within 30 days of Your discovery of the 357 | violation; or 358 | 359 | 2. upon express reinstatement by the Licensor. 360 | 361 | For the avoidance of doubt, this Section 6(b) does not affect any 362 | right the Licensor may have to seek remedies for Your violations 363 | of this Public License. 364 | 365 | c. For the avoidance of doubt, the Licensor may also offer the 366 | Licensed Material under separate terms or conditions or stop 367 | distributing the Licensed Material at any time; however, doing so 368 | will not terminate this Public License. 369 | 370 | d. Sections 1, 5, 6, 7, and 8 survive termination of this Public 371 | License. 372 | 373 | 374 | Section 7 -- Other Terms and Conditions. 375 | 376 | a. The Licensor shall not be bound by any additional or different 377 | terms or conditions communicated by You unless expressly agreed. 378 | 379 | b. Any arrangements, understandings, or agreements regarding the 380 | Licensed Material not stated herein are separate from and 381 | independent of the terms and conditions of this Public License. 382 | 383 | 384 | Section 8 -- Interpretation. 385 | 386 | a. For the avoidance of doubt, this Public License does not, and 387 | shall not be interpreted to, reduce, limit, restrict, or impose 388 | conditions on any use of the Licensed Material that could lawfully 389 | be made without permission under this Public License. 390 | 391 | b. To the extent possible, if any provision of this Public License is 392 | deemed unenforceable, it shall be automatically reformed to the 393 | minimum extent necessary to make it enforceable. If the provision 394 | cannot be reformed, it shall be severed from this Public License 395 | without affecting the enforceability of the remaining terms and 396 | conditions. 397 | 398 | c. No term or condition of this Public License will be waived and no 399 | failure to comply consented to unless expressly agreed to by the 400 | Licensor. 401 | 402 | d. Nothing in this Public License constitutes or may be interpreted 403 | as a limitation upon, or waiver of, any privileges and immunities 404 | that apply to the Licensor or You, including from the legal 405 | processes of any jurisdiction or authority. 406 | 407 | 408 | ======================================================================= 409 | 410 | Creative Commons is not a party to its public 411 | licenses. Notwithstanding, Creative Commons may elect to apply one of 412 | its public licenses to material it publishes and in those instances 413 | will be considered the “Licensor.” The text of the Creative Commons 414 | public licenses is dedicated to the public domain under the CC0 Public 415 | Domain Dedication. Except for the limited purpose of indicating that 416 | material is shared under a Creative Commons public license or as 417 | otherwise permitted by the Creative Commons policies published at 418 | creativecommons.org/policies, Creative Commons does not authorize the 419 | use of the trademark "Creative Commons" or any other trademark or logo 420 | of Creative Commons without its prior written consent including, 421 | without limitation, in connection with any unauthorized modifications 422 | to any of its public licenses or any other arrangements, 423 | understandings, or agreements concerning use of licensed material. For 424 | the avoidance of doubt, this paragraph does not form part of the 425 | public licenses. 426 | 427 | Creative Commons may be contacted at creativecommons.org. 428 | 429 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Nix RFCs 2 | 3 | Many changes, including bug fixes and documentation improvements can be 4 | implemented and reviewed via the normal GitHub pull request workflow. 5 | 6 | Some changes though are "substantial", and we ask that these be put through a 7 | bit of a design process and produce a consensus among the Nix community. 8 | 9 | This is the bulk of the RFC. Explain the design in enough detail for somebody 10 | familiar with the ecosystem to understand, and implement. This should get 11 | into specifics and corner-cases, and include examples of how the feature is 12 | used. 13 | 14 | ## When this process is followed 15 | 16 | This process is followed when one intends to make "substantial" changes to the 17 | Nix ecosystem. What constitutes a "substantial" change is evolving based on 18 | community norms, but may include the following. 19 | 20 | * Any semantic or syntactic change to the language that is not a bug fix 21 | * Removing language features 22 | * Big restructuring of Nixpkgs 23 | * Expansions to the scope of Nixpkgs (new arch, major subprojects, ...) 24 | * Introduction of new interfaces or functions 25 | 26 | Certain changes do not require an RFC: 27 | 28 | * Adding, updating and removing packages in Nixpkgs 29 | * Fixing security updates and bugs that don't break interfaces 30 | 31 | Pull requests that contain any of the aforementioned 'substantial' changes may 32 | be closed if there is no RFC connected to the proposed changes. 33 | 34 | ## Terminology 35 | 36 | ##### RFC Steering Committee 37 | A team of people defined by [RFC 36](./rfcs/0036-rfc-process-team-amendment.md) 38 | and stays consistent until the team members are changed via a follow-up RFC. 39 | This committee is responsible for forming an RFC Shepherd team from the 40 | available nominations on each RFC. This team also names the leader of the 41 | Shepherd team. This has to happen within 1 week after the PR has been opened. 42 | Until then the Steering Committee is responsible for guiding the discussion. In 43 | case of the Shepherding Team not doing its work the Steering Committee shall 44 | encourage them or step in and assign new Shepherds. They also are in charge of 45 | merging accepted and rejected RFCs. Generally by these expectations they should 46 | find time to meet once a week for about an hour. 47 | 48 | They have no special responsibility with regard to the content of an RFC, they 49 | can weigh in on them, the same as any other community member, but are only in 50 | charge of: 51 | * selecting the Shepherds unanimously 52 | * supervising that the Shepherds are carrying out their work 53 | * committing the final RFC 54 | 55 | ##### Shepherd Team 56 | A team of 3-4 community members defined unanimously by the RFC Steering 57 | Committee, responsible for accepting or rejecting a specific RFC. This team is 58 | created per RFC from community members nominated in the discussion on that RFC. 59 | 60 | This team should be people who are very familiar with the main components 61 | touched by the RFC. The author cannot be part of the Shepherd Team. In addition, 62 | at most half of the Shepherd Team can be part of the RFC Steering Committee. 63 | 64 | The responsibility of the team is to guide the discussion as long as it is 65 | constructive, new points are brought up and the RFC is iterated on and from time 66 | to time summarise the current state of discussion. If this is the case no longer, 67 | then the Shepherd Team shall step in with a motion for FCP. 68 | 69 | ##### Shepherd Leader 70 | The person in charge of the RFC process for a specific RFC, and responsible for 71 | ensuring the process is followed in a timely fashion. The Shepherd Leader has no 72 | special responsibility with regard to moving an undecided Shepherd Team to a 73 | certain decision. 74 | 75 | ##### Final Comment Period (FCP) 76 | A period of ten calendar days, which will be called by the Shepherd Team after 77 | the RFC has received ample discussion and enough of the tradeoffs have been 78 | discussed. The Shepherd Team will propose to either accept or reject the RFC 79 | after the FCP. 80 | 81 | 82 | ## Process from Creation to Merge 83 | 84 | *In short, to get a major change included in Nix or Nixpkgs, one must 85 | first get the RFC merged into the RFC repository as a markdown file under the 86 | `rfcs` directory. At that point the RFC is accepted and may be implemented 87 | with the goal of eventual inclusion into Nix or Nixpkgs.* 88 | 89 | 0. Have a cool idea! 90 | 1. Fill in the RFC. Put care into the details: RFCs that do not present 91 | convincing motivation, demonstrate understanding of the impact of the design, 92 | or are disingenuous about the drawbacks or alternatives tend to be 93 | poorly-received. You might want to create a PR in your fork of the RFCs 94 | repository to help you flesh it out with a few supporters or chat/video 95 | conference with a few people involved in the topic of the RFC. 96 | 2. In case your RFC is a technical proposal, you might want to prepare a 97 | prototype of your idea to firstly make yourself aware of potential pitfalls 98 | and also help reviewers understand the RFC. Code may be able to explain some 99 | issues in short. 100 | 3. Submit a pull request. As a pull request the RFC will receive design feedback 101 | from the larger community, and the author should be prepared to revise it in 102 | response. 103 | 4. For the nomination process for potential members of the RFC Shepherd Team, 104 | that is specific to each RFC, anyone interested can either nominate another 105 | person or themselves to be a potential member of the RFC Shepherd Team. This 106 | can already be done when submitting the PR. 107 | 5. The RFC Steering Committee assigns a subset of the nominees to the RFC 108 | Shepherd Team and designates a leader for it. This has to be done 109 | unanimously. 110 | 6. Build consensus and integrate feedback. RFCs that have broad support are much 111 | more likely to make progress than those that don't receive any comments. Feel 112 | free to reach out to the RFC Shepherd Team leader in particular to get help 113 | identifying stakeholders and obstacles. 114 | 7. The RFC Shepherd Team will discuss the RFC pull request, as much as possible 115 | in the comment thread of the pull request itself. Discussion outside of the 116 | pull request, either offline or in a video conference, that might be 117 | preferable to get to a solution for complex issues, will be summarized on the 118 | pull request comment thread. 119 | 8. RFCs rarely go through this process unchanged, especially as alternatives and 120 | drawbacks are shown. You can make edits, big and small, to the RFC to clarify 121 | or change the design, but make changes as new commits to the pull request, 122 | and leave a comment on the pull request explaining your changes. 123 | Specifically, do not squash or rebase commits after they are visible on the 124 | pull request. 125 | 9. At some point, a member of the RFC Shepherd Team will propose a "motion for 126 | final comment period" (FCP), along with a disposition for the RFC (merge or 127 | close). 128 | * This step is taken when enough of the tradeoffs have been discussed that 129 | the RFC Shepherd Team is in a position to make a decision. That does not 130 | require consensus amongst all participants in the RFC thread (which is 131 | usually impossible). However, the argument supporting the disposition on 132 | the RFC needs to have already been clearly articulated, and there should 133 | not be a strong consensus against that position outside of the RFC 134 | Shepherd Team. RFC Shepherd Team members use their best judgment in taking 135 | this step, and the FCP itself ensures there is ample time and notification 136 | for stakeholders to push back if it is made prematurely. 137 | * For RFCs with lengthy discussion, the motion to FCP is usually preceded by 138 | a summary comment trying to lay out the current state of the discussion 139 | and major tradeoffs/points of disagreement. 140 | * Before actually entering FCP, all members of the RFC Shepherd Team must 141 | sign off the motion. 142 | 10. The FCP lasts ten calendar days, so that it is open for at least 5 business 143 | days. It is also advertised widely, e.g. in NixOS Weekly and through 144 | Discourse announcements. This way all stakeholders have a chance to lodge 145 | any final objections before a decision is reached. 146 | 11. In most cases, the FCP period is quiet, and the RFC is either merged or 147 | closed. However, sometimes substantial new arguments or ideas are raised, 148 | the FCP is canceled, and the RFC goes back into development mode. 149 | 12. In case of acceptance, the RFC Steering Committee merges the PR. 150 | Otherwise the RFC's pull request is closed. If no 151 | consensus can be reached on the RFC but the idea in general is accepted, it 152 | gets closed, too. A note is added that is should be proposed again, when the 153 | circumstances, that are stopping the discussion to come to another decision, 154 | change. 155 | 156 | 157 | ![RFC Process](./rfcs/0036-rfc-process.png) 158 | ![Review Process](./rfcs/0036-review-process.png) 159 | 160 | 161 | ## The RFC life-cycle 162 | 163 | Once an RFC is accepted the authors may implement it and submit the feature as a 164 | pull request to the Nix or Nixpkgs repo. Being accepted is not a rubber stamp, 165 | and in particular still does not mean the feature will ultimately be merged; it 166 | does mean that in principle all the major stakeholders have agreed to the 167 | feature and are amenable to merging it. In general though this means that the 168 | implementation will be merged as long as there are no substantial technical 169 | objections to the implementation. 170 | 171 | Furthermore, the fact that a given RFC has been accepted implies nothing about 172 | what priority is assigned to its implementation, nor does it imply anything 173 | about whether a Nix/Nixpkgs developer has been assigned the task of implementing 174 | the feature. While it is not necessary that the author of the RFC also write the 175 | implementation, it is by far the most effective way to see an RFC through to 176 | completion: authors should not expect that other project developers will take on 177 | responsibility for implementing their accepted feature. 178 | 179 | Minor modifications to accepted RFCs can be done in follow-up pull requests. We 180 | strive to write each RFC in a manner that it will reflect the final design of 181 | the feature; but the nature of the process means that we cannot expect every 182 | merged RFC to actually reflect what the end result will be after implementation. 183 | 184 | In general, once accepted, RFCs should not be substantially changed. Only very 185 | minor changes should be submitted as amendments. More substantial changes should 186 | be new RFCs, with a note added to the original RFC. Exactly what counts as a 187 | "very minor change" is up to the RFC Shepherd Team of the RFC to be amended, to 188 | be decided in cooperation with the RFC Steering Committee. 189 | 190 | 191 | ## Members of the RFC Steering Committee 192 | 193 | The current members of the RFC Steering Committee are: 194 | 195 | - Eelco Dolstra (edolstra, niksnut) 196 | - Shea Levy (shlevy) 197 | - Domen Kožar (domenkozar) 198 | - Jörg Thalheim (Mic92) 199 | - Robin Gloster (globin) 200 | 201 | 202 | ## License 203 | 204 | All contributions are licensed by their respective authors under the 205 | [CC-BY-SA 4.0 License](https://creativecommons.org/licenses/by-sa/4.0/legalcode). 206 | -------------------------------------------------------------------------------- /rfcs/0001-rfc-process.md: -------------------------------------------------------------------------------- 1 | --- 2 | feature: rfc-process 3 | start-date: 2017-02-12 4 | author: zimbatm 5 | co-authors: teh, MoreTea 6 | related-issues: https://github.com/zimbatm/rfcs/pull/2 7 | --- 8 | 9 | # Summary 10 | [summary]: #summary 11 | 12 | The "RFC" (request for comments) process is intended to provide a consistent 13 | and controlled path for new features to enter the Nix language, packages and 14 | OS, so that all stakeholders can be confident about the direction the 15 | ecosystem is evolving in. 16 | 17 | # Motivation 18 | [motivation]: #motivation 19 | 20 | There are a number of changes that are significant enough that they could 21 | benefit from wider community consensus before being implemented. Either 22 | because they introduce new concepts, big changes or are controversial enough 23 | that not everybody will agree on the direction to take. 24 | 25 | Therefore, the purpose of this RFC is to introduce a process that allows to 26 | bring the discussion upfront and avoid unnecesary implementations. It forces 27 | developers to formulate their ideas without getting bogged down into 28 | implementation details. This RFC is used to bootstrap the process and further 29 | RFCs can be used to refine the process. 30 | 31 | # Detailed design 32 | [design]: #detailed-design 33 | 34 | Many changes, including bug fixes and documentation improvements can be 35 | implemented and reviewed via the normal GitHub pull request workflow. 36 | 37 | Some changes though are "substantial", and we ask that these be put through a 38 | bit of a design process and produce a consensus among the Nix community. 39 | 40 | This is the bulk of the RFC. Explain the design in enough detail for somebody 41 | familiar with the ecosystem to understand, and implement. This should get 42 | into specifics and corner-cases, and include examples of how the feature is 43 | used. 44 | 45 | ## When this process is followed 46 | 47 | This process is followed when one intends to make "substantial" changes to the 48 | Nix ecosystem. What constitutes a "substantial" change is evolving based on 49 | community norms, but may include the following. 50 | 51 | * Any semantic or syntactic change to the language that is not a bugfix 52 | * Removing language features 53 | * Big restructuring of nixpkgs 54 | * Expansions to the scope of nixpkgs (new arch, major subprojects, ...) 55 | * Introduction of new interfaces or functions 56 | 57 | Certain changes do not require an RFC: 58 | 59 | * Adding, updating and removing packages in nixpkgs 60 | * Fixing security updates and bugs that don't break interfaces 61 | 62 | Pull requests that contain any of the afore mentioned 'substantial' changes may be closed if there is no RFC connected to the proposed changes. 63 | 64 | ## Description of the process 65 | 66 | In short, to get a major feature added to the Nix ecosystem, one should first 67 | go through the RFC process in order to improve the likelyhood of inclusion. 68 | Here are roughly the steps that one would take: 69 | 70 | * Fork the RFC repo https://github.com/NixOS/rfcs 71 | * Copy `0000-template.md` to `rfcs/0000-my-feature.md` (where 'my-feature' is 72 | descriptive. don't assign an RFC number yet). 73 | * Fill in the RFC 74 | * Submit a pull request. Rename the rfcs with the PR number. (eg: PR #123 would 75 | be `rfcs/0123-my-feature.md`) 76 | 77 | At this point, the person submitting the RFC should find at least one "co-author" 78 | that will help them bring the RFC to completion. The goal is to improve the 79 | chances that the RFC is both desired and likely to be implemented. 80 | 81 | Once the author is happy with the state of the RFC, they should seek for 82 | wider community review by stating the readyness of the work. Advertisement on 83 | the mailing-list and IRC is an acceptable way of doing that. 84 | 85 | After a number of rounds of review the discussion should settle and a general 86 | consensus should emerge. This bit is left intentionally vague and should be 87 | refined in the future. We don't have a technical commitee so controversial 88 | changes will be rejected by default. 89 | 90 | If a RFC is accepted then authors may implement it and submit the feature as a 91 | pull request to the Nix or nixpkgs repo. An 'accepted' RFC is not a rubber 92 | stamp, and in particular still does not mean the feature will ultimately be 93 | merged; it does mean that in principle all the major stakeholders have agreed 94 | to the feature and are amenable to merging it. 95 | 96 | Whoever merges the RFC should do the following: 97 | 98 | * Fill in the remaining metadata in the RFC header, including links for the 99 | original pull request(s) and the newly created issue. 100 | * Commit everything. 101 | 102 | If a RFC is rejected, whoever merges the RFC should do the following: 103 | * Move the rfc to the rejected folder 104 | * Fill in the remaining metadata in the RFC header, including links for the 105 | original pull request(s) and the newly created issue. 106 | * Include a summary reason for the rejection 107 | * Commit everything 108 | 109 | ## Role of the "co-author" 110 | 111 | The goal for assigning a "co-author" is to help move the RFC along. 112 | 113 | The co-author should: 114 | * be available for discussion with the main author 115 | * respond to inquiries in a timely manner 116 | * help with fixing minor issues like typos so community discussion can stay 117 | on design issues 118 | 119 | The co-author doesn't necessarily have to agree with all the points of the RFC 120 | but should generally be satisfied that the proposed additions are a good thing 121 | for the community. 122 | 123 | # Drawbacks 124 | [drawbacks]: #drawbacks 125 | 126 | There is a risk that the additional process will hinder contribution more 127 | than it would help. We should stay alert that the process is only a way to 128 | help contribution, not an end in itself. 129 | 130 | # Alternatives 131 | [alternatives]: #alternatives 132 | 133 | Retain the current informal RFC process. The newly proposed RFC process is 134 | designed to improve over the informal process in the following ways: 135 | 136 | * Discourage unactionable or vague RFCs 137 | * Ensure that all serious RFCs are considered equally 138 | * Give confidence to those with a stake in the Nix ecosystem that they 139 | understand why new features are being merged 140 | 141 | As an alternative, we could adopt an even stricter RFC process than the one 142 | proposed here. If desired, we should likely look to Python's [PEP] process for 143 | inspiration. 144 | 145 | # Unresolved questions 146 | [unresolved]: #unresolved-questions 147 | 148 | To be solved in the future: 149 | 150 | 1. Does this RFC strike a favorable balance between formality and agility? 151 | 2. Does this RFC successfully address the aforementioned issues with the current 152 | informal RFC process? 153 | 154 | [PEP]: http://legacy.python.org/dev/peps/pep-0001/ 155 | -------------------------------------------------------------------------------- /rfcs/0004-replace-unicode-quotes.md: -------------------------------------------------------------------------------- 1 | --- 2 | feature: replace-unicode-quotes 3 | start-date: 2017-03-19 4 | author: layus 5 | co-authors: zimbatm 6 | related-issues: 7 | - https://github.com/NixOS/nix/pull/1140 8 | - https://github.com/NixOS/nix/issues/915 9 | - https://github.com/NixOS/nix/pull/910 10 | --- 11 | 12 | # Summary 13 | [summary]: #summary 14 | 15 | Nix uses unicode glyphs to quote strings and paths in its output. 16 | This RFC proposes to use only ASCII `"` and `'` for quoting purposes in strings 17 | printed during evaluation. 18 | 19 | # Motivation 20 | [motivation]: #motivation 21 | 22 | There are three main reasons for this change. 23 | 24 | 1. _Correctness_: By removing preventively these characters, we will not have 25 | to track the triggered issues separately. Unicode interact badly with 26 | variable interpolation in bash and will create more issues if we keep them. 27 | See "nix installer produces broken output on Darwin" 28 | https://github.com/NixOS/nix/issues/915. 29 | and the detailed explanation in https://github.com/NixOS/nix/issues/910. 30 | 31 | As an example, on the following code the shell is treating the 1st UTF-8 32 | byte of `’` as part of the variable name (which is undefined, thus ""). 33 | This results in `echo ""$'\x80\x99'` 34 | 35 | $ x=y 36 | $ echo "$x" 37 | y 38 | $ echo "$x’" # WTF is going on here!? 39 | ?? 40 | 41 | Also, such quotes should be removed from code snippets in the documentation. 42 | Otherwise, they cannot be used as is. See 43 | https://nixos.org/nix-dev/2010-April/004286.html 44 | 45 | 2. _Compatibility_: Most terminal emulators do not recognise unicode quotes as 46 | string delimiters. This makes string copy/paste from the terminal clumsy. 47 | 48 | For example, with a double-click in the following text, gnome-terminal will 49 | correctly select the derivation path without the quotes, while rxvt-unicode 50 | and st will select the string with the quotes. The string without quotes 51 | needs to be tediously edited to be reused anywhere. 52 | 53 | > building path(s) ‘/nix/store/hdlkn4pnc7l79jbawlkvssx1hc7gqmj8-gnum4-1.4.18’ 54 | 55 | Some terminals like Eterm seem unable to print these characters correctly. 56 | 57 | 3. _Consistency_: As some quotes were replaced for compatibility with shells and 58 | terminal emulators, we end up with a mix of both styles. 59 | 60 | See also 61 | - https://github.com/NixOS/nix/pull/947#r71710959 62 | - https://github.com/NixOS/nix/pull/1140 (Get rid of unicode quotes) 63 | - https://github.com/NixOS/nix/commit/b3fc0160618d89bf63ce87ccad27fc68360c9731 64 | 65 | # Detailed design 66 | [design]: #detailed-design 67 | 68 | Implementing this requires to replace every unicode quote glyph by an ASCII 69 | character. This change needs only happen in strings intended to be part of 70 | build logs or otherwise printed in the console. 71 | 72 | The automated change should not alter comments nor documentation, except for 73 | code snippets within that documentation. Neither should it alter derivations 74 | outputs by changing input variables. 75 | 76 | After the change, using ASCII quotes should be enforced to maintain consistency. 77 | 78 | The change mainly needs to happen in Nix, but nixpkgs should follow for consistency. 79 | For example, https://github.com/NixOS/nixpkgs/blob/c86f05e7ce13e64238960ebf3ee9706142db961b/nixos/modules/tasks/filesystems.nix#L236 should be updated. 80 | 81 | # Drawbacks 82 | [drawbacks]: #drawbacks 83 | 84 | Snippets of nix output in documentation and blogs will be out of sync (their 85 | quotes would not match the real printed output). 86 | Also, ASCII quotes are less aesthetic. 87 | 88 | # Alternatives 89 | [alternatives]: #alternatives 90 | 91 | As a decision needs to be take, we could also prefer to keep these nice unicode 92 | glyphs and fix issues as we encounter them. 93 | This also requires to push patches upstream in terminal emulators, and provide 94 | documentation as how to use them safely in shell scripts. 95 | 96 | # Unresolved questions 97 | [unresolved]: #unresolved-questions 98 | 99 | Should we also force ASCII quotes in pkgs meta fields and nixos options description ? 100 | These are displayed on the web (see https://nixos.org/nixos/options.html) and in the console 101 | with nixos-option. 102 | It would be simpler to consider these as documentation, leaving them as-is. 103 | 104 | 105 | -------------------------------------------------------------------------------- /rfcs/0015-release-manager.md: -------------------------------------------------------------------------------- 1 | --- 2 | feature: release-manager-nixos 3 | start-date: 2017-07-18 4 | author: Robin Gloster (@globin) 5 | co-authors: Franz Pletz (@fpletz) 6 | related-issues: -- 7 | --- 8 | 9 | # Summary 10 | [summary]: #summary 11 | 12 | NixOS currently has no process for electing release managers (RMs). We propose to 13 | switch to a model with two RMs, where each RM SHOULD 14 | serve for a consecutive term of two releases. A new RM is appointed 15 | by the previous team for each new release. 16 | 17 | # Motivation 18 | [motivation]: #motivation 19 | 20 | Currently release managing in NixOS has mostly been done by individuals who 21 | volunteered and were then chosen by the last release manager. Over the last 22 | few releases a process has been established and 23 | [documented](https://nixos.org/nixos/manual/index.html#release-process). 24 | As this makes it easier to cut a release this role should be passed on 25 | regularly and not be held by a single individual over a longer time. 26 | 27 | # Detailed design 28 | [design]: #detailed-design 29 | 30 | For each release there are two RMs. After each release the RM having 31 | managed two releases steps down and the RM team of the last release 32 | appoint a new RM. 33 | 34 | This makes sure a RM team always consists of one RM who already has 35 | managed one release and one RM being introduced to their role, making 36 | it easier to pass on knowledge and experience. 37 | 38 | A release manager's role is mostly facilitating: 39 | * manage the release process 40 | * start discussions about features and changes for a given release 41 | * create a roadmap 42 | * release in cooperation with Eelco Dolstra 43 | * decide which bug fixes, features etc. get backported after a release 44 | 45 | The process outlined in this RFC has informally started by @globin taking 46 | over the role from @domenkozar for NixOS 17.03 and having the latter as a 47 | backup and contact at all times for questions and support. We propose to 48 | continue this by appointing @fpletz for the second RM, who has been working 49 | with @globin a lot to keep the additional overhead of communication to a 50 | minimum at the beginning. 51 | 52 | # Drawbacks 53 | [drawbacks]: #drawbacks 54 | 55 | There is more communicational overhead but by having a second RM 56 | two individuals are checking the issues from a RM's point of view. 57 | Additionally it ensures that there is always one 58 | RM with the experience of having released NixOS once before. 59 | 60 | # Alternatives 61 | [alternatives]: #alternatives 62 | 63 | We can consider continuing the process as is and not specifying it formally, 64 | this will probably continue to work but does not ensure the role being passed 65 | on regularly. 66 | 67 | There are other possibilities how a RM can be elected, by vote (who by?), by 68 | @edolstra, RFCs, etc. This would mean even more overhead and the need of 69 | defining eligibility to vote or centring more decisions around @edolstra. 70 | 71 | # Unresolved questions 72 | [unresolved]: #unresolved-questions 73 | 74 | Nothing we can currently think of. 75 | 76 | # Future work 77 | [future]: #future-work 78 | 79 | * Specifying the process for releasing NixOS itself. 80 | -------------------------------------------------------------------------------- /rfcs/0023-musl-libc.md: -------------------------------------------------------------------------------- 1 | --- 2 | feature: musl-libc 3 | start-date: 2018-02-19 4 | author: Will Dietz (@dtzWill) 5 | co-authors: Shea Levy (@shlevy) 6 | related-issues: 34645, 6221, ... 7 | --- 8 | 9 | 10 | 11 | # Summary 12 | [summary]: #summary 13 | 14 | When targeting Linux platforms, Nixpkgs builds software against 15 | the defacto standard of Linux libc implementations: 16 | [glibc](https://www.gnu.org/software/libc/). 17 | 18 | This RFC proposes adding **experimental** support in Nixpkgs for the use 19 | of an alternative libc implementation, [musl](https://www.musl-libc.org/), 20 | for the reasons outlined below. 21 | Adding this support is similar to introducing support for an architecture, 22 | and realistically will be limited in compatibility and features 23 | compared to non-musl siblings such as `x86_64-unknown-linux-gnu`. 24 | 25 | Initial support is already available in nixpkgs master, capable 26 | of building up through important packages such as nixUnstable itself 27 | and LLVM. This is not to be taken as an endorsement: discussing 28 | and ultimately deciding whether support for musl should be part of nixpkgs 29 | is the subject of this RFC. That said, this initial support is 30 | a reasonable foundation for evaluating technical details discussed below, 31 | and a convenient way for interested parties to explore the work so far. 32 | 33 | To help ensure we're all on the same page, unless otherwise specified 34 | assume references to musl support implementation are in reference 35 | to this commit (latest master at time of writing): 36 | 37 | [bd7d5b365799a145717d31122ebfd24b51fea117](https://github.com/NixOS/nixpkgs/commit/bd7d5b365799a145717d31122ebfd24b51fea117) 38 | 39 | # Motivation 40 | [motivation]: #motivation 41 | 42 | ## Why Musl? 43 | There are many reasons to prefer the use of musl. 44 | 45 | musl is advertised as being: 46 | * lightweight 47 | * fast 48 | * simple 49 | * free 50 | * correctness: standards-conforming 51 | * correctness: safety 52 | 53 | Additionally it is very popular when statically linking software, 54 | creating binaries capable of executing most anywhere. 55 | 56 | In fact it is for this reason that Nixpkgs itself builds 57 | the bootstrap busybox using musl. 58 | 59 | A somewhat outdated overview comparing musl against other 60 | implementations is available [here](http://www.etalabs.net/compare_libcs.html). 61 | Note this comparison is maintained by the (primary) author of musl, 62 | (as indicated at the top of the page). 63 | 64 | I'm unable to find good numbers but musl is "arguably" the second 65 | most popular libc implementation on Linux, and is used 66 | by a number of important projects you may be familiar with 67 | large userbases, including: 68 | * Alpine Linux - [#70 on Distrowatch](https://distrowatch.com/table.php?distribution=alpine) but very popular amongst docker users for producing slim container images. 69 | * [OpenWRT/LEDE](https://openwrt.org/) - #1 open-source Linux router firmware project; foundation of most other projects targetting routers. 70 | More projects and details of how they use musl can be found here: 71 | 72 | https://wiki.musl-libc.org/projects-using-musl.html 73 | 74 | ## Why Nixpkgs? 75 | 76 | The importance of musl is not the primary point of contention in this RFC, 77 | instead perhaps the main question is whether such support belongs in Nixpkgs or not. 78 | 79 | The main arguments for inclusion are: 80 | * **convenience of use** 81 | * **foundation for exciting future work**: musl is widely used by high-level languages 82 | as the libc implementation used to produce statically linked programs: 83 | these are easy to deploy, launch quickly, and only include the code required. 84 | (NOTE: currently musl support prefers dynamic linking and shared libraries 85 | as is the strong preference in Nixpkgs) 86 | * Software sometimes must be patched to compile or run with musl; in @dtzWill's experience, 87 | these changes are largely fixes improving compliance and correctness resulting in 88 | higher-quality programs. Recent versions of glibc have started taking stronger stances 89 | on enforcing compliance (look at patch fallout folllowing any glibc upgrade in last year or so) 90 | resulting in overlapping work from both sides. 91 | (NOTE: use of glibc extensions or reliance on non-standard behavior is still common and unlikely to go away soon) 92 | 93 | And to a large extent: 94 | "Why not?" -- similar to including support for architectures such as Aarch64 or RISC-V, 95 | and just like support for those architectures it's relatively clear that pushing them 96 | into private forks would be detrimental to the nixpkgs project as well as all users 97 | interested in using Nixpkgs on those platforms/architectures. 98 | 99 | musl is clearly useful for a variety of important use cases, 100 | however including support has a few costs (see Drawbacks, below): 101 | do folks believe the costs are too high? 102 | 103 | 104 | ## Additional Resources 105 | 106 | * [musl FAQ](https://www.musl-libc.org/faq.html) 107 | * [projects using musl](https://wiki.musl-libc.org/projects-using-musl.html) 108 | * [Slides from a talk discussing various libcs, 2014](http://events17.linuxfoundation.org/sites/events/files/slides/libc-talk.pdf) 109 | 110 | ## Related Isssues 111 | 112 | * [big musl PR](https://github.com/NixOS/nixpkgs/pull/34645) 113 | * [issues matching "musl", newest first](https://github.com/NixOS/nixpkgs/search?o=desc&q=musl&s=created&type=Issues&utf8=%E2%9C%93) 114 | * [2015 libc discussion](https://github.com/NixOS/nixpkgs/issues/6221#issuecomment-116754223) 115 | 116 | # Detailed design 117 | [design]: #detailed-design 118 | 119 | ## Goals 120 | ### Laying the Foundation 121 | 122 | Implement the following in nixpkgs: 123 | 124 | * [x] musl-based bootstrap 125 | * [x] stdenv for native musl building 126 | * [x] cross-musl stdenv 127 | 128 | These are already implemented and are currently tested 129 | to build and provide basic functionality as part 130 | of release-cross.nix. 131 | 132 | These features would be very difficult to implement 133 | or maintain externally, and near impossible as an overlay. 134 | 135 | ## Package Compatibility 136 | 137 | For a variety of reasons many packages do not work out-of-the-box 138 | in musl-based environments. 139 | 140 | ### "Normalization" 141 | 142 | Vast majority of the problems here are "minor" and are the 143 | sort of problem we regularly encounter and address when 144 | bumping to a new glibc version, new gcc version, or using 145 | a clang-based stdenv (such as on Darwin). 146 | 147 | I'm calling these fixes "normalization". 148 | These are changes like "adding a missing include" or 149 | "don't assume compiler is invoked 'gcc'". 150 | 151 | These changes usually can be safely applied on all platforms 152 | (although sometimes they are not for rebuild reasons) 153 | and are easy to check for correctness or at least "couldn't-possibly-hurt". 154 | 155 | ### Big Incompatibilities 156 | 157 | Some packages are very much not portable and require significant 158 | and invasive changes to work with environments they don't expect. 159 | 160 | In the context of this RFC's proposed musl support, 161 | there are a number of packages that are known to be in this category: 162 | 163 | * systemd 164 | * ... 165 | 166 | This RFC proposes ignoring those for the immediate future, 167 | to be revisited later, and focuses on systemd. 168 | 169 | #### Systemd 170 | 171 | Currently many packages depend on systemd. 172 | This dependency is indirect for all but a handful of packages, 173 | with a few key pieces of software integrating with systemd. 174 | 175 | As far as I know this dependency is generally optional, 176 | and so we could easily avoid its use when using musl. 177 | 178 | This makes it possible to build a great number of packages 179 | (thousands) but more complicated software "ecosystems" 180 | and "desktop environments" will not work without something 181 | to tie them together with the various roles played by systemd. 182 | 183 | Addressing this in any way is not in the scope of this RFC. 184 | 185 | Similarly, NixOS itself (especially services) require systemd 186 | and we do not propose altering this. 187 | 188 | An early version of the "musl PR" patched systemd so that it 189 | would build successfully, using patches from OpenEmbedded.org. 190 | 191 | The result was never tested or reviewed in terms of providing 192 | basic functionality or general suitability for Nixpkgs/NixOs. 193 | 194 | (OE folks do great work, but they may expect rather different 195 | things from systemd or workaround introduced shortcomings elsewhere 196 | in various capacities) 197 | 198 | ## Scope 199 | 200 | Primarily non-GUI packages for now, due to systemd blocker. 201 | 202 | In the future these will be supported. 203 | 204 | This RFC is primarily concerned with the groundwork for using musl at all. 205 | 206 | ## Testing and Maintenance 207 | 208 | "Ideally" the answer would be an infinite number of builders would constantly 209 | build all the things on all the platforms. 210 | 211 | Unfortunately this is unrealistic due to capacity constraints and other reasons. 212 | 213 | ### Responsibility 214 | 215 | "musl team" is reponsible, initially consisting of 216 | 217 | * @dtzWill 218 | * @shlevy 219 | * @domenkozar 220 | * @rasendubi 221 | 222 | A team handle will be created to track this 223 | and to ping the team on musl-related discussion or issues. 224 | 225 | ### Infrastructure 226 | 227 | Build at least stdenv with more being added in the future. 228 | 229 | Jobs may be given lower priority/shares. 230 | 231 | # Drawbacks 232 | [drawbacks]: #drawbacks 233 | 234 | Why should we *not* do this? 235 | 236 | Potential maintenance burden, particularly regarding collections of patches, 237 | seems to be the primary concern. 238 | 239 | ## Additional Costs 240 | 241 | * Maintenance 242 | * Infrastructure (build pressure, storage, ...) 243 | 244 | ## Fractured Community 245 | 246 | > Another issue: adding musl support fractures the Nixpkgs user/development community: some people will run musl-based packages and some will run glibc-based packages. As a result all of Nixpkgs/NixOS will end up being less tested. it doubles the test matrix on Linux, after all. 247 | 248 | ## Previous Discussion of drawbacks and concerns 249 | 250 | This RFC was prompted by concerns about the drawbacks: 251 | ["I'm really not in favour of adding support to Nixpkgs"](https://github.com/NixOS/nixpkgs/pull/34645#issuecomment-366789321). 252 | This comment echoes very similar concerns expressed [back in 2015](https://github.com/NixOS/nixpkgs/issues/6221#issuecomment-116754223). 253 | 254 | # Alternatives 255 | [alternatives]: #alternatives 256 | 257 | * Maintain in a separate fork 258 | * [SLNOS project is willing to adopt](https://github.com/NixOS/nixpkgs/pull/34645#issuecomment-366845015) 259 | * Maintained as an overlay 260 | * No musl libc support. 261 | * Not really an "alternative" :). 262 | 263 | # Unresolved questions 264 | [unresolved]: #unresolved-questions 265 | 266 | What parts of the design are still TBD or unknowns? 267 | 268 | ## Support 269 | 270 | We need to work on defining: 271 | 272 | * What "Support" entails 273 | * Responsibility 274 | * Blame? 275 | 276 | For now we leave it as an informal understanding 277 | which we can improve on in the future. 278 | 279 | ## Impact 280 | 281 | ### Infrastructure 282 | 283 | * Hydra 284 | * ofborg 285 | 286 | ### Complexity 287 | 288 | * evaluation complexity 289 | * cost of behind-the-scenes "magic" required 290 | * keeping expressions avoidable 291 | * cyclomatic complexity 292 | 293 | ## How to Remove? 294 | 295 | Is there a good way to move forward 296 | without becoming impossibly intertwined? 297 | Such that a future party could 298 | * reduce nixpkgs to what it "would be" without musl support 299 | * Do so confidently without worrying about subtle 300 | breakages? 301 | 302 | Maintaining entirely as an overlay (or fork?) 303 | is an obviously effective solution in this regard. 304 | Clear separation and enforced use of carefully crafted 305 | interfaces/abstractions may also help with this. 306 | 307 | To some extent the importance of this depends 308 | on how likely the community expects to find itself 309 | "regretting" or wanting to be "rid" of musl support. 310 | 311 | However the design and use of good abstractions 312 | is valuable in all cases :). 313 | 314 | # Future work 315 | [future]: #future-work 316 | 317 | ### Fetch, Unpack, Patch 318 | 319 | (TODO: Split to new RFC?) 320 | It may be possible to leverage proper use of "phases" so that 321 | we can provide reasonable coverage of the unpack and patch 322 | phases for all "supported" configurations. 323 | 324 | As an example, this would make it possible for our x86_64 builders and users to 325 | get feedback ensuring that changes didn't break hashes or patch application 326 | elsewhere without requiring builders of each configuration. 327 | 328 | The benefit of this would be in avoiding most of the burden of building everything 329 | while making it easy to catch the most common sort of problems 330 | so they can be addressed ("oops I didn't update the hash for darwin") 331 | or flagged for investigation. 332 | 333 | I believe there's a branch or PR trying this somewhere. 334 | Regardless, out of scope for this RFC. 335 | -------------------------------------------------------------------------------- /rfcs/0025-nix-core-team.md: -------------------------------------------------------------------------------- 1 | --- 2 | feature: nix-core-team 3 | start-date: 2018-01-31 4 | end-date: 2019-04-25 5 | author: Graham Christensen 6 | co-authors: Daniel Peebles, Eelco Dolstra, Peter Simons, Shea Levy, Vladimír Čunát 7 | related-issues: #44 (disbands the team) 8 | --- 9 | 10 | # Superseded! 11 | 12 | This RFC is superseded by [RFC 44](./0044-disband-nix-core.md). The original text 13 | is preserved below. 14 | 15 | # Summary 16 | [summary]: #summary 17 | 18 | Create an experimental Nix Core Team to help lead the direction of 19 | Nix. This RFC may not be perfect, and we don’t have good answers to 20 | all the possible questions, but let’s try it. 21 | 22 | # Motivation 23 | [motivation]: #motivation 24 | 25 | - Improve visibility in to how the project operates 26 | - Distribute the work Eelco has been doing across more people 27 | - "Unstuck" pull requests which are sitting idle 28 | - Provide a more diverse group of experiences when evaluating changes 29 | to core Nix 30 | 31 | # Detailed design 32 | [design]: #detailed-design 33 | 34 | ## This team will: 35 | 36 | - Evaluate larger features being proposed to Nix 37 | - Serve as a second opinion on Nix changes that Eelco doesn't 38 | otherwise see the value to 39 | - Make road-mapping decisions 40 | - Evaluate a change to determine if it is ready for inclusion 41 | - Follow up on unreviewed pull requests 42 | 43 | The core team will have a GitHub team, a public mailing list, and 44 | perhaps an IRC channel. The team will comprise long-term, trusted 45 | community members who have a deep understanding of Nix and the Nix 46 | ecosystem. 47 | 48 | ## To start with, the team will be: 49 | 50 | - Daniel Peebles @copumpkin 51 | - Eelco Dolstra @edolstra 52 | - Peter Simons @peti 53 | - Shea Levy @shlevy 54 | - Vladimír Čunát @vcunat 55 | 56 | The team will be considered experimental to encourage revisiting how 57 | the processes work and refining them over time. We encourage the use 58 | of the RFC process to guide the process of the team itself. We 59 | explicitly invite the wider community to propose RFCs to help with 60 | this. 61 | 62 | Ultimately, we hope for a similar process to develop for NixOS as 63 | well. 64 | 65 | This experiment will run for one year, to allow for a few Nix and 66 | NixOS releases. 67 | 68 | ## Making Decisions 69 | 70 | In all cases, the team will strive to reach consensus. However, 71 | consensus will not always be possible. Decisions will be made after 72 | four out of five members vote for approval. 73 | 74 | Votes are registered through `+1`s and `-1`s. `Looks good to me`, `I 75 | don't know`s and `I'm not sure`s aren't votes. 76 | 77 | If some members abstain from the discussion, the following voting 78 | rules apply: 79 | 80 | 1. In any case, if two people are -1 on a proposal, it fails. 81 | 2. If after a sufficient period of time (to be determined later,) if 82 | only one person is -1 on a proposal and two or more people are +1, 83 | it passes. 84 | 85 | ## What this team is not 86 | 87 | This team is not about infrastructure, Nixpkgs, NixOS, Hydra, or the 88 | Foundation. This team is to focus very narrowly on Nix. 89 | -------------------------------------------------------------------------------- /rfcs/0026-staging-workflow.md: -------------------------------------------------------------------------------- 1 | --- 2 | feature: staging-workflow 3 | start-date: 2018-03-05 4 | author: Vladimír Čunát (@vcunat) 5 | co-authors: Frederik Rietdijk (@FRidh) 6 | related-issues: 7 | --- 8 | 9 | # Summary 10 | [summary]: #summary 11 | 12 | Define a new workflow for the `staging` branch that can better accomodate the 13 | current and future influx of changes in order to deliver mass-rebuilds faster to 14 | master. As part of this new workflow an additional branch, `staging-next`, shall 15 | be introduced. 16 | 17 | 18 | # Motivation 19 | [motivation]: #motivation 20 | 21 | The current workflow cannot handle the high amount of mass-rebuilds that are 22 | continuously delivered, resulting in long delays for these deliveries to reach 23 | `master`. When a certain delivery causes failures, attemps are typically made to 24 | fix these failures and stabilize `staging` so that the specific delivery can still 25 | reach `master`. 26 | 27 | Often it happens that during this period of stabilization other mass-rebuilds 28 | are submitted, and it is not uncommon that these also introduce failures, thus 29 | again increasing the time it takes for a delivery to reach `master`. This is 30 | especially worrysome in case of security fixes that need to be delivered as soon 31 | as possible. 32 | 33 | # Detailed design 34 | [design]: #detailed-design 35 | 36 | There shall be the following branches: 37 | - `master` is the main branch where all small deliveries go; 38 | - `staging` is branched from `master` and mass-rebuilds and other large deliveries go to this branch; 39 | - `staging-next` is branched from `staging` and only fixes to stabilize and security fixes shall be delivered to this branch. This branch shall be merged into `master` when deemed of sufficiently high quality. 40 | 41 | Binary packages shall be build by Hydra for each of these branches. The 42 | following table gives an overview of the branches, the check interval in hours, 43 | amount of shares, and the jobset that they build. 44 | 45 | 46 | | Branch | Interval | Shares | Jobset 47 | |----------------|----------|--------|----------- 48 | | `master` | 4 | High | release.nix 49 | | `staging-next` | 12 | Medium | release.nix 50 | | `staging` | 6 | Medium | release-small.nix 51 | 52 | 53 | The check interval of `staging-next` is reduced from 24 hours (the current value 54 | for `staging`) to 12 hours. This can be done because only stabilization fixes 55 | shall be submitted and thus fewer rebuilds shall typically have to be performed. 56 | 57 | The `staging` branch shall have a short interval of only 6 hours. This is because 58 | of the relatively small jobset, and to obtain a higher resolution to detect any 59 | troublesome deliveries. 60 | 61 | # Drawbacks 62 | [drawbacks]: #drawbacks 63 | 64 | A potential drawback of this new workflow is that the additional branch may be 65 | considered complicated and/or more difficult to work with. However, for most 66 | contributors the workflow will remain the same, that is, choose `master` or 67 | `staging` depending on the number of rebuilds. 68 | 69 | # Alternatives 70 | [alternatives]: #alternatives 71 | 72 | ## Maintain the status quo 73 | 74 | The current situation could be kept, however, that would not solve any of the 75 | issues mentioned in the "Motivation" section. 76 | 77 | ## Single branch 78 | 79 | Instead of multiple branches only a single branch, say `master`, could be kept 80 | for development. While this removes the issue of merge conflicts, it will result 81 | in continuous mass-rebuilds on `master`, slowing down the delivery of binary 82 | substitutes and thus development. 83 | 84 | ## Reduce Hydra jobset size 85 | 86 | Reducing the size of the Hydra jobset would mean the iteration pace could be 87 | higher, but has the downside of testing fewer packages, and having fewer binary 88 | substitutes available. 89 | 90 | The part about fewer binary substitutes could be partially mitigated by adding 91 | another slower larger jobset that wouldn't block the channel. 92 | 93 | # Unresolved questions 94 | [unresolved]: #unresolved-questions 95 | 96 | - The exact amount of shares, which is something that has the be found out. 97 | 98 | # Future work 99 | [future]: #future-work 100 | 101 | - Document the new workflow; 102 | - Create the new branch; 103 | - Create a Hydra jobset for the new branch and adjust the existing jobs. 104 | -------------------------------------------------------------------------------- /rfcs/0036-review-process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tweag/rfcs/830cea04a895a1ab2f7e40efca04b8d34a9980c2/rfcs/0036-review-process.png -------------------------------------------------------------------------------- /rfcs/0036-rfc-process-team-amendment.md: -------------------------------------------------------------------------------- 1 | --- 2 | feature: rfc-process-team-amendment 3 | start-date: 2018-10-27 4 | author: Robin Gloster 5 | co-authors: Graham Christensen 6 | related-issues: 1 (initial process), 38 (implementation) 7 | --- 8 | 9 | # Summary 10 | [summary]: #summary 11 | 12 | This RFC proposes an RFC Steering Committee who decide on a group of RFC 13 | shepherds for each RFC who guide the discussion to a general consensus and then 14 | propose a motion for a "Final Comment Period" (FCP) with a disposition for 15 | acception or rejection (see Terminology for a short definition) 16 | 17 | 18 | # Motivation 19 | [motivation]: #motivation 20 | 21 | A lot of RFCs have stalled and already an [RFC has been submitted exactly on 22 | this topic](https://github.com/NixOS/rfcs/pull/18), which ironically has not 23 | been decided on either. This new RFC takes the above into account and tries to 24 | expand on that to flesh out the process further. During this effort a lot of 25 | inspiration has been taken from [Rust's RFC 26 | process](https://github.com/rust-lang/rfcs#what-the-process-is) which works well 27 | and we have adapted to our needs. 28 | 29 | 30 | # Detailed design 31 | [design]: #detailed-design 32 | 33 | ## Terminology 34 | 35 | ##### RFC Steering Committee 36 | A team of people defined by _this_ RFC and stays consistent until the team 37 | members are changed via a follow-up RFC. This committee is responsible for 38 | forming an RFC Shepherd team from the available nominations on each RFC. This 39 | team also names the leader of the Shepherd team. This has to happen within 1 40 | week after the PR has been opened. Until then the Steering Committee is 41 | responsible for guiding the discussion. In case of the Shepherding Team not 42 | doing its work the Steering Committee shall encourage them or step in and assign 43 | new Shepherds. They also are in charge of merging accepted and rejected RFCs. 44 | Generally by these expectations they should find time to meet once a week for 45 | about an hour. 46 | 47 | They have no special responsibility with regard to the content of an RFC, they 48 | can weigh in on them, the same as any other community member, but are only in 49 | charge of: 50 | * selecting the Shepherds unanimously 51 | * supervising that the Shepherds are carrying out their work 52 | * committing the final RFC 53 | 54 | ##### Shepherd Team 55 | A team of 3-4 community members defined unanimously by the RFC Steering 56 | Committee, responsible for accepting or rejecting a specific RFC. This team is 57 | created per RFC from community members nominated in the discussion on that RFC. 58 | 59 | This team should be people who are very familiar with the main components 60 | touched by the RFC. The author cannot be part of the Shepherd Team. In addition, 61 | at most half of the Shepherd Team can be part of the RFC Steering Committee. 62 | 63 | The resposibility of the team is to guide the discussion as long as it is 64 | constructive, new points are brought up and the RFC is iterated on and from time 65 | to time summarise the current state of discussion. If this is the case no longer, 66 | then the Shepherd Team shall step in with a motion for FCP. 67 | 68 | ##### Shepherd Leader 69 | The person in charge of the RFC process for a specific RFC, and responsible for 70 | ensuring the process is followed in a timely fashion. The Shepherd Leader has no 71 | special resposibility with regard to moving an undecided Shepherd Team to a 72 | certain decision. 73 | 74 | ##### Final Comment Period (FCP) 75 | A period of ten calendar days, which will be called by the Shepherd Team after 76 | the RFC has received ample discussion and enough of the tradeoffs have been 77 | discussed. The Shepherd Team will propose to either accept or reject the RFC 78 | after the FCP. 79 | 80 | 81 | ## Process from Creation to Merge 82 | 83 | *In short, to get a major change included in Nix or nixpkgs, one must 84 | first get the RFC merged into the RFC repository as a markdown file under the 85 | `accepted` directory. At that point the RFC is accepted and may be implemented 86 | with the goal of eventual inclusion into Nix or nixpkgs.* 87 | 88 | 0. Have a cool idea! 89 | 1. Fill in the RFC. Put care into the details: RFCs that do not present 90 | convincing motivation, demonstrate understanding of the impact of the design, 91 | or are disingenuous about the drawbacks or alternatives tend to be 92 | poorly-received. You might want to create a PR in your fork of the RFCs 93 | repository to help you flesh it out with a few supporters or chat/video 94 | conference with a few people involved in the topic of the RFC. 95 | 2. In case your RFC is a technical proposal, you might want to prepare a 96 | prototype of your idea to firstly make yourself aware of potential pitfalls 97 | and also help reviewers understand the RFC. Code may be able to explain some 98 | issues in short. 99 | 3. Submit a pull request. As a pull request the RFC will receive design feedback 100 | from the larger community, and the author should be prepared to revise it in 101 | response. 102 | 4. For the nomination process for potential members of the RFC Shepherd Team, 103 | that is specific to each RFC, anyone interested can either nominate another 104 | person or themselves to be a potential member of the RFC Shepherd Team. This 105 | can already be done when submitting the PR. 106 | 5. The RFC Steering Committee assigns a subset of the nominees to the RFC 107 | Shepherd Team and designates a leader for it. This has to be done 108 | unanimously. 109 | 6. Build consensus and integrate feedback. RFCs that have broad support are much 110 | more likely to make progress than those that don't receive any comments. Feel 111 | free to reach out to the RFC Shepherd Team leader in particular to get help 112 | identifying stakeholders and obstacles. 113 | 7. The RFC Shepherd Team will discuss the RFC pull request, as much as possible 114 | in the comment thread of the pull request itself. Discussion outside of the 115 | pull request, either offline or in a video conference, that might be 116 | preferable to get to a solution for complex issues, will be summarized on the 117 | pull request comment thread. 118 | 8. RFCs rarely go through this process unchanged, especially as alternatives and 119 | drawbacks are shown. You can make edits, big and small, to the RFC to clarify 120 | or change the design, but make changes as new commits to the pull request, 121 | and leave a comment on the pull request explaining your changes. 122 | Specifically, do not squash or rebase commits after they are visible on the 123 | pull request. 124 | 9. At some point, a member of the RFC Shepherd Team will propose a "motion for 125 | final comment period" (FCP), along with a disposition for the RFC (merge or 126 | close). 127 | * This step is taken when enough of the tradeoffs have been discussed that 128 | the RFC Shepherd Team is in a position to make a decision. That does not 129 | require consensus amongst all participants in the RFC thread (which is 130 | usually impossible). However, the argument supporting the disposition on 131 | the RFC needs to have already been clearly articulated, and there should 132 | not be a strong consensus against that position outside of the RFC 133 | Shepherd Team. RFC Shepherd Team members use their best judgment in taking 134 | this step, and the FCP itself ensures there is ample time and notification 135 | for stakeholders to push back if it is made prematurely. 136 | * For RFCs with lengthy discussion, the motion to FCP is usually preceded by 137 | a summary comment trying to lay out the current state of the discussion 138 | and major tradeoffs/points of disagreement. 139 | * Before actually entering FCP, all members of the RFC Shepherd Team must 140 | sign off the motion. 141 | 10. The FCP lasts ten calendar days, so that it is open for at least 5 business 142 | days. It is also advertised widely, e.g. in NixOS Weekly and through 143 | Discourse announcements. This way all stakeholders have a chance to lodge 144 | any final objections before a decision is reached. 145 | 11. In most cases, the FCP period is quiet, and the RFC is either merged or 146 | closed. However, sometimes substantial new arguments or ideas are raised, 147 | the FCP is canceled, and the RFC goes back into development mode. 148 | 12. In case of acceptance, the RFC Steering Committee merges the PR into the 149 | `accepted` directory. Otherwise the RFC's pull request is closed. If no 150 | consensus can be reached on the RFC but the idea in general is accepted, it 151 | gets closed, too. A note is added that is should be proposed again, when the 152 | circumstances, that are stopping the discussion to come to another decision, 153 | change. 154 | 155 | 156 | ![RFC Process](./0036-rfc-process.png) 157 | ![Review Process](./0036-review-process.png) 158 | 159 | 160 | ## The RFC life-cycle 161 | 162 | Once an RFC is accepted the authors may implement it and submit the feature as a 163 | pull request to the Nix or nixpkgs repo. Being accepted is not a rubber stamp, 164 | and in particular still does not mean the feature will ultimately be merged; it 165 | does mean that in principle all the major stakeholders have agreed to the 166 | feature and are amenable to merging it. In general though this means that the 167 | implementation will be merged as long as there are no substantial technical 168 | objections to the implementation. 169 | 170 | Furthermore, the fact that a given RFC has been accepted implies nothing about 171 | what priority is assigned to its implementation, nor does it imply anything 172 | about whether a Nix/nixpkgs developer has been assigned the task of implementing 173 | the feature. While it is not necessary that the author of the RFC also write the 174 | implementation, it is by far the most effective way to see an RFC through to 175 | completion: authors should not expect that other project developers will take on 176 | responsibility for implementing their accepted feature. 177 | 178 | Minor modifications to accepted RFCs can be done in follow-up pull requests. We 179 | strive to write each RFC in a manner that it will reflect the final design of 180 | the feature; but the nature of the process means that we cannot expect every 181 | merged RFC to actually reflect what the end result will be after implementation. 182 | 183 | In general, once accepted, RFCs should not be substantially changed. Only very 184 | minor changes should be submitted as amendments. More substantial changes should 185 | be new RFCs, with a note added to the original RFC. Exactly what counts as a 186 | "very minor change" is up to the RFC Shepherd Team of the RFC to be amended, to 187 | be decided in cooperation with the RFC Steering Committee. 188 | 189 | 190 | ## Members of the RFC Steering Committee 191 | 192 | In cooperation and discussion with Eelco Dolstra and all nominees the proposal 193 | for the first iteration of members of the RFC Steering Committee are: 194 | 195 | - Eelco Dolstra (edolstra, niksnut) 196 | - Shea Levy (shlevy) 197 | - Domen Kožar (domenkozar) 198 | - Jörg Thalheim (Mic92) 199 | - Robin Gloster (globin) 200 | 201 | 202 | # Drawbacks 203 | [drawbacks]: #drawbacks 204 | 205 | If the Steering Committee were too biased, it might select a biased Shepherding 206 | Team. We are hoping for them and believe them to commit to doing their work in 207 | the interest of the community. Also this RFC introduces more process and 208 | bureaucracy, and requires more meetings for some core Nix/nixpkgs contributors. 209 | Precious time and energy will need to be devoted to discussions. 210 | 211 | # Alternatives 212 | [alternatives]: #alternatives 213 | 214 | The current state, which hardly ever results in an RFC being accepted. 215 | 216 | A possibility could also be to define owners for particular domains who have the 217 | responsibility of deciding to accept changes in that area. An extreme example of 218 | this case is a BDFL responsible for all final decisions. This would mirror the 219 | model of decisions in the kernel development. Although a soft form of "code 220 | owners" could be the base of decisions for Shepherd nominees for different RFCs, 221 | similar to the Rust RFC model having subteams, to whom RFCs are assigned. 222 | 223 | # Unresolved questions 224 | [unresolved]: #unresolved-questions 225 | 226 | None, as of now. 227 | 228 | # Future work 229 | [future]: #future-work 230 | 231 | Work on auto-labeling RFCs and automation of parts of the process that either do 232 | not need human intervention or to remind people to continue their work. 233 | 234 | Define how the Steering Committee is picked in the future and how to replace 235 | members thereof if they are not able to participate in the meetings, including 236 | guidelines on when to replace members. (a timeline, not being active, etc.) 237 | -------------------------------------------------------------------------------- /rfcs/0036-rfc-process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tweag/rfcs/830cea04a895a1ab2f7e40efca04b8d34a9980c2/rfcs/0036-rfc-process.png -------------------------------------------------------------------------------- /rfcs/0039-unprivileged-maintainer-teams.md: -------------------------------------------------------------------------------- 1 | --- 2 | feature: unprivileged-maintainer-teams 3 | start-date: 2019-01-16 4 | author: Graham Christensen 5 | co-authors: zimbatm 6 | related-issues: https://github.com/NixOS/ofborg/pull/303 7 | --- 8 | 9 | # Summary 10 | [summary]: #summary 11 | 12 | Package maintainers who are not able to commit directly to Nixpkgs 13 | don't have adequate tools to attentively maintain their package. 14 | OfBorg requests reviews of maintainers it can identify. GitHub only 15 | allows requesting a review of a Collaborator of the repository. 16 | 17 | This RFC bridges that gap, and allows OfBorg to request reviews of 18 | maintainers. 19 | 20 | # Motivation 21 | [motivation]: #motivation 22 | 23 | The goal of this RFC is to involve package maintainers in reviewing 24 | pull requests against their packages. This RFC does not grant 25 | maintainers the ability to merge pull requests against their own 26 | package. 27 | 28 | Maintainers take a responsibility for their package, and want to know 29 | about updates to their package's expression. However, Nixpkgs receives 30 | over 1,000 pull requests each month and subscribing to them all is not 31 | a reasonable requirement to maintain a package. 32 | 33 | The ideal outcome is package maintainership means a more active role 34 | in reviewing and approving changes to Nixpkgs. 35 | 36 | # Detailed design 37 | [design]: #detailed-design 38 | 39 | Package maintainers will be a member of a GitHub team, allowing OfBorg 40 | to request a review. 41 | 42 | ## The Team 43 | 44 | We will create a GitHub team under the NixOS GitHub organization 45 | called "Nixpkgs Maintainers" which only grants "read" access to 46 | Nixpkgs. 47 | 48 | This team will not grant any privileges to the Nix ecosystem 49 | repositories which non-members don't already have. They will not be able to 50 | close other people's issues or PRs or push branches. Experimentation 51 | and documentation shows this will only grant access to a team 52 | discussion board on GitHub. 53 | 54 | Being a member of this team will let the user mark themselves as a 55 | public member of the organization. This will show the NixOS logo on 56 | their GitHub profile, and people will see "Member" next to their 57 | account name when browsing issues. 58 | 59 | In order to be a member, each user will need to enable 2FA on their 60 | GitHub account, since [the GitHub organization requires 2FA of all 61 | members](https://github.com/NixOS/nixpkgs/issues/42761). 62 | 63 | See 64 | https://help.github.com/articles/permission-levels-for-an-organization/ 65 | for more information about what this will grant. 66 | 67 | ## Changes to `maintainers/maintainer-list.nix` 68 | 69 | The existing Nixpkgs maintainer list already contains a structured 70 | attribute set of per-maintainer details, including GitHub account 71 | names. Automation will sync this list of GitHub handles with the 72 | team's membership, automatically adding and removing people to/from 73 | the team as the master branch's maintainer list changes. 74 | 75 | GitHub handles can change from one user to another, and so we will 76 | change the maintainer list to include the GitHub user *ID* as well as 77 | their handle. When syncing, the automation will validate the user ID 78 | matches. GitHub User IDs are easily found at 79 | `https://api.github.com/users/«username»`. 80 | 81 | If a user ID's GitHub handle changes, the maintainer should remain 82 | part of the team under their new handle. The user's entry in 83 | `maintainer-list.nix` should be updated to reflect their new handle. 84 | 85 | ## Team Automation 86 | 87 | The team must be automatically updated at least once a day to ensure 88 | the maintainer list is fresh and up to date. The automation for this 89 | will be written in Rust with the hubcaps library. It will run on the 90 | NixOS infrastructure with limited credentials, with only sufficient 91 | permission to manage the team. 92 | 93 | The automation will fetch a fresh version of Nixpkgs's master branch, 94 | extract the maintainer information, and update the team. It will 95 | support a dry-run option. 96 | 97 | New members of the team will receive an invitation to join the GitHub 98 | organization. 99 | 100 | ## Changes to Reviewer/Maintainer Behavior 101 | 102 | Reviewers and maintainers should use GitHub's review tools (Approve, 103 | Request Changes, etc.) to clearly communicate their feedback about the 104 | pull request. 105 | 106 | ## OfBorg changes 107 | 108 | OfBorg will identify PRs which are approved by their maintainers, and 109 | add a special label `approved-by-maintainer`. 110 | 111 | ## Roll-Out Plan 112 | 113 | 1. Write an explanatory post on Discourse about the what-and-why of 114 | this plan. 115 | 2. Select a small group of maintainers who are not committers to be 116 | part of the first round, and manually run the tooling, and pause 117 | half a week to see what changes. 118 | 3. Automate the tooling on the infrastructure. 119 | 4. Expand the group to one quarter of the maintainers, and pause a 120 | half a week to gauge response. 121 | 5. Expand the group to one half of the maintainers and wait one week. 122 | 6. Expand the group to all of the maintainers. 123 | 124 | If we receive no major feedback or problems during the rollout, we 125 | will continue to 100%. 126 | 127 | # Drawbacks 128 | [drawbacks]: #drawbacks 129 | 130 | - Putting each maintainer in a read only team will display 131 | maintainers as "member", without specifying which team they are a 132 | member of. This gives the impression of authority which maintainers 133 | don't already receive. This is a pro and a con. 134 | 135 | - A mistake in the automation, or in the admin panel of GitHub could 136 | grant the team write access to Nix ecosystem repositories. 137 | 138 | - Package maintainers who do not wish to have a GitHub account will 139 | not benefit from this change. 140 | 141 | - Package maintainers who do have a GitHub account, but do not wish 142 | to use 2 factor authentication will not benefit from this change. 143 | 144 | - Someone who is banned from the NixOS GitHub organization is not 145 | allowed to be a package maintainer. 146 | 147 | # Alternatives 148 | [alternatives]: #alternatives 149 | 150 | Mentioning people in GitHub comments is the main alternative. This has 151 | the major down-side of not receiving the support of [GitHub's UI 152 | for requested reviews](https://github.com/pulls/review-requested). 153 | 154 | 155 | # Resolved questions 156 | [resolved]: #resolved-questions 157 | 158 | - Is it possible for the automation to spam a user who doesn't want 159 | to be part of the team with invitations? 160 | No. 161 | 162 | # Unresolved questions 163 | [unresolved]: #unresolved-questions 164 | 165 | - Do maintainers want to be part of this team? 166 | - Will the requirement of 2FA cause a significant number of people to 167 | not want to participate? 168 | - How will we handle people who have been invited, but have not 169 | accepted the invitation? 170 | 171 | # Future work 172 | [future]: #future-work 173 | 174 | - Writing the automation program. 175 | - Adding UIDs to every maintainer. 176 | - Creating the GitHub team 177 | - Updating the NixOS Org Configurations repository to run the 178 | automation with credentials on an automated basis. 179 | 180 | # Future Potential RFCs 181 | The following topics are explictly _not_ part of this RFC. 182 | 183 | - Allowing maintainers to merge pull requests against their packages 184 | without having commit access. 185 | - Requiring all maintainers to have a GitHub account with 2FA. 186 | -------------------------------------------------------------------------------- /rfcs/0043-rfcsc-rotation.md: -------------------------------------------------------------------------------- 1 | --- 2 | feature: rfcsc-rotation 3 | start-date: 2019-04-24 4 | author: Robin Gloster , Simon Lackerbauer 5 | related-issues: 36 6 | --- 7 | 8 | # Summary 9 | [summary]: #summary 10 | 11 | Each RFC Steering Committee (RFCSC) unanimously elects the succeeding one at 12 | their first meeting in December from an open list of nominees. 13 | 14 | # Motivation 15 | [motivation]: #motivation 16 | 17 | The RFC Steering Committee has been established by [RFC 18 | 36](https://github.com/NixOS/rfcs/blob/master/rfcs/0036-rfc-process-team-amendment.md). 19 | Future work for that RFC included a definition of how members to the Committee 20 | are to be chosen or removed. This RFC provides mechanisms for beginning and 21 | ending Steering Committee membership. The purpose of this is to ensure that the 22 | committee: 23 | 24 | * continues to consist of well-informed and motivated members; 25 | * continues to represent the evolving community; 26 | * remains active and keeps the RFC process running. 27 | 28 | # Detailed design 29 | [design]: #detailed-design 30 | 31 | The RFC Steering Committee shall always have five members. If membership drops 32 | below five members (for example by resignation of a member as detailed below), 33 | a new member shall be elected without delay after a nomination period of at 34 | least two weeks (see below for nomination and selection process). If the number 35 | of members of the RFCSC drops below 4 people, it cannot proceed with shepherd 36 | team selections until new members have been selected. 37 | 38 | ## Ending membership 39 | Membership in the Steering Committee can end by any of the following four 40 | mechanisms: 41 | 42 | 1. At the end of an election period. 43 | 2. Resignation 44 | 3. Unanimous vote by all other members after having missed two or more regular 45 | meetings without giving an appropriate excuse. 46 | 4. Unanimous vote by all other members due to conduct unbecoming of a member. 47 | 48 | A member can resign from the RFC Steering Committee at any time and for any 49 | reason. A member planning to resign should inform the rest of the RFC 50 | Steering Committee of their intention at their earliest convenience. 51 | 52 | ## Becoming a member 53 | The members chosen through the original implementation as 54 | specified in RFC 36 are regular members as specified in this RFC. They will 55 | stay on as members until replaced by new members as outlined below. 56 | 57 | If a seat has to be filled earlier than at the yearly vote, the new member will 58 | only serve for the rest of the term. 59 | 60 | Each year at the first meeting of the RFCSC in December (starting 2019, 61 | approximately a year after establishment in RFC 36) they unanimously decide on 62 | the succeeding committee members. If unanimous agreement cannot be reached, the 63 | RFCSC votes on each nominee, ranking them by votes in favour of the candidate 64 | and further holds run-off votes if there is a tie for the fifth & sixth spot. 65 | Nominations are open to anyone, and one can either nominate themself or any 66 | other person who accepts the nomination. Members of the previous RFCSC 67 | explicitly can stand again, but should reflect on their free time and 68 | commitment to their role. The nomination period starts at the beginning of 69 | November, a minimum of four weeks before election, and is announced on all 70 | relevant communication channels (as of April 2019, discourse.nixos.org, 71 | IRC #nixos and #nixos-dev, and NixOS Weekly). The new RFCSC takes over in the 72 | first week of January. 73 | 74 | Additionally to RFC 36 a new restriction formally comes into effect. In order 75 | to avoid conflict of interest there is an upper cap of appointing 2 members 76 | working for a single employer. 77 | 78 | # Drawbacks 79 | [drawbacks]: #drawbacks 80 | 81 | The RFCSC basically elects their own successors, but this minimises the 82 | complexity of having to hold elections, including defining who is eligible to 83 | vote and how to hold them. 84 | 85 | # Alternatives 86 | [alternatives]: #alternatives 87 | 88 | * Do nothing: then the current members of the RFC Steering Committee as 89 | defined in RFC 36 could stay on the Committee indefinitely or at least until 90 | that part of RFC 36 is overridden by a newly accepted RFC. 91 | * Rigorously defining a voting procedure (though possible, but probably too 92 | complex) 93 | 94 | # Unresolved questions 95 | [unresolved]: #unresolved-questions 96 | 97 | As of now, none. 98 | 99 | # Future work 100 | [future]: #future-work 101 | 102 | As this process is to be implemented over a fairly long time frame (a year for 103 | each iteration), this framework might have to be revised at a later date, 104 | incorporating any experience made over these years. 105 | -------------------------------------------------------------------------------- /rfcs/0044-disband-nix-core.md: -------------------------------------------------------------------------------- 1 | --- 2 | feature: disband-nix-core 3 | start-date: 2019-04-25 4 | author: Shea Levy 5 | co-authors: 6 | related-issues: NixOS/rfcs#25 7 | --- 8 | 9 | # Summary 10 | [summary]: #summary 11 | 12 | Formally disband the Nix Core Team in favor of the RFC steering 13 | committee. 14 | 15 | # Motivation 16 | [motivation]: #motivation 17 | 18 | The Nix Core Team was a first attempt at more formal process for the 19 | evolution of the Nix ecosystem and community. It was originally slated 20 | as a year-long experiment. 21 | 22 | It is now a little over a year since officially merging. In that time, 23 | the core team has not made signifcant progress on its initial goals. 24 | We now have the RFC steering/shepherding process which serves similar 25 | goals (but for the whole ecosystem, not just Nix proper) and is 26 | operating well. The remaining functions of the core team *not* covered 27 | by the RFC process (e.g. PR triage) can be resurrected as more 28 | narrowly defined responsibilities defined through RFCs. 29 | 30 | # Detailed design 31 | [design]: #detailed-design 32 | 33 | Remove the github group, close down the communication channels, 34 | announce on all relevant forums. 35 | 36 | # Drawbacks 37 | [drawbacks]: #drawbacks 38 | 39 | * The RFC process is not based around Nix expertise per se, and so may 40 | not cover the right skillsets. 41 | * There is not perfect overlap between the RFC process coverage and 42 | what the core team was intended to cover. 43 | 44 | # Alternatives 45 | [alternatives]: #alternatives 46 | 47 | * Keep the core team around in its current form and responsibilities. 48 | Would require a fresh attempt to follow through on the relevant 49 | committments to be practical. 50 | * Reform the core team based on what we've learned, including possibly 51 | narrowing the scope. 52 | 53 | # Unresolved questions 54 | [unresolved]: #unresolved-questions 55 | 56 | N/A 57 | 58 | # Future work 59 | [future]: #future-work 60 | 61 | Potentially explicitly enshrining some of the former core team 62 | responsibilities in some future RFCs. 63 | --------------------------------------------------------------------------------