[Nix-dev] How to submit nix expressions?

[cyril Romain]

Hi!

Peter Simons wrote:
>  (1) Just e-mail the patch or the nix file to this mailing list and trust
>      that someone commits it. This is what we're doing implicitly right now.
>   
pros:
  - fastest way to send a patch
  - can be committed quickly, because the mail is directly received to 
the core team
cons:
  if not committed within days for some reason (e.g. lack of time, badly 
written, etc.), the nix expression is 'lost' in the ML, with the 
following downside:
  - searching through mails is not really handy, especially if the mail 
does not follow a well establish style policy. And I think it's 
difficult to make all newcomers following such convention even if well 
established.
  - a nix expression rewritten from scratch because it has been lost or 
cannot be found easily is IHMO not acceptable. E.g. a newcomer that 
subscribe to the ML does not receive previous threads, and thus cannot 
be aware of such expression previously sent by mail.
  - sending new expression by mail can pollute the ML in the long run 
(using the bug tracker is better IHMO)

>  (2) Post the patch or the nix file to the bug tracker. This triggers a
>      notification, which (hopefully) leads to the bug being assigned to some
>      volunteer to handle the contribution. It's all very ISO-9001'ish, but
>      the process seems to work for Gentoo.
>   
pros:
  - many open source project send patches through the bug tracker, that 
does not pollute the main ML
  - the core team can comment the patch in the bug tracker, and teach 
newcomers (as well as people lurking bugs) what is wrong in their patches
  - newcomers can suggested improved patches
  - as you said more ISO-9001'ish thanks to the bug tracker (e.g. 
history of each bug/patchs)
  - a bug tracker is well suited for that (comments, patch triages, 
context, searching capabilities, etc.)
cons:
  - a nix expression can stay in bug tracker for some time

>  (3) Post the patch to a wiki. This is how the Emacs people collect elisp
>      files, and it seems to work fine.
>   
pros:
 - patch written in a collaborative way ? (bad if not applied and tested 
anyway)
cons:
  - I doubt a wiki can have a good search/comment/upload/bug status/bug 
dependencies features you have in a bug tracker


So I'm all for (2)

2 cents from a lurking user,

  Cyril