<MichaelRaskin>
Sigh. I think there are additional effects about reviewer switching, not just discoverability.
<timokau[m]>
Please leave a comment with your opinion, I'm sure it can be improved :)
<MichaelRaskin>
I am not sure it is something that is easy to improve in the RFC, which is why I don't want to start the discussion with hard-to-fix pessimistic remarks
<MichaelRaskin>
Ooohh the long dream of the ofBorg merge workflow
<timokau[m]>
If keeping the same reviewer would be preferred, we could mark prs as `has:reviewer` or make use of githubs assignments. We could then automatically remove that assignment after some time without a review. That way it would stay one reviewer in most cases while still solving (2).
<timokau[m]>
The `build-and-merge` is not a prerequisite for this of course.
<MichaelRaskin>
timokau: single reviewer is not desirable in principle, but in specific cases people often want the original commenter to evaluate how the issues raised were addressed in an updated version of the PR
<MichaelRaskin>
Something like lost:reviewer could serve as an encouragement
<MichaelRaskin>
gchristensen: I mostly meant my comment as «this is coming some day, and this is needed, and these claims are true independently of the RFC»
<gchristensen>
aye :)
<timokau[m]>
MichaelRaskin: I think in most cases the comments are relatively straightforward nitpicks. But it probably doesn't hurt much to keep to one reviewer for most cases.
<jtojnar>
dtz[m]: do you have something I can reproduce the meson build failure with?
<timokau[m]>
MichaelRaskin: do you still think that your concern shouldn't be added to the PR discussion?
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
<MichaelRaskin>
timokau: I have some pessimism, and some things that I would prefer to discuss once some definitely-planned ofBorg features land
<timokau[m]>
Given the time the rfc process usually takes, I think it makes sense to start discussion now. You can do it however you prefer of course :)
<MichaelRaskin>
Let there be some less jaded comments than mine
<MichaelRaskin>
At least to set the initial tone
<timokau[m]>
MichaelRaskin: very considerate :D Anyways, I'll be away for a while now.
<MichaelRaskin>
Good luck in case anything in the process can benefit form luck!
aszlig has quit [Quit: Kerneling down for reboot NOW.]
aszlig has joined #nixos-dev
<aanderse>
MichaelRaskin: are you raskin from maintainers.raskin?
<aanderse>
you're listed as the openscenegraph maintainer
<aanderse>
it needs a version bump, and i made it a bit more configurable
<MichaelRaskin>
aanderse: yes, and I have mass-packaged a lot of stuff by dependency-walking, so I am very willing to add extra maintainers
<MichaelRaskin>
(and I am not very good at finding relevant notifications from GitHub unless direct-mentioned as @7c6f434c )
<MichaelRaskin>
gchristensen: good that surgery does help…
<aanderse>
MichaelRaskin: will submit and mention you then
<MichaelRaskin>
Did you try more than one support combination?
<aanderse>
i tried compiling with all on, all off, and default
<aanderse>
all 3 cases compiled
<MichaelRaskin>
did they actually have different closures?
<aanderse>
well... in hindsight that seems like an obvious check :( i checked the result/ dir to make sure the list of plugins was different
<aanderse>
but
<aanderse>
yeah... should have checked that first
<aanderse>
i mean... one implies the other
<aanderse>
but still
<aanderse>
<- still learning
<MichaelRaskin>
No, checking difference in plugin list is also fine
<MichaelRaskin>
I just don't remember specifics, so I ask for a generic check; specific check is perfectly fine when applicable
orivej has quit [Ping timeout: 256 seconds]
<aanderse>
ok, confirmed different hashes... though it appears lua sneaks in regardless of luaSupport being false
<aanderse>
it must include the source inside osg or something
<MichaelRaskin>
Hashes will always be different, runtime dependency list is the interesting question
* aanderse
removes luaSupport flag
<MichaelRaskin>
Yes, honesty is nice.
<aanderse>
hmm... same for zip support
<aanderse>
baked in
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 248 seconds]
<aanderse>
MichaelRaskin: rebuilt everything with the 2 options removed, going to make a pull and mention you now
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev
aanderse has quit [Ping timeout: 240 seconds]
garbas has joined #nixos-dev
Drakonis has joined #nixos-dev
<gchristensen>
the most inconvenient part of having such a large community around the world is there is no obviously convenient time to shut down ofborg for 30min
<gchristensen>
not entirely true: 20:00 - 02:00 America/New_York seems like the best time
<MichaelRaskin>
Having a few morning people (I mean those rising early in the morning, not those up until morning! — although if you have the former, you probably also have the latter…) does that inside a single timezone!
<MichaelRaskin>
20:00 seems to be so-so from US-East point of view?
<gchristensen>
yeah
<MichaelRaskin>
02:00 New York is 09:00 MSK, right?
<gchristensen>
sounds likely
<MichaelRaskin>
I think we have people from Beijing…
<MichaelRaskin>
Then again, when my builder with regular 20h of down time turned out to be the only one, it was investigated like a month later
<MichaelRaskin>
So 30 minutes of downtime, if RabbitMQ just holds the messages to use later, could be not that much of an impact
<gchristensen>
that is the problem, rabbitmq will be going down for it
<LnL>
it's rabbitmq itself, not the rest of the infra isn't a big deal
<gchristensen>
to make it easier to add more rabbitmq nodes
<MichaelRaskin>
I wonder if there is something ready-made that can be started to replace RabbitMQ and just write down all the requests into files
<gchristensen>
a good idea
<gchristensen>
it wouldn't be so hard to make the github ingestion program write to a file, on a new server, for an hour
<MichaelRaskin>
You are not obliged to reply in a sensible way, right?
<MichaelRaskin>
So it can basically be socat instance
<MichaelRaskin>
Hm. So if socat just dumps every connection into a file, then these files can be later replayed by a similar trivial socat abuse, right?
<gchristensen>
MichaelRaskin: github would prefer I send back an http 200 :P
<MichaelRaskin>
Sigh.
<MichaelRaskin>
Still not too complicated, but complicated enough to wonder if there is a ready script for that.
<gchristensen>
the final option is we can just drop them on the floor
<gchristensen>
it wouldn't be the first time
<MichaelRaskin>
That's true
<MichaelRaskin>
But having a recorder would also be nice for the future planned downtime
<gchristensen>
for sure
<MichaelRaskin>
Argh, Java, do not want
<gchristensen>
nooope
<MichaelRaskin>
Are requests POST or PUT?
<gchristensen>
POST
<gchristensen>
there is another option I hadn't considered
<gchristensen>
don't upgrade the node at all, just point new traffic to a new node and migrate workers over.
<MichaelRaskin>
That sounds like a natural solution…