[Nix-commits] [NixOS/nixpkgs] abc3fa: rkt: 1.10.1 -> 1.11.0

[Rok Garbas]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: abc3faa2942f7fb95b478e256dc941797078231d
  
https://github.com/NixOS/nixpkgs/commit/abc3faa2942f7fb95b478e256dc941797078231d
  Author: Stefan Junker 
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
M pkgs/applications/virtualization/rkt/default.nix

  Log Message:
  ---
  rkt: 1.10.1 -> 1.11.0


  Commit: 04b30b2397439168af4854b4a7a9cd58c1e72b70
  
https://github.com/NixOS/nixpkgs/commit/04b30b2397439168af4854b4a7a9cd58c1e72b70
  Author: Stefan Junker 
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
M pkgs/applications/virtualization/rkt/default.nix

  Log Message:
  ---
  rkt: fix default stage1 location


  Commit: d5adf1348b5d59c15fe1738b00a96ddfcbfd8061
  
https://github.com/NixOS/nixpkgs/commit/d5adf1348b5d59c15fe1738b00a96ddfcbfd8061
  Author: Rok Garbas 
  Date:   2016-07-23 (Sat, 23 Jul 2016)

  Changed paths:
M pkgs/applications/virtualization/rkt/default.nix

  Log Message:
  ---
  Merge pull request #17192 from steveeJ/rkt-bump

rkt: 1.10.1 -> 1.11.0


Compare: https://github.com/NixOS/nixpkgs/compare/715e01cfc24e...d5adf1348b5d___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-dev] Requesting issue closing rights

[Profpatsch]

I like triaging, but not being able to close issues
is a nuisance. Not sure what access rights are needed,
but there’s probably a few people on the core team who
know me by now.

-- 
Proudly written in Mutt with Vim on NixOS.
Q: Why is this email five sentences or less?
A: http://five.sentenc.es
May take up to five days to read your message. If it’s urgent, call me.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] HaskellPackages in nix-dev, still maintained?

[Benno Fünfstück]

As far as I know, haskellPackages is still maintained. You've probably read
the message of the deprecation of the various LTS Haskell and Stackage
package sets: those were provided in addition to the haskellPackage set.

Regards,
Benno

andika.riyan  schrieb am Sa., 23. Juli 2016 00:53:

> Hi, i just want to clarify on what i read somewhere in this mailing list
> about the continuation of maintaining haskellPackages. From what i read
> haskellPackages is no longer maintained in nix, is it true?
>
> If so, then should we develop haskell like usual?
>
> Thanks,
> Rizy
>
>
>
> Sent from my Samsung device
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] HaskellPackages in nix-dev, still maintained?

[Profpatsch]

On 16-07-23 05:52am, andika.riyan wrote:
> 
> 
> Hi, i just want to clarify on what i read somewhere in this mailing list 
> about the continuation of maintaining haskellPackages. From what i read 
> haskellPackages is no longer maintained in nix, is it true?
> If so, then should we develop haskell like usual?
> Thanks,Rizy

Nope, haskellPackages are well maintained. We just removed support
for the stackage LTS distributions, which tended to be not as
stable or supported as we’d like.


-- 
Proudly written in Mutt with Vim on NixOS.
Q: Why is this email five sentences or less?
A: http://five.sentenc.es
May take up to five days to read your message. If it’s urgent, call me.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Profpatsch]

On 16-07-22 09:59am, Michael Walker wrote:
> If there are 1000+ open issues, it's hard to know what to prioritise.
> If inactive issues get closed, it at least helps cut down on things
> which may no longer be relevant (and if they are, someone finds the
> closed issue, comments in it, and it opens again).

I do think Github gives us the means for that.
You can sort by activity, by age, by label, by reactions …

To start triaging just sort by least recently updated
and work from start to finish. ;)

-- 
Proudly written in Mutt with Vim on NixOS.
Q: Why is this email five sentences or less?
A: http://five.sentenc.es
May take up to five days to read your message. If it’s urgent, call me.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Benno Fünfstück]

> The key here would be that we shouldn't get rattled if we get assigned an
> issue/PR. All it means is "I think you know more about this than I do, feel
> free to pass it on to someone else if aren't the right person or can't
> handle this with the appropriate urgency".
>

I don't think that assignment is the right tool for this job. Assignment in
my opinion should be used for the purpose of avoiding duplicated work: you
assign yourself to an issue if you plan on working on it, so that everyone
else knows that they shouldn't work on that particular task themselves.

An alternative approach is to just ping the relevant persons in the issue.
This way, they'll get notifications on updates to the issue. But I think
this partly already happens right now through mentionbot.

What I would like to see, however, is a clear set of guidelines that list a
person who has the final say over changes in each subset of nixpkgs. It is
not uncommon for PRs to stay around for months because it is unclear who
may approve/disapprove them (and saying no to PRs sometimes is important as
well). For example, this guideline could list someone responsible for each
language currently supported by nixpkgs (python, haskell, etc) or for parts
of the nixos module system or for the stdenv and so on.

Just my two cents,
Benno

>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] 715e01: Cleanup ucs-fonts (#16994)

[Robert Helgesson]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 715e01cfc24e3f75dc581bb98d1ec1d6a51c19ca
  
https://github.com/NixOS/nixpkgs/commit/715e01cfc24e3f75dc581bb98d1ec1d6a51c19ca
  Author: Robert Helgesson 
  Date:   2016-07-23 (Sat, 23 Jul 2016)

  Changed paths:
R pkgs/data/fonts/fontWrap/default.nix
M pkgs/data/fonts/ucs-fonts/default.nix
M pkgs/top-level/aliases.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  Cleanup ucs-fonts (#16994)

* ucs-fonts: remove use of `wrapFonts`

This cleans up the `ucs-fonts` package. In particular it removes the use
of `wrapFonts`, which depends on `builderDefs`. It also renames the
package attribute from `ucsFonts` to `ucs-fonts` (with the old name
being an alias for the newer).

* wrapFonts: remove

Removed since this attribute is no longer used and depends on
`builderDefs`.


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] e9b971: selenium: 2.44 to 2.52 (2.53 tested but not workin...

[Joachim Schiele]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: e9b9710e0f8fae0a4cff48d7ef70fedd4da118e7
  
https://github.com/NixOS/nixpkgs/commit/e9b9710e0f8fae0a4cff48d7ef70fedd4da118e7
  Author: Joachim Schiele 
  Date:   2016-07-23 (Sat, 23 Jul 2016)

  Changed paths:
M pkgs/top-level/python-packages.nix

  Log Message:
  ---
  selenium: 2.44 to 2.52 (2.53 tested but not working well; 2.44 fails because 
of firefox 36 extension signing enforcement (#15982)


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 44157c: smugline: init at 20160106 (#17191)

[obadz]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 44157c6da48bf2740c6a4c634c71648eb6756c1f
  
https://github.com/NixOS/nixpkgs/commit/44157c6da48bf2740c6a4c634c71648eb6756c1f
  Author: obadz 
  Date:   2016-07-23 (Sat, 23 Jul 2016)

  Changed paths:
M pkgs/top-level/all-packages.nix
M pkgs/top-level/python-packages.nix

  Log Message:
  ---
  smugline: init at 20160106 (#17191)

(required smugpy: init at 20131218)


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 2e48d8: haskell/Glob: fix build

[Benno Fünfstück]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 2e48d838d0c2ac0804e8c56eb4c8474d7f0d64fe
  
https://github.com/NixOS/nixpkgs/commit/2e48d838d0c2ac0804e8c56eb4c8474d7f0d64fe
  Author: Benno Fünfstück 
  Date:   2016-07-23 (Sat, 23 Jul 2016)

  Changed paths:
M pkgs/development/haskell-modules/configuration-common.nix

  Log Message:
  ---
  haskell/Glob: fix build


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 70a227: ecryptfs-helper: add meta

[obadz]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 70a2278e1875b7734eef4ca3ef54357d37127b74
  
https://github.com/NixOS/nixpkgs/commit/70a2278e1875b7734eef4ca3ef54357d37127b74
  Author: obadz 
  Date:   2016-07-23 (Sat, 23 Jul 2016)

  Changed paths:
M pkgs/tools/security/ecryptfs/default.nix
M pkgs/tools/security/ecryptfs/helper.nix

  Log Message:
  ---
  ecryptfs-helper: add meta


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] fd5cdc: ecryptfs-helper: init at 20160722

[obadz]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: fd5cdca91691a9b6b274ccbd0fbc094611487fd4
  
https://github.com/NixOS/nixpkgs/commit/fd5cdca91691a9b6b274ccbd0fbc094611487fd4
  Author: obadz <obadz-...@obadz.com>
  Date:   2016-07-23 (Sat, 23 Jul 2016)

  Changed paths:
A pkgs/tools/security/ecryptfs/helper.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  ecryptfs-helper: init at 20160722


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] f4d5d6: mysql: 5.5.49 -> 5.5.50 for CVEs (#17160)

[Graham Christensen]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: f4d5d6e73eb29f438174c0fdffdffd09ae2f6848
  
https://github.com/NixOS/nixpkgs/commit/f4d5d6e73eb29f438174c0fdffdffd09ae2f6848
  Author: Graham Christensen 
  Date:   2016-07-23 (Sat, 23 Jul 2016)

  Changed paths:
M pkgs/servers/sql/mysql/5.5.x.nix

  Log Message:
  ---
  mysql: 5.5.49 -> 5.5.50 for CVEs (#17160)

Problems include buffer overflows, null pointer dereferences, and
other bugfixes.

 - CVE-2016-3477
 - CVE-2016-3521
 - CVE-2016-3615
 - CVE-2016-5440

Details:
https://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-50.html


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 307e80: makeRustPlatform: Remove `self` argument (#16932)

[John Ericson]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 307e8098c50b4b6dece915b60e909390e69de0bb
  
https://github.com/NixOS/nixpkgs/commit/307e8098c50b4b6dece915b60e909390e69de0bb
  Author: John Ericson 
  Date:   2016-07-23 (Sat, 23 Jul 2016)

  Log Message:
  ---
  makeRustPlatform: Remove `self` argument (#16932)


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] f6d7a5: influxdb: parametrize default.nix to prepare packa...

[Christine Koppelt]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: f6d7a567a5ee5d7d46acfdca8e26fe428fbf3313
  
https://github.com/NixOS/nixpkgs/commit/f6d7a567a5ee5d7d46acfdca8e26fe428fbf3313
  Author: Christine Koppelt 
  Date:   2016-07-23 (Sat, 23 Jul 2016)

  Changed paths:
M pkgs/servers/nosql/influxdb/default.nix
A pkgs/servers/nosql/influxdb/v0.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  influxdb: parametrize default.nix to prepare packaging of 1.0 (#17161)


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] e6e873: erlangR19: init at 19.0.2 (#17123)

[Eric Bailey]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: e6e873beca9211f084a7e878a0c2fdc2b6b28ece
  
https://github.com/NixOS/nixpkgs/commit/e6e873beca9211f084a7e878a0c2fdc2b6b28ece
  Author: Eric Bailey 
  Date:   2016-07-23 (Sat, 23 Jul 2016)

  Changed paths:
A pkgs/development/interpreters/erlang/R19.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  erlangR19: init at 19.0.2 (#17123)

Add R19.nix, based on @binarin's R18.nix.

N.B. erlang/otp#1023 obviated the need for `rmAndPwdPatch` in R19.


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] e434ce: hostapd: 2.4 -> v2.5, fixes #17164

[Matthew Robbetts]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: e434ce8f49060dc265772a99d5c6067145230429
  
https://github.com/NixOS/nixpkgs/commit/e434ce8f49060dc265772a99d5c6067145230429
  Author: Matthew Robbetts 
  Date:   2016-07-23 (Sat, 23 Jul 2016)

  Changed paths:
M pkgs/os-specific/linux/hostapd/default.nix

  Log Message:
  ---
  hostapd: 2.4 -> v2.5, fixes #17164


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 44c5b7: osx-private-sdk: Fix hash (#17185)

[Daiderd Jordan]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 44c5b729b8249e15e43f358c7336aedfce91d43d
  
https://github.com/NixOS/nixpkgs/commit/44c5b729b8249e15e43f358c7336aedfce91d43d
  Author: Daiderd Jordan 
  Date:   2016-07-23 (Sat, 23 Jul 2016)

  Changed paths:
M pkgs/os-specific/darwin/osx-private-sdk/default.nix

  Log Message:
  ---
  osx-private-sdk: Fix hash (#17185)

- use fetchFromGitHub


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] d5ee0a: jp: init at 0.1.2

[Daiderd Jordan]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: d5ee0a27d0690012375c66c3947902d020e31fe9
  
https://github.com/NixOS/nixpkgs/commit/d5ee0a27d0690012375c66c3947902d020e31fe9
  Author: Casey Ransom 
  Date:   2016-07-21 (Thu, 21 Jul 2016)

  Changed paths:
A pkgs/development/tools/jmespath/default.nix
A pkgs/development/tools/jp/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  jp: init at 0.1.2

A json parson tool based on the JMESPATH query language.
http://jmespath.org/


  Commit: 20a0be5aee8668f9aa7523fd7dd83c3dfc683211
  
https://github.com/NixOS/nixpkgs/commit/20a0be5aee8668f9aa7523fd7dd83c3dfc683211
  Author: Daiderd Jordan 
  Date:   2016-07-23 (Sat, 23 Jul 2016)

  Changed paths:
A pkgs/development/tools/jmespath/default.nix
A pkgs/development/tools/jp/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  Merge pull request #17131 from cransom/jmespath

jp: init at 0.1.2


Compare: https://github.com/NixOS/nixpkgs/compare/9d53dc00c393...20a0be5aee86___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-dev] HaskellPackages in nix-dev, still maintained?

[andika.riyan]

Hi, i just want to clarify on what i read somewhere in this mailing list about 
the continuation of maintaining haskellPackages. From what i read 
haskellPackages is no longer maintained in nix, is it true?
If so, then should we develop haskell like usual?
Thanks,Rizy


Sent from my Samsung device___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] 9d53dc: dropbox: 4.4.29 -> 6.4.14 (#17165)

[Peter Hoeg]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 9d53dc00c3937c16960424d4f9814afe2639d5a8
  
https://github.com/NixOS/nixpkgs/commit/9d53dc00c3937c16960424d4f9814afe2639d5a8
  Author: Peter Hoeg 
  Date:   2016-07-23 (Sat, 23 Jul 2016)

  Changed paths:
M pkgs/applications/networking/dropbox/default.nix

  Log Message:
  ---
  dropbox: 4.4.29 -> 6.4.14 (#17165)


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 5c56c9: Adds pkg-config file and headers (#17173)

[Richard Zetterberg]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 5c56c906e308f168c13605e8c15efa499933cc01
  
https://github.com/NixOS/nixpkgs/commit/5c56c906e308f168c13605e8c15efa499933cc01
  Author: Richard Zetterberg 
  Date:   2016-07-23 (Sat, 23 Jul 2016)

  Changed paths:
M pkgs/development/libraries/libui/default.nix
A pkgs/development/libraries/libui/libui.pc

  Log Message:
  ---
  Adds pkg-config file and headers (#17173)


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] c38e6a: mysql: fix replication tests (#17174)

[ben smith]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: c38e6a2a6060434d842f173ebe5a4a7d4d99781a
  
https://github.com/NixOS/nixpkgs/commit/c38e6a2a6060434d842f173ebe5a4a7d4d99781a
  Author: ben smith 
  Date:   2016-07-23 (Sat, 23 Jul 2016)

  Changed paths:
M nixos/modules/services/databases/mysql.nix
M nixos/tests/mysql-replication.nix
M nixos/tests/mysql.nix

  Log Message:
  ---
  mysql: fix replication tests (#17174)

Eliminate race condition in replication test
Remove replication configuration from standalone test
Improve mysql command syntax consistency


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 38d896: connman-notify: init at 2014-06-23

[Daiderd Jordan]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 38d896aeee56701bcf2efe42528a1ffea063e2fa
  
https://github.com/NixOS/nixpkgs/commit/38d896aeee56701bcf2efe42528a1ffea063e2fa
  Author: José Romildo Malaquias 
  Date:   2016-07-20 (Wed, 20 Jul 2016)

  Changed paths:
A pkgs/tools/networking/connman-notify/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  connman-notify: init at 2014-06-23


  Commit: e8343fbb3882e932d23af6141d00a195528cc0b0
  
https://github.com/NixOS/nixpkgs/commit/e8343fbb3882e932d23af6141d00a195528cc0b0
  Author: Daiderd Jordan 
  Date:   2016-07-23 (Sat, 23 Jul 2016)

  Changed paths:
A pkgs/tools/networking/connman-notify/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  Merge pull request #17137 from romildo/new.connman-notify

connman-notify: init at 2014-06-23


Compare: https://github.com/NixOS/nixpkgs/compare/b45ee066bc8d...e8343fbb3882___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] b45ee0: itstool: 1.2.0 -> 2.0.2 (#17189)

[Miguel Madrid]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: b45ee066bc8d1665ec2384722236198987e8470f
  
https://github.com/NixOS/nixpkgs/commit/b45ee066bc8d1665ec2384722236198987e8470f
  Author: Miguel Madrid 
  Date:   2016-07-23 (Sat, 23 Jul 2016)

  Changed paths:
M pkgs/development/tools/misc/itstool/default.nix

  Log Message:
  ---
  itstool: 1.2.0 -> 2.0.2 (#17189)


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 8816df: shotwell: 0.23.2 -> 0.23.4 (#17190)

[Miguel Madrid]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 8816df20f30b33fd0eb9221b58e488201c909805
  
https://github.com/NixOS/nixpkgs/commit/8816df20f30b33fd0eb9221b58e488201c909805
  Author: Miguel Madrid 
  Date:   2016-07-23 (Sat, 23 Jul 2016)

  Changed paths:
M pkgs/applications/graphics/shotwell/default.nix

  Log Message:
  ---
  shotwell: 0.23.2 -> 0.23.4 (#17190)


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 9886c8: Add gocd agent and server service packages (#16273...

[Shawn Warren]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 9886c80daa8c5601f3a6de2a1512d00435da3432
  
https://github.com/NixOS/nixpkgs/commit/9886c80daa8c5601f3a6de2a1512d00435da3432
  Author: Shawn Warren 
  Date:   2016-07-23 (Sat, 23 Jul 2016)

  Changed paths:
M lib/maintainers.nix
M nixos/modules/misc/ids.nix
M nixos/modules/module-list.nix
A nixos/modules/services/continuous-integration/gocd-agent/default.nix
A nixos/modules/services/continuous-integration/gocd-server/default.nix
M nixos/release.nix
A nixos/tests/gocd-agent.nix
A nixos/tests/gocd-server.nix
A pkgs/development/tools/continuous-integration/gocd-agent/default.nix
A pkgs/development/tools/continuous-integration/gocd-server/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  Add gocd agent and server service packages (#16273)

GoCD is an open source continuous delivery server specializing in advanced 
workflow
modeling and visualization.  Update maintainers list to include swarren83.  
Update
module list to include gocd agent and server module.  Update packages list to 
include
gocd agent and server package.  Update version, revision and checksum for GoCD
release 16.5.0.


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] cb6fd6: libixp-hg: refactor to fetchurl as fetchg broke

[Joachim F]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: cb6fd6eaed5e1d130e63c2b61f07d06c9819040a
  
https://github.com/NixOS/nixpkgs/commit/cb6fd6eaed5e1d130e63c2b61f07d06c9819040a
  Author: Kovacsics Robert (NixOS) 
  Date:   2016-07-21 (Thu, 21 Jul 2016)

  Changed paths:
M pkgs/development/libraries/libixp-hg/default.nix

  Log Message:
  ---
  libixp-hg: refactor to fetchurl as fetchg broke


  Commit: 32a31353c45538ef84b19735b7971742d9143611
  
https://github.com/NixOS/nixpkgs/commit/32a31353c45538ef84b19735b7971742d9143611
  Author: Joachim F 
  Date:   2016-07-23 (Sat, 23 Jul 2016)

  Changed paths:
M pkgs/development/libraries/libixp-hg/default.nix

  Log Message:
  ---
  Merge pull request #17155 from KoviRobi/libixp-hg-update

libixp-hg: refactor to fetchurl as fetchg broke


Compare: https://github.com/NixOS/nixpkgs/compare/3bacfede380f...32a31353c455___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] a6df5b: wmii-hg: refactor to fetchurl as fetchhg broke

[Joachim F]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: a6df5b9f1d4a2ef62c368b080caf815497d86a17
  
https://github.com/NixOS/nixpkgs/commit/a6df5b9f1d4a2ef62c368b080caf815497d86a17
  Author: Kovacsics Robert (NixOS) 
  Date:   2016-07-21 (Thu, 21 Jul 2016)

  Changed paths:
M pkgs/applications/window-managers/wmii-hg/default.nix

  Log Message:
  ---
  wmii-hg: refactor to fetchurl as fetchhg broke


  Commit: c4c378b6138ac224f2de13ecf172a760104dae3e
  
https://github.com/NixOS/nixpkgs/commit/c4c378b6138ac224f2de13ecf172a760104dae3e
  Author: Joachim F 
  Date:   2016-07-23 (Sat, 23 Jul 2016)

  Changed paths:
M pkgs/applications/window-managers/wmii-hg/default.nix

  Log Message:
  ---
  Merge pull request #17156 from KoviRobi/wmii-hg-update

wmii-hg: refactor to fetchurl as fetchhg broke


Compare: https://github.com/NixOS/nixpkgs/compare/32a31353c455...c4c378b6138a___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 3e938a: metamorphose2: init at 0.9.0beta

[Daiderd Jordan]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 3e938ad7f1becd1a0560426174479373ce9a8d67
  
https://github.com/NixOS/nixpkgs/commit/3e938ad7f1becd1a0560426174479373ce9a8d67
  Author: Ram Kromberg 
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
A pkgs/applications/misc/metamorphose2/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  metamorphose2: init at 0.9.0beta


  Commit: 3bacfede380f69ca211d486d4d982ed29e111b25
  
https://github.com/NixOS/nixpkgs/commit/3bacfede380f69ca211d486d4d982ed29e111b25
  Author: Daiderd Jordan 
  Date:   2016-07-23 (Sat, 23 Jul 2016)

  Changed paths:
A pkgs/applications/misc/metamorphose2/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  Merge pull request #17171 from RamKromberg/init/metamorphose2

metamorphose2: init at 0.9.0beta


Compare: https://github.com/NixOS/nixpkgs/compare/206bc64b48af...3bacfede380f___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 87e008: guile-gnome-platform: 20150123 -> 2.16.4

[Daiderd Jordan]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 87e008d538c637ae36686416245bfc11ed6ae91a
  
https://github.com/NixOS/nixpkgs/commit/87e008d538c637ae36686416245bfc11ed6ae91a
  Author: Andrew Miloradovsky 
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
M lib/maintainers.nix
M pkgs/development/guile-modules/guile-gnome/default.nix

  Log Message:
  ---
  guile-gnome-platform: 20150123 -> 2.16.4

No more `git clone`. Fetch a tarball.


  Commit: 206bc64b48af482272eefed51d0de71891d09fec
  
https://github.com/NixOS/nixpkgs/commit/206bc64b48af482272eefed51d0de71891d09fec
  Author: Daiderd Jordan 
  Date:   2016-07-23 (Sat, 23 Jul 2016)

  Changed paths:
M pkgs/development/guile-modules/guile-gnome/default.nix

  Log Message:
  ---
  Merge pull request #17177 from amiloradovsky/new-guile-gnome

guile-gnome-platform: 20150123 -> 2.16.4


Compare: https://github.com/NixOS/nixpkgs/compare/ded7d04f812d...206bc64b48af___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 0a9eba: htop: 2.0.1 -> 2.0.2

[Peter Simons]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 0a9eba2aa4cc2d5a4afb1ef1566dbe8166155328
  
https://github.com/NixOS/nixpkgs/commit/0a9eba2aa4cc2d5a4afb1ef1566dbe8166155328
  Author: mimadrid 
  Date:   2016-07-23 (Sat, 23 Jul 2016)

  Changed paths:
M pkgs/tools/system/htop/default.nix

  Log Message:
  ---
  htop: 2.0.1 -> 2.0.2


  Commit: ded7d04f812de5d55730c03f916156b4478e7373
  
https://github.com/NixOS/nixpkgs/commit/ded7d04f812de5d55730c03f916156b4478e7373
  Author: Peter Simons 
  Date:   2016-07-23 (Sat, 23 Jul 2016)

  Changed paths:
M pkgs/tools/system/htop/default.nix

  Log Message:
  ---
  Merge pull request #17188 from mimadrid/update/htop-2.0.2

htop: 2.0.1 -> 2.0.2


Compare: https://github.com/NixOS/nixpkgs/compare/8593eb92e837...ded7d04f812d___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 1bedec: stellarium: wrap binary using `wrapQtProgram`

[Peter Simons]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 1bedecb4f9178da2e50a9b14873e8186bc619e8a
  
https://github.com/NixOS/nixpkgs/commit/1bedecb4f9178da2e50a9b14873e8186bc619e8a
  Author: Robert Helgesson 
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
M pkgs/applications/science/astronomy/stellarium/default.nix

  Log Message:
  ---
  stellarium: wrap binary using `wrapQtProgram`

Fixes #13582 where Stellarium segfaults when starting.


  Commit: 1012508356abd1e24c39df813c89d27e948a4017
  
https://github.com/NixOS/nixpkgs/commit/1012508356abd1e24c39df813c89d27e948a4017
  Author: Robert Helgesson 
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
M pkgs/applications/science/astronomy/stellarium/default.nix

  Log Message:
  ---
  stellarium: 0.14.2 -> 0.14.3


  Commit: 8593eb92e837b3806536211db01cefba2f45994b
  
https://github.com/NixOS/nixpkgs/commit/8593eb92e837b3806536211db01cefba2f45994b
  Author: Peter Simons 
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
M pkgs/applications/science/astronomy/stellarium/default.nix

  Log Message:
  ---
  Merge pull request #17186 from rycee/fix-and-bump/stellarium

Fix and version bump Stellarium


Compare: https://github.com/NixOS/nixpkgs/compare/597b0b0144b5...8593eb92e837___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-dev] nixops: argument list too long

[Eike]

Hello,

I start using nixops and want to deploy from one machine to
another. Both have NixOS running. This is the nix file I feed to nixops
create:

{
  network.description = "Lenni";
  lenni =
{ config, pkgs, ... }:
{
  imports = [ ./configuration.nix ];

  deployment.targetEnv = "none";
  deployment.targetHost = "192.168.1.72";
};
}

The configuration.nix is the same file I used with `nixos-rebuild`
directly on the target machine.

When I run nixops deploy it builds the configuration and then quits with
“[Errno 7] Argument list too long” error:

$ nixops deploy -d lenni
building all machine configurations...
lenni> copying closure...
error: [Errno 7] Argument list too long

I'm not sure what I did wrong and could not find anything useful when
searching the internet. Can someone help me out here?

Thanks and regards
Eike


-- 
gpg: AD7AC35E
finger print: 137F BB0B 1639 D25F DC5D E59C B412 C5F5 AD7A C35E
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] 597b0b: gradm: fix build on i686

[Joachim Fasting]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 597b0b0144b514cdf77d4bead891b50e83c58969
  
https://github.com/NixOS/nixpkgs/commit/597b0b0144b514cdf77d4bead891b50e83c58969
  Author: Joachim Fasting 
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  gradm: fix build on i686

This is a regression introduced by my update at 
e4b7b7b028e0ce724ea6e4bfad156b78d7ef7b8e

Turns out this was actually required to build the package on i686; without it,
the build fails with

```
/nix/store/[...]-flex-2.6.0/lib/libfl.so: undefined reference to `yylex'
```

for some reason ... the easiest solution is to just use flex_2_5_35, which does
build successfully.


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 17b127: evilwm: init at 1.1.1 (#17104)

[Joachim F]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 17b127205da6b0168898bd0bdf2f0ccd5170f09f
  
https://github.com/NixOS/nixpkgs/commit/17b127205da6b0168898bd0bdf2f0ccd5170f09f
  Author: Andrew Miloradovsky 
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
M lib/maintainers.nix
A pkgs/applications/window-managers/evilwm/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  evilwm: init at 1.1.1 (#17104)

Minimalist window manager for the X Window System


  Commit: 46c924c4a25ef9daaa65bf3e0a80e4bcc8e3b1e4
  
https://github.com/NixOS/nixpkgs/commit/46c924c4a25ef9daaa65bf3e0a80e4bcc8e3b1e4
  Author: Joachim F 
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
M lib/maintainers.nix
A pkgs/applications/window-managers/evilwm/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  Merge pull request #17178 from amiloradovsky/add-evilwm

evilwm: init at 1.1.1 (#17104)


Compare: https://github.com/NixOS/nixpkgs/compare/d67cdde7f9b2...46c924c4a25e___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 19f074: gd: 2.2.2 -> 2.2.3

[Joachim F]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 19f074a5c3fa5347a61b52d43e344e0292e43d72
  
https://github.com/NixOS/nixpkgs/commit/19f074a5c3fa5347a61b52d43e344e0292e43d72
  Author: Michael Stone 
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
M pkgs/development/libraries/gd/default.nix

  Log Message:
  ---
  gd: 2.2.2 -> 2.2.3


  Commit: d67cdde7f9b22d583d676fef7894f1965baa349b
  
https://github.com/NixOS/nixpkgs/commit/d67cdde7f9b22d583d676fef7894f1965baa349b
  Author: Joachim F 
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
M pkgs/development/libraries/gd/default.nix

  Log Message:
  ---
  Merge pull request #17184 from mstone/update/gd-2.2.3

gd: 2.2.2 -> 2.2.3


Compare: https://github.com/NixOS/nixpkgs/compare/7f681d215bee...d67cdde7f9b2___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 7f681d: nix-generate-from-cpan: clean up build inputs

[Robert Helgesson]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 7f681d215bee91b1126d4142e580ce9a19186505
  
https://github.com/NixOS/nixpkgs/commit/7f681d215bee91b1126d4142e580ce9a19186505
  Author: Robert Helgesson 
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
M maintainers/scripts/nix-generate-from-cpan.pl

  Log Message:
  ---
  nix-generate-from-cpan: clean up build inputs

In particular remove those build inputs that are already mentioned among
the propagated build inputs. Fixes #10373.


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] c1d24e: darwin: R: provide gettext and gfortran as buildIn...

[Peter Simons]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: c1d24efd6a28372019b9c8cd110737b1739105dc
  
https://github.com/NixOS/nixpkgs/commit/c1d24efd6a28372019b9c8cd110737b1739105dc
  Author: Michael Stone 
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
M pkgs/development/r-modules/default.nix
M pkgs/development/r-modules/generic-builder.nix

  Log Message:
  ---
  darwin: R: provide gettext and gfortran as buildInputs on Darwin.

As discussed in #10623, many R modules fail to build on Darwin without the
libraries and compilers provided by these packages.

For more detail, please see comment:

  https://github.com/NixOS/nixpkgs/pull/10623#issuecomment-172375342


  Commit: 649db354bf1ae7e7a5752564b7f2e9f5caf332a1
  
https://github.com/NixOS/nixpkgs/commit/649db354bf1ae7e7a5752564b7f2e9f5caf332a1
  Author: Peter Simons 
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
M pkgs/development/r-modules/default.nix
M pkgs/development/r-modules/generic-builder.nix

  Log Message:
  ---
  Merge pull request #17183 from mstone/darwin/fix-r-gettext-gfortran

darwin: R: provide gettext and gfortran as buildInputs on Darwin.


Compare: https://github.com/NixOS/nixpkgs/compare/575e0e27b146...649db354bf1a___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 575e0e: jabref: 3.4 -> 3.5

[Gabriel Ebner]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 575e0e27b146ea20b4d5274ea496e5d838e39273
  
https://github.com/NixOS/nixpkgs/commit/575e0e27b146ea20b4d5274ea496e5d838e39273
  Author: Gabriel Ebner 
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
M pkgs/applications/office/jabref/default.nix

  Log Message:
  ---
  jabref: 3.4 -> 3.5


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] adf3b2: rakudo: 2016.04 -> 2016.07

[Graham Christensen]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: adf3b24f79faa7865da52f8fd36ee450a769b23b
  
https://github.com/NixOS/nixpkgs/commit/adf3b24f79faa7865da52f8fd36ee450a769b23b
  Author: Rahul Gopinath 
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
M pkgs/development/interpreters/rakudo/default.nix

  Log Message:
  ---
  rakudo: 2016.04 -> 2016.07


  Commit: ae3f767a42e3fc4f5a6517c533959bd24f0fa665
  
https://github.com/NixOS/nixpkgs/commit/ae3f767a42e3fc4f5a6517c533959bd24f0fa665
  Author: Graham Christensen 
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
M pkgs/development/interpreters/rakudo/default.nix

  Log Message:
  ---
  Merge pull request #17179 from vrthra/rakudo

rakudo: 2016.04 -> 2016.07


Compare: https://github.com/NixOS/nixpkgs/compare/e4b7b7b028e0...ae3f767a42e3___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

Re: [Nix-dev] Too many open issues

[obadz]

On Fri, Jul 22, 2016 at 6:21 PM, Guillaume Maudoux (Layus) <
layus...@gmail.com> wrote:

> Furthermore, I think that every issue should be assigned to someone. Being
> assigned to an issue would mean that you are responsible for its progress,
> like pinging the maintainers, not for fixing the problem by yourself (but
> you still can).
>

I think this is a key point. While we can't really hope for 0 open
issues/PR, maybe we should be striving towards 0 unassigned issues/PR.

May I suggest a policy where we "liberally" assign issues/PR to each other.
The lifecycle of an issue/PR would then look something like this:

   - First triager comes up with his best guess as to who could be useful
   on the issue/PR, maybe based on `git log`
   - First assignee may decide that he isn't the best person to look at
   this and reassigns further
   - Hopefully the iterative process lets assignment converge towards the
   right expert

Of course the downside of such a process is that major contributors whose
time is already stretched thin are going to end up with a
disproportionately high share of issues/PRs assigned to them. However they
are also most likely to know who is capable of tackling the issue/PR and
further re-assign it, or to request help by adding a tag like `status:
need-help`?

The key here would be that we shouldn't get rattled if we get assigned an
issue/PR. All it means is "I think you know more about this than I do, feel
free to pass it on to someone else if aren't the right person or can't
handle this with the appropriate urgency".

Thoughts?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Guillaume Maudoux (Layus)]

Hi,

May I suggest that the culprit is the tool itself ? Clearly GitHub does a poor 
job at managing and displaying issues. It works well for pull requests and code 
exploration, but not for issues.

What we need is to maintain a pool of issues that need attention. Ideally this 
pool is quite small (max 20), and contains issues that require some action, or 
could benefit from anyone's input.

For example, a new issue requires attention. When the discussion has started, 
it can be removed from the pool.
Issues with no activity also require attention eventually.

Furthermore, I think that every issue should be assigned to someone. Being 
assigned to an issue would mean that you are responsible for its progress, like 
pinging the maintainers, not for fixing the problem by yourself (but you still 
can).

We really need a way to get a short list of items requiring global attention, 
then triage/dispatch it elsewhere to keep focus on interesting things.
If GitHub cannot do that, we may need another tool.

Regards,

-- Layus.___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Azul]

triage exists to help manipulating a backlog, it is just another tool to
make sure team members are only working valuable issues and not spend the
time bikshedding, it also prevents duplication.
auto-closing issues due to being no longer applicable, or simply to reduce
the size of the backlog is another tool.
theming or (tagging) issues another process that helps to keep team members
with knowhow in a particular area aligned with the issues they care or are
able to fix in the shortest amount of time compared to other
dev/maintainers in the team.
voting is another good way to measure how important an issue is for a
number of users.
with these processes in place, someone responsible for managing the backlog
can look to every issue opened and work their way to reduce the overall
size of that backlog. then, it can be tagged and grouped into themes,
languages, maintainers, expertise and so on so that maintainers can find
then quickly.
if the backlog is then sorted by votes, common sense or other means then it
can be sliced and batched so that there is always a chunk of issues
available to be worked on ( attempt readers probably noticed by now I am a
kanban boy).

open source prj on github have the best tooling available to manage these
workflows, tools like the 'autoclose machine' mentioned here, zenhub for
managing work in progress in a simple board and others  are out there and
usually free for open source projects.

from this thread it seems to me that the most useful action would be to
nominate someone to manage that backlog and make a constant effort to bring
it down to a workable size, and always ordered by the ones that need to be
tackled first.
On 22 Jul 2016 17:58, "Guillaume Maudoux (Layus)" 
wrote:

> Hi,
>
> I have tried code triage for some weeks, and finally stopped using it.
>
> Yes, it allows to spread attention to many issues, but many issues do not
> need attention, either because they are already in progress, or because
> nobody really cares.
>
> Some issues are even weirder, like the 200 issues opened automatically for
> wiki migration. These are the only one that could benefit from auto close.
>
> Codetriage is not the solution, and not really a solution.
>
> Regards,
>
> -- Layus.
>
> Le 22 juillet 2016 20:12:18 UTC+07:00, Kevin Cox  a
> écrit :
>>
>> On 22/07/16 08:55, Alexey Shmalko wrote:
>>
>>>  This one: https://www.codetriage.com/nixos/nixpkgs
>>
>>
>>
>> That's it! I have subscribed to get a couple issues a day so hopefully I
>> can help a bit. This site seems like a nice way to spread the load.
>>
>> It's open source too, and I just opened an issue asking them to
>> implement filters as I'm not really interesting in seeing in-progress
>> issues.
>>
>> https://github.com/codetriage/codetriage/issues/498
>>
>>
>> --
>>
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Guillaume Maudoux (Layus)]

Hi,

I have tried code triage for some weeks, and finally stopped using it.

Yes, it allows to spread attention to many issues, but many issues do not need 
attention, either because they are already in progress, or because nobody 
really cares.

Some issues are even weirder, like the 200 issues opened automatically for wiki 
migration. These are the only one that could benefit from auto close.

Codetriage is not the solution, and not really a solution.

Regards,

-- Layus.

Le 22 juillet 2016 20:12:18 UTC+07:00, Kevin Cox  a écrit 
:
>On 22/07/16 08:55, Alexey Shmalko wrote:
>> This one: https://www.codetriage.com/nixos/nixpkgs
>>
>
>That's it! I have subscribed to get a couple issues a day so hopefully
>I
>can help a bit. This site seems like a nice way to spread the load.
>
>It's open source too, and I just opened an issue asking them to
>implement filters as I'm not really interesting in seeing in-progress
>issues.
>
>https://github.com/codetriage/codetriage/issues/498
>
>
>
>
>
>
>___
>nix-dev mailing list
>nix-dev@lists.science.uu.nl
>http://lists.science.uu.nl/mailman/listinfo/nix-dev
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] e4b7b7: gradm: 3.1-201507191652 -> 3.1-201607172312

[Joachim Fasting]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: e4b7b7b028e0ce724ea6e4bfad156b78d7ef7b8e
  
https://github.com/NixOS/nixpkgs/commit/e4b7b7b028e0ce724ea6e4bfad156b78d7ef7b8e
  Author: Joachim Fasting 
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
M pkgs/os-specific/linux/gradm/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  gradm: 3.1-201507191652 -> 3.1-201607172312


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 24e632: offlineimap: 6.7.0.1 -> 6.7.0.2

[Graham Christensen]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 24e632b242faeb045ed48bc6bc85d31aa122607c
  
https://github.com/NixOS/nixpkgs/commit/24e632b242faeb045ed48bc6bc85d31aa122607c
  Author: Damien Cassou 
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
M pkgs/tools/networking/offlineimap/default.nix

  Log Message:
  ---
  offlineimap: 6.7.0.1 -> 6.7.0.2


  Commit: 0cbea742ab3e1def61f24bb6423d3bdc17458f21
  
https://github.com/NixOS/nixpkgs/commit/0cbea742ab3e1def61f24bb6423d3bdc17458f21
  Author: Graham Christensen 
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
M pkgs/tools/networking/offlineimap/default.nix

  Log Message:
  ---
  Merge pull request #17175 from DamienCassou/offlineimap-6.7.0.2

offlineimap: 6.7.0.1 -> 6.7.0.2


Compare: https://github.com/NixOS/nixpkgs/compare/99bfa00bf6b3...0cbea742ab3e___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

Re: [Nix-dev] Too many open issues

[Paul Dufresne]

I did triaging in the past in a big distro.
What was frustrating was that I had the feeling that most bugs were
fixed by themselves (like if they were
rediscovered and fix upstream, or care about when developers
encounters them by themselves).

Thinking about it, I have come to the conclusion that it is probably
part of how teams organize like:
-documenters
-bug triagers
-developers
etc.

I think it would help to organize around subject:
-administrating tools
--cloud
--other
-games
-desktops
--kde
--gnome-shell
--mate
--cinnamon
--other
-printing
-audio/video
-office software
-science
--astronomy
--medical
--electronic
--other
-other

Developers are likely to prefer to organize around programming languages.
I guess it is ok to let them aggregate by programming language, but
that way, should be
kept less important than the previous category I think.

So it is important that bug triagers, documentation, etc. are on the
same teams as developers that have
access to infrastructure, and that suggestions can become real changes.

I believe that to achieve this, a forum is a much better place than a
mailing list.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] how to go about refactoring nixos-container?

[Eric Merritt]

Kosyrev,

We are probably doing something pretty similar. We use nix to generate our 
images at all the various levels from testing through production. We use 
nixos-container as a cheap way to standup our system on the desktop. To that 
end I have been making changes. In the very short term, my goals are just to 
make the nixos-container command a bit more tractable and trust worthy. In the 
mid term I want to be able to spin up a container without root privileges. In 
the very long term, I want to orchestrate local infrastructure in the same way 
I do my remote infrastructure. All of this starts by making nixos-container a 
bit nicer to live in.

Eric




Sent from [ProtonMail](https://protonmail.com), encrypted email based in 
Switzerland.


 Original Message 
Subject: Re: [Nix-dev] how to go about refactoring nixos-container?
Local Time: July 21, 2016 3:16 PM
UTC Time: July 21, 2016 10:16 PM
From: _deepf...@feelingofgreen.ru
To: e...@merritt.tech
CC: nix-dev@lists.science.uu.nl,dpauk...@ptsecurity.com

Eric Merritt  writes:
> Maintainers,
>
> I have been spending a fair amount of time adding bits to
> `nixos-container` and expect to be spending more time there as I have
> started using it heavily for standing up and testing groups of
> systems. It's been tempting to refactor the command. Before doing that
> I wanted to ask the maintainers the path with the highest likelihood
> of being accepted, to avoid waisting a lot of time on dead ends.

Eric,

We, at Positive Technologies[1], are quite interested in employing Nix
for rootfs generation, and we already have some unreleased adaptations.

I think it would be quite nice if you had voiced your plans, so we could
coordinate in this effort -- that is, if I'm not mistaken and our goals
do indeed intersect.

Cc-ing Denis, who's doing work on this.

--
1. Using non-corporate email because it's subscribed to the list.
--
с уважениeм / respectfully / Z poważaniem,
Косырев Сергей___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Matthias Beyer]

On 22-07-2016 13:26:13, Wout Mertens wrote:
> Ok, how about this: We split nixpkgs in nixpkgs-core and nixpkgs-community

I would argue against this.

As others have explained (and as Graham Christensen wrote in the next 
mail in this thread) size is not a bad thing and we really should be 
proud.

Reaching out to others and asking how they do it is way better IMO.
Splitting the problem into smaller ones will not solve the issue.

Also: "Moving" packages between repositories is not as trivial as you 
might think. We would lose history _all the time_, and at least I 
consider this a big NO-NO.

-- 
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer

Proudly sent with mutt.
Happily signed with gnupg.


signature.asc
Description: PGP signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Matthias Beyer]

On 22-07-2016 12:25:25, Wout Mertens wrote:
> We could run this tool first with a 1-year timeout, then one week 
> later 6 months etc until we get to 14 days, so that people are not 
> overwhelmed by all the close notices.

This is a neat idea IMHO.

--
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer

Proudly sent with mutt.
Happily signed with gnupg.


signature.asc
Description: PGP signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Matthias Beyer]

On 22-07-2016 14:18:55, Damien Cassou wrote:
> Wout Mertens  writes:
> 
> > We have 1238 open issues and 286 open PRs.
> > That is just too much to reason about.
> >
> > How about using something like https://github.com/twbs/no-carrier which
> > auto-closes after 14 days of inactivity, and reopens on a new comment?
> 
> I agree with you about auto-closing old issues but I think 14 days is
> way too short. For me, an issue must be automatically closed
> 
> - if nobody cares enough to say either that he is impacted too or is
>   still impacted
> 
> - if nobody cares enough to fix the issue
> 
> There is not enough man power for nixpkgs to be bug free. Automatically
> closing issues means open issues are the ones people care about.
> Moreover, the tools auto-closing issues must warn a few days before
> closing the issue to raise awareness of the open issues.
> 
> One day I closed an issue because nobody cared for months (even I didn't
> care enough even though I reported it). Someone reopened it saying that
> lack of care was not a reason to close an issue and someone else fixed
> the issue the same day. So, closing can even encourage fixing :-).
> 

I agree with you. I wouldn't draw the line at 14 days, it is way to 
short. We have sometimes unstable beeing not updated for up to 4 
weeks... and I guess that should also be the line. let it be 28 days, 
reporting after 25 days that the issue will be closed and another 3 
until it is closed, maybe.

-- 
Mit freundlichen Grüßen,
Kind regards,
Matthias Beyer

Proudly sent with mutt.
Happily signed with gnupg.


signature.asc
Description: PGP signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Graham Christensen]

I see the growth in contributions and PRs as a great indicator of a healthy
project.

We get around 1,000 new issues/PRs every 1.5 months. The 33 PRs from the
last ~24 hours were contributed by 24 different people[0]. Our issuestats
badges say we close PRs in about 18 hours, and issues in 5 days.

Those are pretty good numbers, I think.

Here are some other projects and numbers:

 - Docker has 1,800 open issues, 142 open PRs
 - Ruby on Rails has 477 open issues, 632 open PRs

Here are some other _distributions_:

 - Debian has 90,000 bugs (?) https://www.debian.org/Bugs/
 - Redhat has 25,000 bugs
 - Gentoo has 20,000 bugs

I think we should be really proud of the number of quality contributions[1]
we get, and how effectively and promptly we can merge so many of them.

Some opinions:

 - I think we should be seeking out information about how other large,
popular open source projects deal with issue and PR load. I've reached out
to people at Docker, Drupal, and Emacs for feedback.
 - I think auto-closing issues which don't get attention is
passive-aggressive. I would be more amenable to a process of tagging issues
as "Needs response from submitter" and auto-closing if that isn't resolved.
Docker has/had a bot to let users add labels to issues.
 - I think splitting the repository isn't going to do us any favors and
just moves the burden around, and raises the difficulty of submitting
issues and updates. I don't think making it more difficult is in our best
interest.

Best,
Graham Christensen

[0]: This is amazing! No small group is submitting the bulk of the PRs.
Contributors:
https://gist.github.com/grahamc/cff852defb726dd5ae64b5a3287651d4
[1]: https://github.com/docker/docker/pulls?q=is%3Apr+is%3Aclosed


On Fri, Jul 22, 2016 at 8:26 AM Wout Mertens  wrote:

> Ok, how about this: We split nixpkgs in nixpkgs-core and nixpkgs-community
>
> For any package or service, there need to be at least 3 active
> maintainers, or it goes out of nixpkgs-core into a nixpkgs-community repo.
>
> Hydra builds nixos from nixpkgs-core, and nixpkgs from both combined.
>
> nixpgks-core issues are mostly solved by the maintainers or of course any
> PR that is good enough.
>
> In the nixpkgs-community we implement the
> http://rfc.zeromq.org/spec:42/C4/ process, meaning that any PR that
> fulfills all the objective goals gets merged. It worked well for ZeroMQ,
> and takes the guesswork out of PRs. Tree maintainers only need to evaluate
> the C4 objectives
>  of the PR, and
> if they are fulfilled, merge.
>
> Packages get moved between the two repos as support status changes.
>
> That way, we have a small "trust base" for server systems, and a large
> "community base" for the latest and greatest. NixOS is so flexible that you
> can mix and match as you wish.
>
> On Fri, Jul 22, 2016 at 3:12 PM Kevin Cox  wrote:
>
>> On 22/07/16 08:55, Alexey Shmalko wrote:
>> > This one: https://www.codetriage.com/nixos/nixpkgs
>> >
>>
>> That's it! I have subscribed to get a couple issues a day so hopefully I
>> can help a bit. This site seems like a nice way to spread the load.
>>
>> It's open source too, and I just opened an issue asking them to
>> implement filters as I'm not really interesting in seeing in-progress
>> issues.
>>
>> https://github.com/codetriage/codetriage/issues/498
>>
>>
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] 1000 EUR for a week of work with Nix and NixOps

[zimbatm]

s/start the machines either trough nixops/start the machines either trough
terraform/

On Fri, 22 Jul 2016 at 15:06 zimbatm  wrote:

> Hi Seroka,
>
> I would like to recommend terraform for the orchestration layer and then
> use a pull model to deploy nix channels to your servers.
>
> nixops is fantastic and I use it to deploy to my two servers but I don't
> think it's the best solution to manage a constantly-changing fleet of
> servers. When deploying a bigger infrastructure you want things like:
> support for auto-scaling and shared deploy state between machines. Also
> terraform has a much richer community and supports more cloud providers out
> of the box.
>
> The approach would be to start the machines either trough nixops or trough
> provider-specific tools like Amazon's ASG and provision the
> configuration.nix file during boot and finally run `nixos-rebuild switch
> --upgrade`. The configuration would be setup to pull from one of your
> private hydra channels. You can also use terraform to ssh into all of the
> boxes if you want to control the rate of deploys.
>
> Let me know if you want more details. It's pretty clear in my head but
> didn't have the chance to implement this yet. I think Rok Garbas did
> something similar for his personal setup if you want to talk to him.
>
> Best,
> z
>
>
>
> On Fri, 22 Jul 2016 at 07:28 Arseniy Seroka  wrote:
>
>> Fellow nixers,
>>
>> I'm Arseniy Seroka, founder of Serokell.
>> We already use Nix on a daily basis while working on our projects. For
>> one such
>> project, rscoin[1], we need to come up with a way of deploying and
>> running it
>> on a multitude of cloud services. Naturally, we're looking at NixOps to
>> do that.
>> We have a pretty tight deadline — we need to get it done by July 29th,
>> hence we're seeking for aid in this goal.
>> We want to hire a nixer with a good background in NixOps for the next
>> week and
>> we intend to pay up to 1000 EUR for forty hours of work.
>> We're also open for some follow-up contracts with nixers, such as
>> contributing
>> to our long-running Haskell Overlay initiative or setting up elaborate
>> Hydra-based CI infrastructure. RSCoin is a great project that uses
>> Haskell and
>> PureScript, we think you'll have fun contributing to its usability and
>> deployability!
>>
>> [1] https://github.com/input-output-hk/rscoin-haskell
>>
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] 1000 EUR for a week of work with Nix and NixOps

[zimbatm]

Hi Seroka,

I would like to recommend terraform for the orchestration layer and then
use a pull model to deploy nix channels to your servers.

nixops is fantastic and I use it to deploy to my two servers but I don't
think it's the best solution to manage a constantly-changing fleet of
servers. When deploying a bigger infrastructure you want things like:
support for auto-scaling and shared deploy state between machines. Also
terraform has a much richer community and supports more cloud providers out
of the box.

The approach would be to start the machines either trough nixops or trough
provider-specific tools like Amazon's ASG and provision the
configuration.nix file during boot and finally run `nixos-rebuild switch
--upgrade`. The configuration would be setup to pull from one of your
private hydra channels. You can also use terraform to ssh into all of the
boxes if you want to control the rate of deploys.

Let me know if you want more details. It's pretty clear in my head but
didn't have the chance to implement this yet. I think Rok Garbas did
something similar for his personal setup if you want to talk to him.

Best,
z



On Fri, 22 Jul 2016 at 07:28 Arseniy Seroka  wrote:

> Fellow nixers,
>
> I'm Arseniy Seroka, founder of Serokell.
> We already use Nix on a daily basis while working on our projects. For
> one such
> project, rscoin[1], we need to come up with a way of deploying and
> running it
> on a multitude of cloud services. Naturally, we're looking at NixOps to
> do that.
> We have a pretty tight deadline — we need to get it done by July 29th,
> hence we're seeking for aid in this goal.
> We want to hire a nixer with a good background in NixOps for the next
> week and
> we intend to pay up to 1000 EUR for forty hours of work.
> We're also open for some follow-up contracts with nixers, such as
> contributing
> to our long-running Haskell Overlay initiative or setting up elaborate
> Hydra-based CI infrastructure. RSCoin is a great project that uses
> Haskell and
> PureScript, we think you'll have fun contributing to its usability and
> deployability!
>
> [1] https://github.com/input-output-hk/rscoin-haskell
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] 1000 EUR for a week of work with Nix and NixOps

[Joachim Schiele]

we are interested. that is:
paul and me, we run nixcloud.io, do lots of deployment and can help you.

if you are interested, just let us know.

On 22.07.2016 08:30, Arseniy Seroka wrote:
> Fellow nixers,
> 
> I'm Arseniy Seroka, founder of Serokell.
> We already use Nix on a daily basis while working on our projects. For
> one such
> project, rscoin[1], we need to come up with a way of deploying and
> running it
> on a multitude of cloud services. Naturally, we're looking at NixOps to
> do that.
> We have a pretty tight deadline — we need to get it done by July 29th,
> hence we're seeking for aid in this goal.
> We want to hire a nixer with a good background in NixOps for the next
> week and
> we intend to pay up to 1000 EUR for forty hours of work.
> We're also open for some follow-up contracts with nixers, such as
> contributing
> to our long-running Haskell Overlay initiative or setting up elaborate
> Hydra-based CI infrastructure. RSCoin is a great project that uses
> Haskell and
> PureScript, we think you'll have fun contributing to its usability and
> deployability!
> 
> [1] https://github.com/input-output-hk/rscoin-haskell
> 
> 
> 
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
> 


___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Wout Mertens]

Ok, how about this: We split nixpkgs in nixpkgs-core and nixpkgs-community

For any package or service, there need to be at least 3 active maintainers,
or it goes out of nixpkgs-core into a nixpkgs-community repo.

Hydra builds nixos from nixpkgs-core, and nixpkgs from both combined.

nixpgks-core issues are mostly solved by the maintainers or of course any
PR that is good enough.

In the nixpkgs-community we implement the
http://rfc.zeromq.org/spec:42/C4/ process,
meaning that any PR that fulfills all the objective goals gets merged. It
worked well for ZeroMQ, and takes the guesswork out of PRs. Tree
maintainers only need to evaluate the C4 objectives
 of the PR, and if
they are fulfilled, merge.

Packages get moved between the two repos as support status changes.

That way, we have a small "trust base" for server systems, and a large
"community base" for the latest and greatest. NixOS is so flexible that you
can mix and match as you wish.

On Fri, Jul 22, 2016 at 3:12 PM Kevin Cox  wrote:

> On 22/07/16 08:55, Alexey Shmalko wrote:
> > This one: https://www.codetriage.com/nixos/nixpkgs
> >
>
> That's it! I have subscribed to get a couple issues a day so hopefully I
> can help a bit. This site seems like a nice way to spread the load.
>
> It's open source too, and I just opened an issue asking them to
> implement filters as I'm not really interesting in seeing in-progress
> issues.
>
> https://github.com/codetriage/codetriage/issues/498
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Kevin Cox]

On 22/07/16 08:55, Alexey Shmalko wrote:
> This one: https://www.codetriage.com/nixos/nixpkgs
>

That's it! I have subscribed to get a couple issues a day so hopefully I
can help a bit. This site seems like a nice way to spread the load.

It's open source too, and I just opened an issue asking them to
implement filters as I'm not really interesting in seeing in-progress
issues.

https://github.com/codetriage/codetriage/issues/498




signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[zimbatm]

We could close all >1 month old issues as a one-time thing but first we
really should have a proper process in place.

One thing we might have to consider is that there is a natural limit to how
many package each core committer can handle and we have way too many
packages right now. I know it's not pleasing to think of our limitations
but maybe should consider trimming the herd in exchange for a better
supported core of package. That's something that Arch does for example.

On Fri, 22 Jul 2016 at 13:25 Wout Mertens  wrote:

> > One day I closed an issue because nobody cared for months (even I
> didn't care enough even though I reported it). Someone reopened it saying
> that a lack of care was not a reason to close an issue and someone else
> fixed the issue the same day. So, closing can even encourage fixing :-).
>
> Which is exactly my point. 14 days is long enough for people to chime in,
> and if it gets closed all the interested parties get a reminder to reopen
> it if they still care. Autoclose is not the same as close.
>
> We could run this tool first with a 1-year timeout, then one week later 6
> months etc until we get to 14 days, so that people are not overwhelmed by
> all the close notices.
>
> On Fri, Jul 22, 2016 at 2:20 PM Tomasz Czyż  wrote:
>
>> https://github.com/kubernetes/kubernetes - just adding as reference :-)
>>
>>
>> 2016-07-22 12:07 GMT+01:00 zimbatm :
>>
>>> Exactly, we need to organize ourselves better. For me 1k+ open issues is
>>> also a bad signal when I consider adopting a project. Closing them all is
>>> not going to actually fix these issues,  what we need is more helping hands!
>>>
>>> Here are a couple of aspects that I think are part of the problem:
>>>
>>> Github issues doesn't let us forward packaging issues to the package
>>> maintainer which is the best person to fix these issues. Some might be easy
>>> fixed that just didn't reach the right audience. I tried subscribing to the
>>> repo but there is way too much volume for me to handle.
>>>
>>> Another similar issue is that the submitting person can't set flags on
>>> the new issue he's creating. We have to rely on a core contributor for
>>> doing that work instead, which is a waste of resource.
>>>
>>> Right now participation is really random and it's nice to keep this
>>> freedom but would anyone else be willing to setup a rota? If we can be more
>>> consistent on the response times I think it would be beneficial.
>>>
>>> What's our process to make sure issues don't fall trough the cracks?
>>> Just writing a playbook on how to become the "ideal" maintainer would be
>>> helpful I think.
>>>
>>> Hmm that's it for now ^_^
>>>
>>>
>>>
>>> On Fri, 22 Jul 2016 at 11:04 Domen Kožar  wrote:
>>>
 The real question is how to organize so that we triage all incoming
 issues. Closing them is the easy part :)

 On Fri, Jul 22, 2016 at 11:52 AM, Wout Mertens 
 wrote:

> We could tag those issues with "mayor-unsolved-issue" and search for
> them that way. Unsolvable issues are just standing in the way of solvable
> ones, making it harder to keep the project up-to-date.
>
> On Fri, Jul 22, 2016 at 11:49 AM Roger Qiu 
> wrote:
>
>> What about things that aren't necessarily small fixable bugs. Some
>> projects have long discussions about design or philosophy or some major
>> architecting. Or a bug that is pending somebody coming up with a good
>> solution (like for example ZFS's encryption issue which was open for
>> years). Will people need to constantly comment with `+1` just to reopen?
>> Also if an issue is closed it may increase the number of duplicate 
>> issues,
>> instead of adding onto the closed issue.
>>
>> On 22/07/2016 7:37 PM, Wout Mertens wrote:
>>
>> That's the thing about auto-reopening, it makes sure that people
>> interested in seeing the issue fixed are reminded of the issue so they 
>> can
>> continue fixing it, as well as automatically weeding out the issues that
>> are no longer important.
>>
>> All the *real* issues will stay active, since people will reopen
>> them. All the rest will be available in the history.
>>
>> I think 14 days is enough time between reminders for an open source
>> project. Shorter is annoying since we can't work on open source every 
>> day,
>> and longer will just lead to more stale issues.
>>
>> On Fri, Jul 22, 2016 at 11:17 AM Oliver Charles <
>> ol...@ocharles.org.uk> wrote:
>>
>>> Agreed.
>>>
>>> But if the problem is you think old issues are skewing the
>>> results/making it hard to find the signal, then can't you just use more
>>> intelligent search filters? E.g., things created in the past 3 months.
>>>
>>> On Fri, Jul 22, 2016 at 10:15 AM Eelco Dolstra <
>>> 

[Nix-commits] [NixOS/nixpkgs] 99bfa0: README.md: add code triagers badge

[Domen Kožar]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 99bfa00bf6b3477850506517625497e837cdbbb5
  
https://github.com/NixOS/nixpkgs/commit/99bfa00bf6b3477850506517625497e837cdbbb5
  Author: Domen Kožar 
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
M README.md

  Log Message:
  ---
  README.md: add code triagers badge


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

Re: [Nix-dev] Too many open issues

[Alexey Shmalko]

This one: https://www.codetriage.com/nixos/nixpkgs

On 07/22/2016 03:30 PM, Kevin Cox wrote:
> I'm not a huge fan of auto-closing issues based on just activity. The one 
> auto-close feature I do like is the `need info` tag when you need more from 
> the reporter. Then the issue is closed in a week or two if they don't respond.
> 
> The reason I don't like auto-closing issues is that it seems more like 
> fighting the symptom then the problem. Just because you close an issue 
> doesn't mean that it doesn't exist. I think a better way is to get more 
> triager to quickly put issues on the wishlist or find an assignee. Rather 
> then close it is probably better to have an "important" or tag of things that 
> should be looked at first (and maybe try to keep that close to zero). I see 
> little value to closing issues just because we don't want to work on them 
> right now.
> 
> It is really painful that only commiters can add tags because I would love to 
> help out with triaging more then just commenting (I think comments often have 
> low value because you can't filter on them).
> 
> One other thing that might help is I remember a service that would send a 
> couple of open issues to your inbox to help divide the load of triaging. I'm 
> going to see if I can find it again as it would probably be useful.
> 
> 
> 
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
> 



signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Kevin Cox]

I'm not a huge fan of auto-closing issues based on just activity. The one
auto-close feature I do like is the `need info` tag when you need more from
the reporter. Then the issue is closed in a week or two if they don't
respond.

The reason I don't like auto-closing issues is that it seems more like
fighting the symptom then the problem. Just because you close an issue
doesn't mean that it doesn't exist. I think a better way is to get more
triager to quickly put issues on the wishlist or find an assignee. Rather
then close it is probably better to have an "important" or tag of things
that should be looked at first (and maybe try to keep that close to zero).
I see little value to closing issues just because we don't want to work on
them right now.

It is really painful that only commiters can add tags because I would love
to help out with triaging more then just commenting (I think comments often
have low value because you can't filter on them).

One other thing that might help is I remember a service that would send a
couple of open issues to your inbox to help divide the load of triaging.
I'm going to see if I can find it again as it would probably be useful.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Tomasz Czyż]

https://github.com/kubernetes/kubernetes - just adding as reference :-)


2016-07-22 12:07 GMT+01:00 zimbatm :

> Exactly, we need to organize ourselves better. For me 1k+ open issues is
> also a bad signal when I consider adopting a project. Closing them all is
> not going to actually fix these issues,  what we need is more helping hands!
>
> Here are a couple of aspects that I think are part of the problem:
>
> Github issues doesn't let us forward packaging issues to the package
> maintainer which is the best person to fix these issues. Some might be easy
> fixed that just didn't reach the right audience. I tried subscribing to the
> repo but there is way too much volume for me to handle.
>
> Another similar issue is that the submitting person can't set flags on the
> new issue he's creating. We have to rely on a core contributor for doing
> that work instead, which is a waste of resource.
>
> Right now participation is really random and it's nice to keep this
> freedom but would anyone else be willing to setup a rota? If we can be more
> consistent on the response times I think it would be beneficial.
>
> What's our process to make sure issues don't fall trough the cracks? Just
> writing a playbook on how to become the "ideal" maintainer would be helpful
> I think.
>
> Hmm that's it for now ^_^
>
>
>
> On Fri, 22 Jul 2016 at 11:04 Domen Kožar  wrote:
>
>> The real question is how to organize so that we triage all incoming
>> issues. Closing them is the easy part :)
>>
>> On Fri, Jul 22, 2016 at 11:52 AM, Wout Mertens 
>> wrote:
>>
>>> We could tag those issues with "mayor-unsolved-issue" and search for
>>> them that way. Unsolvable issues are just standing in the way of solvable
>>> ones, making it harder to keep the project up-to-date.
>>>
>>> On Fri, Jul 22, 2016 at 11:49 AM Roger Qiu  wrote:
>>>
 What about things that aren't necessarily small fixable bugs. Some
 projects have long discussions about design or philosophy or some major
 architecting. Or a bug that is pending somebody coming up with a good
 solution (like for example ZFS's encryption issue which was open for
 years). Will people need to constantly comment with `+1` just to reopen?
 Also if an issue is closed it may increase the number of duplicate issues,
 instead of adding onto the closed issue.

 On 22/07/2016 7:37 PM, Wout Mertens wrote:

 That's the thing about auto-reopening, it makes sure that people
 interested in seeing the issue fixed are reminded of the issue so they can
 continue fixing it, as well as automatically weeding out the issues that
 are no longer important.

 All the *real* issues will stay active, since people will reopen them.
 All the rest will be available in the history.

 I think 14 days is enough time between reminders for an open source
 project. Shorter is annoying since we can't work on open source every day,
 and longer will just lead to more stale issues.

 On Fri, Jul 22, 2016 at 11:17 AM Oliver Charles 
 wrote:

> Agreed.
>
> But if the problem is you think old issues are skewing the
> results/making it hard to find the signal, then can't you just use more
> intelligent search filters? E.g., things created in the past 3 months.
>
> On Fri, Jul 22, 2016 at 10:15 AM Eelco Dolstra <
> eelco.dols...@logicblox.com> wrote:
>
>> Hi,
>>
>> On 07/22/2016 09:06 AM, Wout Mertens wrote:
>>
>> > We have 1238 open issues and 286 open PRs.
>> >
>> > That is just too much to reason about.
>> >
>> > How about using something like https://github.com/twbs/no-carrier
>> which
>> > auto-closes after 14 days of inactivity, and reopens on a new
>> comment?
>>
>> There is something to be said for auto-closing issues after a long
>> time (e.g.
>> Fedora auto-closes inactive issues from CURRENT-2 releases ago), but
>> 14 days is
>> wy to short. Bugs don't disappear after 14 days...
>>
>> --
>> Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>


 ___
 nix-dev mailing 
 listnix-...@lists.science.uu.nlhttp://lists.science.uu.nl/mailman/listinfo/nix-dev


 --
 Founder of Matrix AIhttps://matrix.ai/+61420925975

 ___
 nix-dev mailing list
 nix-dev@lists.science.uu.nl
 

Re: [Nix-dev] Too many open issues

[Damien Cassou]

Wout Mertens  writes:

> We have 1238 open issues and 286 open PRs.
> That is just too much to reason about.
>
> How about using something like https://github.com/twbs/no-carrier which
> auto-closes after 14 days of inactivity, and reopens on a new comment?

I agree with you about auto-closing old issues but I think 14 days is
way too short. For me, an issue must be automatically closed

- if nobody cares enough to say either that he is impacted too or is
  still impacted

- if nobody cares enough to fix the issue

There is not enough man power for nixpkgs to be bug free. Automatically
closing issues means open issues are the ones people care about.
Moreover, the tools auto-closing issues must warn a few days before
closing the issue to raise awareness of the open issues.

One day I closed an issue because nobody cared for months (even I didn't
care enough even though I reported it). Someone reopened it saying that
lack of care was not a reason to close an issue and someone else fixed
the issue the same day. So, closing can even encourage fixing :-).

Best,

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[zimbatm]

Exactly, we need to organize ourselves better. For me 1k+ open issues is
also a bad signal when I consider adopting a project. Closing them all is
not going to actually fix these issues,  what we need is more helping hands!

Here are a couple of aspects that I think are part of the problem:

Github issues doesn't let us forward packaging issues to the package
maintainer which is the best person to fix these issues. Some might be easy
fixed that just didn't reach the right audience. I tried subscribing to the
repo but there is way too much volume for me to handle.

Another similar issue is that the submitting person can't set flags on the
new issue he's creating. We have to rely on a core contributor for doing
that work instead, which is a waste of resource.

Right now participation is really random and it's nice to keep this freedom
but would anyone else be willing to setup a rota? If we can be more
consistent on the response times I think it would be beneficial.

What's our process to make sure issues don't fall trough the cracks? Just
writing a playbook on how to become the "ideal" maintainer would be helpful
I think.

Hmm that's it for now ^_^



On Fri, 22 Jul 2016 at 11:04 Domen Kožar  wrote:

> The real question is how to organize so that we triage all incoming
> issues. Closing them is the easy part :)
>
> On Fri, Jul 22, 2016 at 11:52 AM, Wout Mertens 
> wrote:
>
>> We could tag those issues with "mayor-unsolved-issue" and search for them
>> that way. Unsolvable issues are just standing in the way of solvable ones,
>> making it harder to keep the project up-to-date.
>>
>> On Fri, Jul 22, 2016 at 11:49 AM Roger Qiu  wrote:
>>
>>> What about things that aren't necessarily small fixable bugs. Some
>>> projects have long discussions about design or philosophy or some major
>>> architecting. Or a bug that is pending somebody coming up with a good
>>> solution (like for example ZFS's encryption issue which was open for
>>> years). Will people need to constantly comment with `+1` just to reopen?
>>> Also if an issue is closed it may increase the number of duplicate issues,
>>> instead of adding onto the closed issue.
>>>
>>> On 22/07/2016 7:37 PM, Wout Mertens wrote:
>>>
>>> That's the thing about auto-reopening, it makes sure that people
>>> interested in seeing the issue fixed are reminded of the issue so they can
>>> continue fixing it, as well as automatically weeding out the issues that
>>> are no longer important.
>>>
>>> All the *real* issues will stay active, since people will reopen them.
>>> All the rest will be available in the history.
>>>
>>> I think 14 days is enough time between reminders for an open source
>>> project. Shorter is annoying since we can't work on open source every day,
>>> and longer will just lead to more stale issues.
>>>
>>> On Fri, Jul 22, 2016 at 11:17 AM Oliver Charles 
>>> wrote:
>>>
 Agreed.

 But if the problem is you think old issues are skewing the
 results/making it hard to find the signal, then can't you just use more
 intelligent search filters? E.g., things created in the past 3 months.

 On Fri, Jul 22, 2016 at 10:15 AM Eelco Dolstra <
 eelco.dols...@logicblox.com> wrote:

> Hi,
>
> On 07/22/2016 09:06 AM, Wout Mertens wrote:
>
> > We have 1238 open issues and 286 open PRs.
> >
> > That is just too much to reason about.
> >
> > How about using something like https://github.com/twbs/no-carrier
> which
> > auto-closes after 14 days of inactivity, and reopens on a new
> comment?
>
> There is something to be said for auto-closing issues after a long
> time (e.g.
> Fedora auto-closes inactive issues from CURRENT-2 releases ago), but
> 14 days is
> wy to short. Bugs don't disappear after 14 days...
>
> --
> Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
 ___
 nix-dev mailing list
 nix-dev@lists.science.uu.nl
 http://lists.science.uu.nl/mailman/listinfo/nix-dev

>>>
>>>
>>> ___
>>> nix-dev mailing 
>>> listnix-...@lists.science.uu.nlhttp://lists.science.uu.nl/mailman/listinfo/nix-dev
>>>
>>>
>>> --
>>> Founder of Matrix AIhttps://matrix.ai/+61420925975
>>>
>>> ___
>>> nix-dev mailing list
>>> nix-dev@lists.science.uu.nl
>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>>
>>
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>>
> ___
> nix-dev mailing list
> 

Re: [Nix-dev] Too many open issues

[Domen Kožar]

The real question is how to organize so that we triage all incoming issues.
Closing them is the easy part :)

On Fri, Jul 22, 2016 at 11:52 AM, Wout Mertens 
wrote:

> We could tag those issues with "mayor-unsolved-issue" and search for them
> that way. Unsolvable issues are just standing in the way of solvable ones,
> making it harder to keep the project up-to-date.
>
> On Fri, Jul 22, 2016 at 11:49 AM Roger Qiu  wrote:
>
>> What about things that aren't necessarily small fixable bugs. Some
>> projects have long discussions about design or philosophy or some major
>> architecting. Or a bug that is pending somebody coming up with a good
>> solution (like for example ZFS's encryption issue which was open for
>> years). Will people need to constantly comment with `+1` just to reopen?
>> Also if an issue is closed it may increase the number of duplicate issues,
>> instead of adding onto the closed issue.
>>
>> On 22/07/2016 7:37 PM, Wout Mertens wrote:
>>
>> That's the thing about auto-reopening, it makes sure that people
>> interested in seeing the issue fixed are reminded of the issue so they can
>> continue fixing it, as well as automatically weeding out the issues that
>> are no longer important.
>>
>> All the *real* issues will stay active, since people will reopen them.
>> All the rest will be available in the history.
>>
>> I think 14 days is enough time between reminders for an open source
>> project. Shorter is annoying since we can't work on open source every day,
>> and longer will just lead to more stale issues.
>>
>> On Fri, Jul 22, 2016 at 11:17 AM Oliver Charles 
>> wrote:
>>
>>> Agreed.
>>>
>>> But if the problem is you think old issues are skewing the
>>> results/making it hard to find the signal, then can't you just use more
>>> intelligent search filters? E.g., things created in the past 3 months.
>>>
>>> On Fri, Jul 22, 2016 at 10:15 AM Eelco Dolstra <
>>> eelco.dols...@logicblox.com> wrote:
>>>
 Hi,

 On 07/22/2016 09:06 AM, Wout Mertens wrote:

 > We have 1238 open issues and 286 open PRs.
 >
 > That is just too much to reason about.
 >
 > How about using something like https://github.com/twbs/no-carrier
 which
 > auto-closes after 14 days of inactivity, and reopens on a new comment?

 There is something to be said for auto-closing issues after a long time
 (e.g.
 Fedora auto-closes inactive issues from CURRENT-2 releases ago), but 14
 days is
 wy to short. Bugs don't disappear after 14 days...

 --
 Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
 ___
 nix-dev mailing list
 nix-dev@lists.science.uu.nl
 http://lists.science.uu.nl/mailman/listinfo/nix-dev

>>> ___
>>> nix-dev mailing list
>>> nix-dev@lists.science.uu.nl
>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>>
>>
>>
>> ___
>> nix-dev mailing 
>> listnix-...@lists.science.uu.nlhttp://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>>
>> --
>> Founder of Matrix AIhttps://matrix.ai/+61420925975
>>
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Wout Mertens]

We could tag those issues with "mayor-unsolved-issue" and search for them
that way. Unsolvable issues are just standing in the way of solvable ones,
making it harder to keep the project up-to-date.

On Fri, Jul 22, 2016 at 11:49 AM Roger Qiu  wrote:

> What about things that aren't necessarily small fixable bugs. Some
> projects have long discussions about design or philosophy or some major
> architecting. Or a bug that is pending somebody coming up with a good
> solution (like for example ZFS's encryption issue which was open for
> years). Will people need to constantly comment with `+1` just to reopen?
> Also if an issue is closed it may increase the number of duplicate issues,
> instead of adding onto the closed issue.
>
> On 22/07/2016 7:37 PM, Wout Mertens wrote:
>
> That's the thing about auto-reopening, it makes sure that people
> interested in seeing the issue fixed are reminded of the issue so they can
> continue fixing it, as well as automatically weeding out the issues that
> are no longer important.
>
> All the *real* issues will stay active, since people will reopen them. All
> the rest will be available in the history.
>
> I think 14 days is enough time between reminders for an open source
> project. Shorter is annoying since we can't work on open source every day,
> and longer will just lead to more stale issues.
>
> On Fri, Jul 22, 2016 at 11:17 AM Oliver Charles 
> wrote:
>
>> Agreed.
>>
>> But if the problem is you think old issues are skewing the results/making
>> it hard to find the signal, then can't you just use more intelligent search
>> filters? E.g., things created in the past 3 months.
>>
>> On Fri, Jul 22, 2016 at 10:15 AM Eelco Dolstra <
>> eelco.dols...@logicblox.com> wrote:
>>
>>> Hi,
>>>
>>> On 07/22/2016 09:06 AM, Wout Mertens wrote:
>>>
>>> > We have 1238 open issues and 286 open PRs.
>>> >
>>> > That is just too much to reason about.
>>> >
>>> > How about using something like https://github.com/twbs/no-carrier
>>> which
>>> > auto-closes after 14 days of inactivity, and reopens on a new comment?
>>>
>>> There is something to be said for auto-closing issues after a long time
>>> (e.g.
>>> Fedora auto-closes inactive issues from CURRENT-2 releases ago), but 14
>>> days is
>>> wy to short. Bugs don't disappear after 14 days...
>>>
>>> --
>>> Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
>>> ___
>>> nix-dev mailing list
>>> nix-dev@lists.science.uu.nl
>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>>
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>
>
> ___
> nix-dev mailing 
> listnix-...@lists.science.uu.nlhttp://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
> --
> Founder of Matrix AIhttps://matrix.ai/
> +61420925975
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Roger Qiu]

What about things that aren't necessarily small fixable bugs. Some 
projects have long discussions about design or philosophy or some major 
architecting. Or a bug that is pending somebody coming up with a good 
solution (like for example ZFS's encryption issue which was open for 
years). Will people need to constantly comment with `+1` just to reopen? 
Also if an issue is closed it may increase the number of duplicate 
issues, instead of adding onto the closed issue.



On 22/07/2016 7:37 PM, Wout Mertens wrote:
That's the thing about auto-reopening, it makes sure that people 
interested in seeing the issue fixed are reminded of the issue so they 
can continue fixing it, as well as automatically weeding out the 
issues that are no longer important.


All the *real* issues will stay active, since people will reopen them. 
All the rest will be available in the history.


I think 14 days is enough time between reminders for an open source 
project. Shorter is annoying since we can't work on open source every 
day, and longer will just lead to more stale issues.


On Fri, Jul 22, 2016 at 11:17 AM Oliver Charles > wrote:


Agreed.

But if the problem is you think old issues are skewing the
results/making it hard to find the signal, then can't you just use
more intelligent search filters? E.g., things created in the past
3 months.

On Fri, Jul 22, 2016 at 10:15 AM Eelco Dolstra
>
wrote:

Hi,

On 07/22/2016 09:06 AM, Wout Mertens wrote:

> We have 1238 open issues and 286 open PRs.
>
> That is just too much to reason about.
>
> How about using something like
https://github.com/twbs/no-carrier which
> auto-closes after 14 days of inactivity, and reopens on a
new comment?

There is something to be said for auto-closing issues after a
long time (e.g.
Fedora auto-closes inactive issues from CURRENT-2 releases
ago), but 14 days is
wy to short. Bugs don't disappear after 14 days...

--
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/

___
nix-dev mailing list
nix-dev@lists.science.uu.nl 
http://lists.science.uu.nl/mailman/listinfo/nix-dev

___
nix-dev mailing list
nix-dev@lists.science.uu.nl 
http://lists.science.uu.nl/mailman/listinfo/nix-dev



___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


--
Founder of Matrix AI
https://matrix.ai/
+61420925975

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Wout Mertens]

To give you an idea, there are still 109 issues that were updated in the
last 2 weeks:
https://github.com/NixOS/nixpkgs/issues?utf8=%E2%9C%93=is%3Aissue%20is%3Aopen%20%20updated%3A%3E%3D2016-07-08

This is already quite enough to work on.

On Fri, Jul 22, 2016 at 11:37 AM Wout Mertens 
wrote:

> That's the thing about auto-reopening, it makes sure that people
> interested in seeing the issue fixed are reminded of the issue so they can
> continue fixing it, as well as automatically weeding out the issues that
> are no longer important.
>
> All the *real* issues will stay active, since people will reopen them. All
> the rest will be available in the history.
>
> I think 14 days is enough time between reminders for an open source
> project. Shorter is annoying since we can't work on open source every day,
> and longer will just lead to more stale issues.
>
> On Fri, Jul 22, 2016 at 11:17 AM Oliver Charles 
> wrote:
>
>> Agreed.
>>
>> But if the problem is you think old issues are skewing the results/making
>> it hard to find the signal, then can't you just use more intelligent search
>> filters? E.g., things created in the past 3 months.
>>
>> On Fri, Jul 22, 2016 at 10:15 AM Eelco Dolstra <
>> eelco.dols...@logicblox.com> wrote:
>>
>>> Hi,
>>>
>>> On 07/22/2016 09:06 AM, Wout Mertens wrote:
>>>
>>> > We have 1238 open issues and 286 open PRs.
>>> >
>>> > That is just too much to reason about.
>>> >
>>> > How about using something like https://github.com/twbs/no-carrier
>>> which
>>> > auto-closes after 14 days of inactivity, and reopens on a new comment?
>>>
>>> There is something to be said for auto-closing issues after a long time
>>> (e.g.
>>> Fedora auto-closes inactive issues from CURRENT-2 releases ago), but 14
>>> days is
>>> wy to short. Bugs don't disappear after 14 days...
>>>
>>> --
>>> Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
>>> ___
>>> nix-dev mailing list
>>> nix-dev@lists.science.uu.nl
>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>>
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Wout Mertens]

That's the thing about auto-reopening, it makes sure that people interested
in seeing the issue fixed are reminded of the issue so they can continue
fixing it, as well as automatically weeding out the issues that are no
longer important.

All the *real* issues will stay active, since people will reopen them. All
the rest will be available in the history.

I think 14 days is enough time between reminders for an open source
project. Shorter is annoying since we can't work on open source every day,
and longer will just lead to more stale issues.

On Fri, Jul 22, 2016 at 11:17 AM Oliver Charles 
wrote:

> Agreed.
>
> But if the problem is you think old issues are skewing the results/making
> it hard to find the signal, then can't you just use more intelligent search
> filters? E.g., things created in the past 3 months.
>
> On Fri, Jul 22, 2016 at 10:15 AM Eelco Dolstra <
> eelco.dols...@logicblox.com> wrote:
>
>> Hi,
>>
>> On 07/22/2016 09:06 AM, Wout Mertens wrote:
>>
>> > We have 1238 open issues and 286 open PRs.
>> >
>> > That is just too much to reason about.
>> >
>> > How about using something like https://github.com/twbs/no-carrier which
>> > auto-closes after 14 days of inactivity, and reopens on a new comment?
>>
>> There is something to be said for auto-closing issues after a long time
>> (e.g.
>> Fedora auto-closes inactive issues from CURRENT-2 releases ago), but 14
>> days is
>> wy to short. Bugs don't disappear after 14 days...
>>
>> --
>> Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] 39cf21: nodejs-6_x: 6.2.2 -> 6.3.1

[Wout Mertens]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 39cf213e2bd4487dbc776c620877e79bde9e62c2
  
https://github.com/NixOS/nixpkgs/commit/39cf213e2bd4487dbc776c620877e79bde9e62c2
  Author: Tobias Pflug 
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
M pkgs/development/web/nodejs/nodejs.nix
M pkgs/development/web/nodejs/v6.nix

  Log Message:
  ---
  nodejs-6_x: 6.2.2 -> 6.3.1


  Commit: 434f9d158bbf3629a653b7d05abef450ea5273d5
  
https://github.com/NixOS/nixpkgs/commit/434f9d158bbf3629a653b7d05abef450ea5273d5
  Author: Wout Mertens 
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
M pkgs/development/web/nodejs/nodejs.nix
M pkgs/development/web/nodejs/v6.nix

  Log Message:
  ---
  Merge pull request #17169 from holidaycheck/nodejs-6.3.1

nodejs-6_x: 6.2.2 -> 6.3.1


Compare: https://github.com/NixOS/nixpkgs/compare/390b49a3e771...434f9d158bbf___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 60c6c7: nixos-container: add 'kill' command, 'destroy' to ...

[Eelco Dolstra]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 60c6c7bc9a0d564cf86af4b1711b33db48cf0d07
  
https://github.com/NixOS/nixpkgs/commit/60c6c7bc9a0d564cf86af4b1711b33db48cf0d07
  Author: Scott R. Parish 
  Date:   2016-07-21 (Thu, 21 Jul 2016)

  Changed paths:
M pkgs/tools/virtualization/nixos-container/nixos-container.pl

  Log Message:
  ---
  nixos-container: add 'kill' command, 'destroy' to use 'kill'

Using 'machinectl kill' is much faster then gracefully stopping the
container.

In the case of 'destroy', since we're destroying it anyway, there's no
reason to do a graceful shutdown.


  Commit: 390b49a3e771ca72f6da7ea24ffe4413b3380510
  
https://github.com/NixOS/nixpkgs/commit/390b49a3e771ca72f6da7ea24ffe4413b3380510
  Author: Eelco Dolstra 
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
M pkgs/tools/virtualization/nixos-container/nixos-container.pl

  Log Message:
  ---
  Merge pull request #17130 from srp/nixos-container-kill

nixos-container: add 'kill' command, 'destroy' to use 'kill'


Compare: https://github.com/NixOS/nixpkgs/compare/ad941c12f4af...390b49a3e771___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

Re: [Nix-dev] Too many open issues

[Oliver Charles]

Agreed.

But if the problem is you think old issues are skewing the results/making
it hard to find the signal, then can't you just use more intelligent search
filters? E.g., things created in the past 3 months.

On Fri, Jul 22, 2016 at 10:15 AM Eelco Dolstra 
wrote:

> Hi,
>
> On 07/22/2016 09:06 AM, Wout Mertens wrote:
>
> > We have 1238 open issues and 286 open PRs.
> >
> > That is just too much to reason about.
> >
> > How about using something like https://github.com/twbs/no-carrier which
> > auto-closes after 14 days of inactivity, and reopens on a new comment?
>
> There is something to be said for auto-closing issues after a long time
> (e.g.
> Fedora auto-closes inactive issues from CURRENT-2 releases ago), but 14
> days is
> wy to short. Bugs don't disappear after 14 days...
>
> --
> Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] 51d931: i3blocks-gaps: init at 1.4

[Robin Gloster]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 51d9312e44a1266dddaa927e822b37282f7aa1f7
  
https://github.com/NixOS/nixpkgs/commit/51d9312e44a1266dddaa927e822b37282f7aa1f7
  Author: Carl Sverre 
  Date:   2016-07-21 (Thu, 21 Jul 2016)

  Changed paths:
A pkgs/applications/window-managers/i3/blocks-gaps.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  i3blocks-gaps: init at 1.4

Fork of i3blocks which supports adding borders to work with i3-gaps


  Commit: ad941c12f4af7fa35d6efd67ed51e0d96220ccb5
  
https://github.com/NixOS/nixpkgs/commit/ad941c12f4af7fa35d6efd67ed51e0d96220ccb5
  Author: Robin Gloster 
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
A pkgs/applications/window-managers/i3/blocks-gaps.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  Merge pull request #17168 from carlsverre/add/i3blocks-gaps

i3blocks-gaps: init at 1.4


Compare: https://github.com/NixOS/nixpkgs/compare/5209edc8ec92...ad941c12f4af___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

Re: [Nix-dev] Too many open issues

[Michael Walker]

If there are 1000+ open issues, it's hard to know what to prioritise.
If inactive issues get closed, it at least helps cut down on things
which may no longer be relevant (and if they are, someone finds the
closed issue, comments in it, and it opens again).

On 22 July 2016 at 09:57, Oliver Charles  wrote:
> What does the number 0 bring us if there are in reality still hundreds of
> issues?
>
>
> On Fri, 22 Jul 2016, 8:06 a.m. Wout Mertens,  wrote:
>>
>> We have 1238 open issues and 286 open PRs.
>>
>> That is just too much to reason about.
>>
>> How about using something like https://github.com/twbs/no-carrier which
>> auto-closes after 14 days of inactivity, and reopens on a new comment?
>>
>> I'm sure that if we have close to 0 open issues/PRs, there will be a
>> greater incentive to bring that number to 0…
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>



-- 
Michael Walker (http://www.barrucadu.co.uk)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Oliver Charles]

What does the number 0 bring us if there are in reality still hundreds of
issues?

On Fri, 22 Jul 2016, 8:06 a.m. Wout Mertens,  wrote:

> We have 1238 open issues and 286 open PRs.
>
> That is just too much to reason about.
>
> How about using something like https://github.com/twbs/no-carrier which
> auto-closes after 14 days of inactivity, and reopens on a new comment?
>
> I'm sure that if we have close to 0 open issues/PRs, there will be a
> greater incentive to bring that number to 0…
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] 5209ed: fira-code: 1.102 -> 1.200

[Robert Helgesson]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 5209edc8ec922f95a6378dd8c31e3050491a9fc5
  
https://github.com/NixOS/nixpkgs/commit/5209edc8ec922f95a6378dd8c31e3050491a9fc5
  Author: Robert Helgesson 
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
M pkgs/data/fonts/fira-code/default.nix

  Log Message:
  ---
  fira-code: 1.102 -> 1.200


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 281449: binutils: 2.26 -> 2.26.1

[Lancelot SIX]

  Branch: refs/heads/staging
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 281449424fd9d13552987c1267dbd66233c0cd95
  
https://github.com/NixOS/nixpkgs/commit/281449424fd9d13552987c1267dbd66233c0cd95
  Author: Lancelot SIX 
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
M pkgs/development/tools/misc/binutils/default.nix
R pkgs/development/tools/misc/binutils/fix-bsymbolic.patch
R pkgs/development/tools/misc/binutils/fix-update-symbol-version.patch

  Log Message:
  ---
  binutils: 2.26 -> 2.26.1

See announcement at
http://lists.gnu.org/archive/html/info-gnu/2016-07/msg0.html


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 2568ee: lrzip: 0.621 -> 0.630

[Tobias Geerinckx-Rice]

  Branch: refs/heads/release-16.03
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 2568ee3d73bdebd6bab6739adf8a900f3429c8e6
  
https://github.com/NixOS/nixpkgs/commit/2568ee3d73bdebd6bab6739adf8a900f3429c8e6
  Author: Tobias Geerinckx-Rice 
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
M pkgs/tools/compression/lrzip/default.nix

  Log Message:
  ---
  lrzip: 0.621 -> 0.630

Changes: http://ck-hack.blogspot.com/2016/06/lrzip-0630.html
(cherry picked from commit 1212d921c1712130a200fed9f4e9277445f87860)


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] f8ea8c: tt-rss: Fix evaluation by disabling nginx-options.

[Moritz Ulrich]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: f8ea8c7197943b1cc637bd8a79639885bd1b
  
https://github.com/NixOS/nixpkgs/commit/f8ea8c7197943b1cc637bd8a79639885bd1b
  Author: Moritz Ulrich 
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
M nixos/modules/services/web-apps/tt-rss.nix

  Log Message:
  ---
  tt-rss: Fix evaluation by disabling nginx-options.

The nginx.virtualHosts option isn't merged yet. We can re-enable these
features when https://github.com/NixOS/nixpkgs/pull/15862 is merged.


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-dev] Too many open issues

[Wout Mertens]

We have 1238 open issues and 286 open PRs.

That is just too much to reason about.

How about using something like https://github.com/twbs/no-carrier which
auto-closes after 14 days of inactivity, and reopens on a new comment?

I'm sure that if we have close to 0 open issues/PRs, there will be a
greater incentive to bring that number to 0…
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] d6ff1c: exrtools: init at 0.4

[Tuomas Tynkkynen]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: d6ff1ce2a0eba96dca1b73e036746671a8f1d7a8
  
https://github.com/NixOS/nixpkgs/commit/d6ff1ce2a0eba96dca1b73e036746671a8f1d7a8
  Author: Julien Dehos 
  Date:   2016-07-21 (Thu, 21 Jul 2016)

  Changed paths:
A pkgs/applications/graphics/exrtools/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  exrtools: init at 0.4


  Commit: e5d048ad9aa7e993e6ff2d0469441bff5ec3b19d
  
https://github.com/NixOS/nixpkgs/commit/e5d048ad9aa7e993e6ff2d0469441bff5ec3b19d
  Author: Tuomas Tynkkynen 
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
A pkgs/applications/graphics/exrtools/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  Merge pull request #17151 from juliendehos/exrtools

exrtools: init at 0.4


Compare: https://github.com/NixOS/nixpkgs/compare/0d7da216be11...e5d048ad9aa7___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-dev] 1000 EUR for a week of work with Nix and NixOps

[Arseniy Seroka]

Fellow nixers,

I'm Arseniy Seroka, founder of Serokell.
We already use Nix on a daily basis while working on our projects. For
one such
project, rscoin[1], we need to come up with a way of deploying and
running it
on a multitude of cloud services. Naturally, we're looking at NixOps to
do that.
We have a pretty tight deadline — we need to get it done by July 29th,
hence we're seeking for aid in this goal.
We want to hire a nixer with a good background in NixOps for the next
week and
we intend to pay up to 1000 EUR for forty hours of work.
We're also open for some follow-up contracts with nixers, such as
contributing
to our long-running Haskell Overlay initiative or setting up elaborate
Hydra-based CI infrastructure. RSCoin is a great project that uses
Haskell and
PureScript, we think you'll have fun contributing to its usability and
deployability!

[1] https://github.com/input-output-hk/rscoin-haskell



signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev