User:Profpatsch: Difference between revisions

From NixOS Wiki
imported>Profpatsch
Create user page
 
imported>Profpatsch
support matrix: Linux MAINTAINERS file
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
IRC: Profpatsch (freenode, oftc, …)
* IRC: Profpatsch (freenode, oftc, …)
* Github: https://github.com/Profpatsch


Interested in: (package) tests, [[Workgroup:Container|containers]], lots of other stuff
=== Projects ===
 
* [https://github.com/Profpatsch/yarn2nix yarn2nix]: converting yarn.lock files to build npm projects with nix
* Package testing: an infrastructure to test nix derivations (without the need of VM tests)
** I gave [https://www.youtube.com/watch?v=5Z7IckV6gao a talk about that] on [http://nixcon2017.org/ the 2017 NixCon]
* Building minimal OCI/docker containers from nixpkgs, see [[Workgroup:Container]]
 
 
=== Ideas ===
 
==== nixpkgs support matrix ====
 
Note: grahamc [https://github.com/NixOS/rfcs/pull/25#issuecomment-369589272 mentioned (via peti)] that SUSE uses a <code>ring-0</code>, <code>ring-1</code>, … naming for the different support levels, which we should adopt [https://github.com/NixOS/rfcs/pull/25#issuecomment-369395221 to not introduce any more confusion in nix(pkgs/OS) naming].
 
{| class="wikitable"
|-
!
! x86_64
! glibc
! darwin
! armv7
! musl
|-
! Core
| full
| full
| full
| full
| support
|-
! Extended Core
| full
| full
| support
| support
| ask
|-
! Supported
| support
| support
| support
| support
| ask
|-
! Maintained
| support
| ask
| ask
| ask
| ask
|-
! Unmaintained
| none
| none
| none
| none
| none
|}
 
Support Levels:
* '''full''': always tested, up-to-date, backported and release blocker
* '''support''': tested and actively maintained, backported
* '''ask''': guarantees given depend on the maintainer and package
** adding/re-purposing meta attributes to indicate guarantees might be a good idea
* '''none''': not maintained (but might still be useful and is therefore not deleted)
 
Support Tiers:
* '''Core''': Small (low three-digit) number of packages maintained by active core team
* '''Extended Core''': less vital packages maintained by active maintainers
** About the same level as Archlinux core packages
** Stuff like e.g. <code>KDE</code> goes here
* '''Supported''': actively maintained by wider community, (automatically) tested on core systems [, backported]
* '''Maintained''': maintained, probably only manually tested on the maintainer’s system
* '''Unmaintained''': no maintainer, might not be on the newest version or broken because of updated dependencies
 
The [https://github.com/torvalds/linux/blob/b5c8314f0ebadb6d8a9789cb2d646cbef8448073/MAINTAINERS#L92 <code>MAINTAINERS</code> file] of the Linux kernel has the following categories:
 
<code><pre>
S: Status, one of the following:
  Supported: Someone is actually paid to look after this.
  Maintained: Someone actually looks after it.
  Odd Fixes: It has a maintainer but they don't have time to do
  much other than throw the odd patch in. See below..
  Orphan: No current maintainer [but maybe you could take the
  role as you write your new code].
  Obsolete: Old code. Something tagged obsolete generally means
  it has been replaced by a better system and you
  should be using that.
</pre></code>
 
Especially the “there’s somebody paid to maintain this subsystem” label is an idea we should incorporate.

Latest revision as of 16:25, 31 March 2019

Projects


Ideas

nixpkgs support matrix

Note: grahamc mentioned (via peti) that SUSE uses a ring-0, ring-1, … naming for the different support levels, which we should adopt to not introduce any more confusion in nix(pkgs/OS) naming.

x86_64 glibc darwin armv7 musl
Core full full full full support
Extended Core full full support support ask
Supported support support support support ask
Maintained support ask ask ask ask
Unmaintained none none none none none

Support Levels:

  • full: always tested, up-to-date, backported and release blocker
  • support: tested and actively maintained, backported
  • ask: guarantees given depend on the maintainer and package
    • adding/re-purposing meta attributes to indicate guarantees might be a good idea
  • none: not maintained (but might still be useful and is therefore not deleted)

Support Tiers:

  • Core: Small (low three-digit) number of packages maintained by active core team
  • Extended Core: less vital packages maintained by active maintainers
    • About the same level as Archlinux core packages
    • Stuff like e.g. KDE goes here
  • Supported: actively maintained by wider community, (automatically) tested on core systems [, backported]
  • Maintained: maintained, probably only manually tested on the maintainer’s system
  • Unmaintained: no maintainer, might not be on the newest version or broken because of updated dependencies

The MAINTAINERS file of the Linux kernel has the following categories:

S: Status, one of the following:
  Supported:	Someone is actually paid to look after this.
  Maintained:	Someone actually looks after it.
  Odd Fixes:	It has a maintainer but they don't have time to do
  much other than throw the odd patch in. See below..
  Orphan:	No current maintainer [but maybe you could take the
  role as you write your new code].
  Obsolete:	Old code. Something tagged obsolete generally means
  it has been replaced by a better system and you
  should be using that.

Especially the “there’s somebody paid to maintain this subsystem” label is an idea we should incorporate.