<gchristensen>
MichaelRaskin: fingers crossed somebody can take my job security away from me
<MichaelRaskin>
Not this time, though.
<gchristensen>
:P
<gchristensen>
I wish he'd answer my question, though :/
<MichaelRaskin>
I mean, what is said about ofborg… we-ell, I have ran an ofborg builder, and… What is said about PR reviews… we-ell, I have also burnt out on that after reviewing 50+ on multiple occasions, and…
<gchristensen>
yeahd.
<gchristensen>
yeah.
<MichaelRaskin>
I would not put too much trust in the answer anyway
<gchristensen>
it is hard
<gchristensen>
I mean
<gchristensen>
would it be useful if ofborg built all the dependencies?
<gchristensen>
like if there were 1-10 rebuilds
<MichaelRaskin>
I mean, there is a ton of useful stuff about how they use releases
<gchristensen>
and it rebuilt all all of them?
<gchristensen>
or would that be wasted I don't know
<MichaelRaskin>
I dunno, if comments are out, can ofborg re-request my review when the build I ask about finishes?
<gchristensen>
it probably could, yeah
<MichaelRaskin>
I mean, if it could send an email directly, it would be also nice
<MichaelRaskin>
But if it re-requests review, GH will send an email just fine
<MichaelRaskin>
And I remember you do not like handling email
<MichaelRaskin>
I would even prefer if it re-requests if it has requested and there are some checks running, no matter the reason they are running. But I guess some would complain, and I am not sure there is a good way to manage the options
<MichaelRaskin>
Hmmm, re-requests + announcing ofborg can handle more sounds like a very attractive plan now!
<MichaelRaskin>
Maybe indeed with nix-review command in ofborg
<gchristensen>
clone_for("mr-est"... you can see the origins of ofborg's humble goals
<cole-h>
What does mr-est refer to?
<gchristensen>
"mass-rebuild estimation"
<cole-h>
Oh. Heh.
<gchristensen>
its first goal was "can we stop blowing up master every day?"
<gchristensen>
* with rebuilds
<gchristensen>
its second goal was "can we stop blowing up master every week?" * with evaluation errors
<LnL>
don't give me flashbacks to the travis times
<gchristensen>
oh man
<gchristensen>
we have it so good compared to then
<cole-h>
Travis has been having a bad time recently
<cole-h>
Or was
<gchristensen>
travis was in its heyday when we were using it, and it was awful for us
<gchristensen>
a green travis mark meant almost nothing , and a red one meant absolutely nothing
<MichaelRaskin>
Ah Travis
<gchristensen>
the very bad old days :)
<MichaelRaskin>
Days were still good! It was such a way to get attention by commenting «you will be surprised, but this time Travis _does_ have useful data»
<gchristensen>
hahaha
<gchristensen>
okay yeah I remember that
<MichaelRaskin>
I also remember the raging party in comments when Travis configuration was being removed…
<gchristensen>
hehe
<gchristensen>
so I'm thinking I could store some data in the envelope status to determine if it is done or not
<MichaelRaskin>
Rare case of such unanimity in optimism!
<gchristensen>
and then I can parallelize a bunch of things
<MichaelRaskin>
And I guess there could be a good-first-issue about making the empty-envelope be a check for parseability of the description for finding the intended changed packages or something
<gchristensen>
yeah good idea
<gchristensen>
and using the Checks API, we get more than 140 characters to do it in!
<MichaelRaskin>
One bit should be enough for everyone!