<domenkozar>
what's really interesting is, people are getting more and more used to push upstream late in release cycle
<LnL>
oh, that's why the manual links work again
<MichaelRaskin>
master is the one true branch and release cycle is just a distraction…
keta_suki has quit [(Quit: WeeChat 1.9.1)]
<gchristensen>
domenkozar: can you graph merged PRs in there somehow too?
<domenkozar>
gchristensen: you mean merged per month?
<gchristensen>
yeah, as a separate line
<domenkozar>
should be doable :)
<gchristensen>
our ability to merge PRs, I think, is becoming a "biggest" issue
<gchristensen>
those heroic dips are just as scary to me, easy to burn the people out who do those
<gchristensen>
oh those aren't open PRs, just total submitted, but we'll see heroic dips in the # closed
<MichaelRaskin>
I sometimes do 50 merges or something and then don't merge more than a couple a week for the next month or two.
<gchristensen>
yeah, I think that is a pattern a number of people are in
<MichaelRaskin>
Well, you just need to give out enough commit access that every weekend _someone_ is closing 50 PRs…
<gchristensen>
that-and-or better automation / auditing / reviewing of PRs
<MichaelRaskin>
(well, also there is a qiuestion of having enough Haskell/Node/Python/Ruby people, as there is special machinery)
<MichaelRaskin>
Well, reading for general sanity is the easy part, but estimating the impact is sometimes hard.
<gchristensen>
like "this nss update will break chrome for 2 weeks" impact?
<MichaelRaskin>
Given that we don't have reliable pre-building of all PRs, I guess it is too early to have integration tests for a significant share of programs…
<MichaelRaskin>
Yes.
<MichaelRaskin>
Wait, nss breaks Chrome? Really?
<MichaelRaskin>
MDN, NSS, maybe it is still simpler for Google if Mozilla is around as an entity…
<gchristensen>
I might be confusing it for ICU :)
<MichaelRaskin>
Ouch, ICU.
<gchristensen>
(this was all part of the same PR)
<gchristensen>
one reason I setup my PR rebroadcaster is so people can experiment with PR testing
<gchristensen>
I'm not sure anyone put 2-and-2 together
<MichaelRaskin>
To experiment with PR testing, there is quite an entry barrier, though
<gchristensen>
build capacity?
<MichaelRaskin>
Yes.
<gchristensen>
yeah, no doubt
<MichaelRaskin>
I mean, mere PR notifications could be obtained using just email.
<gchristensen>
but little test bots can provide interesting experiments
<gchristensen>
from my last one, I feel hydra is not suitable for this task
<Profpatsch>
(there’s already new stuff incoming which I’d like to base on these changes to prevent major merge conflicts.
<infinisil>
Profpatsch: Looks good, but not sure about the port thing
Mic92 has quit [(Quit: WeeChat 1.9.1)]
<infinisil>
I have been thinking of adding a port module that assigns ports to (service) modules that need one, and avoid conflicts while doing so
<infinisil>
So I couldn't use this new port type for that purpose
Mic92 has joined joined #nixos-dev
<infinisil>
the modules type system makes it possible to get away from the 'arbitrary' notion of port 0, and instead put meaning behind the declarations
<Profpatsch>
infinisil: Ah, this is not ensured, no.
<Profpatsch>
Normally, Port 0 assigns a free port.
<Profpatsch>
The first ~1000 ports are listed in /etc/hosts
<Profpatsch>
See uids/gids, where systemd dynamic users allow us to move awai from ids.nix
<Profpatsch>
*away
<Profpatsch>
I just try to make these range types a bit more semantig.
<Profpatsch>
*c
<infinisil>
These aren't ports though
<Profpatsch>
infinisil: No, they are port numbers. :)
<Profpatsch>
So maybe rename?
<infinisil>
gui/uid's = port numbers? never heard of that, but I'll gladly learn about it
<infinisil>
I mean yeah it's the same range, but where is the semantic
<infinisil>
But how do you get to uid's etc. from port numbers?
<infinisil>
Other than them having the same range i don't see how they're related
<infinisil>
Or is port here meant in a broader sense? I've never heard of "ports" being used for uid/guids
<Profpatsch>
infinisil: Nah, I meant the “unique port problem” could be solved in a similar way.
<infinisil>
Ahh I see, yeah something like that would work
<infinisil>
But I'm thinking more of putting this responsibility to each service, which needs to declare an option networking.port.52 = <name>; (I know numbers can't be used as attributes, but something like that)
<Profpatsch>
That’s an unsolved problem, yes.
<Profpatsch>
I guess we’d have to extend the module dischange system so that the set of used ports is propagated upwards.
<Profpatsch>
And when a clash happens, the clashing options are reported.
<Profpatsch>
Should be possible if I think about it.
<Profpatsch>
Not sure how it’d influence the speed of module combinations.
<Profpatsch>
But! That can probably be introduced without breaking (non-clashing) user code, afterwards.
<infinisil>
Yeah that's gonna work somehow
<infinisil>
Profpatsch: But, what do you think regarding the port type of your PR?
<infinisil>
(about what i said earlier)
<infinisil>
Well I guess I wasn't really clear :P
<Profpatsch>
infinisil: I’d say introduce it as a ranged type now, then extend it later to correctly throw an error when the same port is used twice.
<infinisil>
What I was trying to say is that I like the idea of having a types.nullOr types.port instead of allowing 0 as a port
<infinisil>
Forget about my idea for now, was supposed to be just a sidenote