<infinisil>
I've looked through the nixpkgs repo to find people which I'd be okay with giving commit rights. These names will be familiar to most people here: etu, oxij, volth and romildo
lassulus_ has joined #nixos-dev
<gchristensen>
we've talked about giving access to volth , but they delete their comments regularly, and I don't think that is ok
<infinisil>
github comments?
<gchristensen>
yea
<infinisil>
Hmm yeah that's not very good
<samueldr>
+1, in the older PRs still open there are replies to unseen question from them :(
<gchristensen>
I also have concerns around oxij. I don't have any concerns around etu and romildo
<gchristensen>
(I also haven't looked at their history)
lassulus has quit [Ping timeout: 252 seconds]
lassulus_ is now known as lassulus
<infinisil>
Ah yeah
<infinisil>
We should really have a fixed process for this
<gchristensen>
+1 :D
<infinisil>
Also I'd be interested in potentially revoking access to long inactive committers
<gchristensen>
+1
<infinisil>
Okay how about some numbers for a start: No commits to nixpkgs in one year revokes commit rights to it
<gchristensen>
1yr seems reasonable to me
<infinisil>
Yeah
<samueldr>
maybe involvement, other kind of involvement would warrand a manual look?
<samueldr>
(though I would be surprised to see involvement in a year, without commits at all)
* gchristensen
goes ahead and just +1s everything
<infinisil>
samueldr: Ahh, maybe activity in general, I think github tracks that already
<infinisil>
Alright, but any policy regarding that is better than just having access forever
<infinisil>
Okay but the more interesting part is for new committers
<infinisil>
How about a number: To become committer you need at least 50 merged PR's (10 of which non-trivial) and have reviewed 20 (non-trivial) PR's
* samueldr
thinks about their own numbers
<infinisil>
Yeah, not sure if current committers fulfil that
<samueldr>
ah, not that far though I guess
<infinisil>
And "non-trivial" is not really automatically detectable
<infinisil>
Maybe lines of change > 10?
<samueldr>
(I think there has to be some manual leeway for out-of-nixpkgs contributions)
<infinisil>
out-of-nixpkgs?
<samueldr>
nixos-homepage, nixos-org-configuration other nixos/ org repos :)
<gchristensen>
not sure we need it to be automatically detectable anyway
<samueldr>
and yeah, there's that
<samueldr>
detecting shouldn't be a worry, but a rule of thumb is good imho
<infinisil>
gchristensen: I'd like most of it to be automatable, such that only minimal manual checks are involved
<infinisil>
Yeah
<infinisil>
Maybe also a requirement: Has added at least 2 new packages (to make sure they know good nix formatting and how to package stuff in nixpkgs), has written at least one NixOS module (but then again, lots of people never do NixOS module reviews, soo.)
* gchristensen
isn't sure he's ever added a package
<samueldr>
closer to your ideas, a points-based system may be easier to understand
<samueldr>
someone with 1000 good reviews, but no other contributions could be better than 10 packages and no reviews, no?
<infinisil>
Hmmm, maybe
<samueldr>
(I mean, if one were to try and build a system around the gut feeling of adding a contributor)
<samueldr>
(which isn't definitively known as desired)
<infinisil>
Yeah sounds good
aminechikhaoui has joined #nixos-dev
aminechikhaoui has quit [Remote host closed the connection]
aminechikhaoui has joined #nixos-dev
<infinisil>
What do you think of a short interview with a couple questions on nixpkgs maintenance?
<samueldr>
I think it should be given to everyone owning commits bits (to hone the valid answers better)
* infinisil
tries to think of questions
<infinisil>
It's hard to come up with questions, because people are specialized to different parts of nixpkgs
<samueldr>
exactly!
<samueldr>
any questions about python or haskell I'll draw the blankest blank
<samueldr>
(or read the fine manual)
<infinisil>
Oh, one question: "How does master and staging work, when to use what"
* samueldr
fails the test
<infinisil>
"Describe the release process, what do you need to look out for during the release time?"
<colemickens>
Hmmm.
<colemickens>
These also seem like excellent things to document, less they become gate-keep-y, no?
<samueldr>
the release process is all in the manual :)
<samueldr>
(staging though is described in an RFC)
<gchristensen>
master/staging workflow is documented, not the decision
<colemickens>
Well, there goes my application :P
* colemickens
does need to go read through old rfcs
* samueldr
it bothered to see issues in backports, when they should have been caught in the original commits :(
<infinisil>
"There is a PR that updates libfoo, how do you test this PR?"
<samueldr>
that's a good question, open ended, no "good" answers
<gchristensen>
+1
<infinisil>
"There is a PR that adds 1000 NixOS options, what are potential problems with this?"
<samueldr>
gchristensen: (if you want to) you were cc-ed on #49387
<drakonis>
doing it on irc is good for a couple reasons, first, logs, second, you have enough folks around to ask enough questions on how to handle situations and to make them reachable
<drakonis>
but i suppose that if they participate enough, the last reason is unnecessary, as they'll already be on irc
<infinisil>
Well, all the people I proposed above aren't on IRC
<infinisil>
I think
<infinisil>
But they do a lot for the community
<infinisil>
Of course, knowing the people on IRC as well is a bonus, but shouldn't be a requirement imo
* samueldr
thinks we may have had an oopsie with 18.09
<drakonis>
a oopsie? tell me more
<samueldr>
looks like the installation media (not an issue) and the vm (maybe one) have had their stateVersion kept at 18.03
<gchristensen>
oops
<samueldr>
installation media: not an issue
<samueldr>
nixos-generate-config uses a placeholder which is replaced
<ekleog>
samueldr: I mentioned this a bit ago iirc
<ekleog>
but it's not an issue
<ekleog>
stateVersion is nowhere compared to 18.09 in nixos
<ekleog>
so 18.03 and 18.09 is the same thing
<samueldr>
at least there's that silver lining :)
* samueldr
is dipping his toes into a huge bikeshedding experience
<drakonis>
a huge bikeshedding experience?
<drakonis>
which color is the bikeshed?
<samueldr>
5
<drakonis>
not a color in my opinion, but to each their own eyyyy
<drakonis>
i'd paint it 4
<drakonis>
infinisil: if only for reaching a consensus on larger changes to nixpkgs
<infinisil>
Discussing it properly can work wonders :)
<drakonis>
yes it can!
<infinisil>
It's often not a matter of one having better arguments than the other, but rather the parties just not understanding each other properly (applies to pretty much every argument ever)
<drakonis>
point taken
<samueldr>
oh, the bikeshedding was not about the previous discussion, but something I'm working on
<drakonis>
it is a good change because stateversion never really made much sense and caused a lot of confusion
<ekleog>
infinisil: well, I'd be happy to not bother people here with triage-pings, but don't expect me to merge anything non-trivial I'd have done myself :p
<drakonis>
plus the numbering scheme is good for pinning down when a large change that requires bumping state
<drakonis>
comes in
<drakonis>
so its no longer "bump state only when release cycles come in"
<ekleog>
potential issue: release notes were done for releases, now the “manual steps for upgrading” needs to be done in a stateEpoch log which needs to be somewhere
<samueldr>
ekleog: right!
<samueldr>
but thos possibly can be coupled with the release notes
<infinisil>
ekleog: Thanks for the linked PR's and issues, closed/merged them all except the old one with postgresql
<drakonis>
use the log as a nixpkgs release notes y/n
<samueldr>
drakonis: no
<samueldr>
not all changes requiring release notes incurr imcompatible changes :)
<ekleog>
infinisil: Thank you! :)
<samueldr>
describing that for 101, foo's stateful directory will move from /dev/null to /dev/urandom, and for 102 bar's configuration file needs to be written in COBOL
<infinisil>
Arghh, r-ryantm opening new PR's so quickly
<drakonis>
i would've rather use it for sweeping incompatible changes rather than individual package changes
<drakonis>
should've written that instead of what i did
<drakonis>
101 would be "new syntax feature"
<drakonis>
wouldn't be written in such a vague/simple way
drakonis has quit [Quit: WeeChat 2.3]
sir_guy_carleton has joined #nixos-dev
sir_guy_carleton has quit [Quit: WeeChat 2.2]
<Mic92>
infinisil: I worked on nix-review to support batching multiple prs better to cope with that.
<Mic92>
darwin-stdenv in staging is b0rked: https://logs.nix.ci/?key=nixos/nixpkgs.49860&attempt_id=99547493-6646-48cd-9ee6-08eb4d5ec8e4
jtojnar has joined #nixos-dev
<colemickens>
So if I build my system today on version 100.
<clever>
Checking .pth file support in /nix/store/jifl19d110jhnb7v3fwsq62qhaylzmg2-mediagoblin/lib/python2.7/site-packages/
<clever>
TEST FAILED: /nix/store/jifl19d110jhnb7v3fwsq62qhaylzmg2-mediagoblin/lib/python2.7/site-packages/ does NOT support .pth files
JosW has joined #nixos-dev
<clever>
as best as i can tell, setuptools is trying to import modules it just installed to $out, and then it fails because they arent yet in PYTHONPATH
<clever>
has any other package in nixpkgs had to deal with this before?
JosW has quit [Remote host closed the connection]
drakonis has quit [Quit: WeeChat 2.3]
drakonis has joined #nixos-dev
pie_ has quit [Ping timeout: 252 seconds]
ma27 has quit [Ping timeout: 252 seconds]
ma27 has joined #nixos-dev
drakonis is now known as drakonis_
drakonis has joined #nixos-dev
pie_ has joined #nixos-dev
pie_ has quit [Read error: Connection reset by peer]
pie_ has joined #nixos-dev
pie_ has quit [Remote host closed the connection]
drakonis1 has joined #nixos-dev
drakonis_ has quit [Ping timeout: 260 seconds]
pie_ has joined #nixos-dev
zarel has joined #nixos-dev
orivej_ has quit [Ping timeout: 246 seconds]
zarel has quit [Quit: Leaving]
<infinisil>
We're not doing backports to 18.03 anymore, right?
<infinisil>
Latest commit Nov 10...
<infinisil>
This needs to stop!
<samueldr>
>> Note that 18.03 is expected to receive important fixes at least until the end of October. Further support is not guaranteed, and shouldn’t be expected.
<samueldr>
"not guaranteed, shouldn't be expected"
<samueldr>
unless we found some contributors willing to LTS-ize 18.03, yeah