[Nix-dev] Improving the Developer Experience in the Nix Community

[Florian Friesdorf]

On Wed, 27 Jun 2012 09:30:28 -0400, Shea Levy <shea at shealevy.com> wrote:
> (..) Please, if you have a vision for what the nix projects could be
> but aren't, share it. Otherwise it's highly unlikely that the nix you
> want to be will come into existence.

I'd like it to be (not claiming that it isn't already):

- easy to package new stuff / update packages
  * for maintainers (people having commit access to nixpkgs and nixos)
    directly possible
  * for new contributors via github pull request or git
    format-patch/send-email

- easy to maintain patch sets (published or local)
  * currently easy against most recent master
  * to minimize deviation from channel to have maximum binary support
    via hydra, tags are needed for channel releases (on Eelco's todo
    list)

- easy to find:
  * how to install (cd/usb/other_linux)
  * where to file bugs (nixos vs nixpkgs)
    + can we move tickets between nixos and nixpkgs trackers?
  * how to contribute

- in-time security updates and instructions, needs (rough thoughts
  only):
  * enough maintainers to handle updates and inform about eventual data
    updates (like needed for the most recent pycrypto weakness right
    now)
  * maybe support through automatic scanning of security announcement
    lists and notification of maintainers if there seems need for action
  * tags for channel releases (see above) to base security updates on
    plus merging into master
  * higher priority for security update builds on hydra

- support for more platforms, finally I'd like all my devices (phone,
  laptop, server, tablets, ...) to run on nixos

- at least a yearly Nix/NixOS meetup/sprint/conference. I think frequent
  in person meetings would help to avoid miscommunications and drive
  further development

- I think it would be great to see a company providing support/services
  for a nixpkgs/nixos (derived) distribution

- increase presence of nixos. I think it is the best we have seen with
  respect to system management / deployment and it has big potential for
  creating well-defined reproducable development environments, but most
  people don't know about it.

- (impure) development environments for nasty pieces of software. To
  work right away on software that relies on a lot of things being
  present in /usr it would be great to have isolated environments where
  one profile is linked to /usr. While working on the software you can
  then purified it step by step until this is not necessary anymore.
  lxc[1] might help with that. The point is to enable you to continue to
  be productive on a piece of software without first spending a week
  explaining different build systems the concept of purity.

regards
florian

[1] http://lxc.teegra.net/
-- 
Florian Friesdorf <flo at chaoflow.net>
  GPG FPR: 7A13 5EEE 1421 9FC2 108D  BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: flo at chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20120629/c7a68b01/attachment.bin