aserio changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar.cct.lsu.edu | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | Buildbot: http://rostam.cct.lsu.edu/ | Log: http://irclog.cct.lsu.edu/
EverYoung has quit [Ping timeout: 276 seconds]
EverYoung has joined #ste||ar
EverYoun_ has joined #ste||ar
EverYoun_ has quit [Remote host closed the connection]
<jbjnr>
msimberg: waiting for green master might make you an old man :)
<msimberg>
jbjnr: may be, but there won't be a release without a green master
<jbjnr>
as release manager - you can enforce a rule that master is locked, except for merges that fix tests fails
<msimberg>
at least not with a red one
<msimberg>
yeah, that's a very reasonable rule
<jbjnr>
use the hpx-users or devel mailing lists to set a date, after which only fixes for tests will be accepted
<jbjnr>
before we can go back to feature additions etc
<jbjnr>
prior to next release
<jbjnr>
so (say) no merges after 10th dec - unless they address tests failures until dashboard is green - after that we can begin merging fixes and improvements that are neeeded for release etc etc until $DATE - after which master will be locked again prior to a release
<jbjnr>
that kind of thing ....
<jbjnr>
we only need heller and hkaiser to agree to it, and then ....
<jbjnr>
we must also consider removing tests that use features that never pass and are never green and consider those features as unsupported until such time tht they become green agin
<jbjnr>
(we need to start being brutal IMHO) - we can discuss this with adrian this afternoon and see what he thinks.
<msimberg>
jbjnr: I agree with everything you said, I admit I've been too passive so far
<msimberg>
was a bit slow in arranging this call with aserio
<msimberg>
jbjnr: can you remind me, the hpx tutorial will be in march, no?
<msimberg>
jbjnr: btw, I think now is a good time to not allow anything that doesn't fix tests ;)
<jbjnr>
yes march tutorial
<jbjnr>
ok - lets talk to adrian, then from monday we can begin ...
<jbjnr>
(release mid feb at latest I'd say - for march tutorial)
<msimberg>
jbjnr: yeah, came to the same conclusion
<msimberg>
mid feb release, rc end of january, cleanup in january, test fixing in december
<msimberg>
roughly
<heller>
jbjnr: I more than agree
<heller>
msimberg: sounds like a plan
<heller>
please enforce this rule ;)(
<heller>
I have two PRs that fix stuff
<heller>
they really block me ...
<heller>
and I think we should switch to a policy such that noone is allowed to merge their own PRs
<K-ballo>
that policy in itself would probably effectively halt development
<K-ballo>
I haven't merged a PR, mine or otherwise, in months
<K-ballo>
there's a lot more people writing PRs than there are merging PRs.. basically is what, one and two halfs?
<heller>
well, the main reason I don't merge PRs at the moment is because there are so many tests failing
<heller>
every other PR merged leads to new test failures
<heller>
and it looks like no one really cares
hkaiser has joined #ste||ar
<heller>
hkaiser: I would really like to move on with #3007 and #2982. Those PR fix rather important bugs
<heller>
and good morning ;)
<hkaiser>
heller: see pm, pls
<zao>
Mood gorning.
hkaiser has quit [Read error: Connection reset by peer]
hkaiser has joined #ste||ar
<heller>
grrr, inspect
<K-ballo>
that reminds me, I'll drop my inspect-first PR.. we'll have to wait for the workflow based ci
<K-ballo>
I cannot get circle to even consider artifacts being generated during the build
<K-ballo>
or rather, in the case of a build failure
<heller>
ok
<heller>
I stalled the workflow based one, since it it also runs the tests
<heller>
it doesn't make sense to merge it to master if those keep failing
<msimberg>
heller: what's actually holding back moving to circleci 2?
<heller>
msimberg: I'd like to run the tests on circleci, but then, every PR is being flagged as failed
<heller>
well, wouldn't be too bad, I think
<msimberg>
that would be great
<heller>
well, every PR including the move to circle2 one ;)
<msimberg>
but you mean with circleci 2 we would be able to run all the tests? and with 1 we can't?
<zao>
I really hate that my test machine is just yawning.
<heller>
we should be able to do it with circle1 as well
<msimberg>
okay, but that would be acceptable
<heller>
but with the workflow pipeline, the different steps can be easily overlapped
<heller>
in an ideal case, we'd be able to reduce the test time to about 1:30
<msimberg>
but I think that's something that should tested/broken as soon as possible, so that we can get on with not merging broken prs
<zao>
1h30m or 1m30s?
<heller>
1h30m
<heller>
including running the tests
<msimberg>
huh, builds + tests?
<heller>
yeah, running in parallel, on 4 builders
<zao>
My biggest pain point for the tests is the ones that time out or are disproportionally long.
<zao>
Can't really go much below 100s timeout before it starts culling genuinely long tests.
<heller>
ah, 1:30 is just for building, as it seems
<heller>
msimberg: i'd be happy if you rebase those commits to latest master and prepare the PR
<heller>
we could even think about dropping the actual test running as a stop-gap measure
<heller>
or only run selected tests
<heller>
ha, I am wrong, that workflow ran the tests... just no the header tests
<msimberg>
heller: yes! I'll gladly do that
<msimberg>
heller: it's just the config file right? is there otherwise something that you'd still like to change or clean up there or is it just a matter of making a pr?
<github>
[hpx] msimberg force-pushed circle_2 from a0cdcfc to c95bc59: https://git.io/vdKfd
<github>
hpx/circle_2 c95bc59 Thomas Heller: Switching to CircleCI 2.0...
hkaiser has quit [Ping timeout: 268 seconds]
<heller>
msimberg: it's just the config file, yeah. the clang-tidy changes are obsolete once the clang_tidy branch is merged
<heller>
msimberg: and then it is about to fix the tests ;)
<msimberg>
heller: okay, I guess I can leave it in there... the commented out stuff at the bottom of the config file is also just the old config file? I can remove that?
<heller>
yes, that can be removed
<msimberg>
yeah, sure, then it's "just" fixing tests ;) but at least we have a much better view of when things break
<jbjnr>
who can tell me what the difference is between an acceptance token and a personal token on gihub
<jbjnr>
zao: ?
<jbjnr>
ignore that question. I found what I needed to know
mcopik has joined #ste||ar
hkaiser has quit [Quit: bye]
jaafar has joined #ste||ar
hkaiser has joined #ste||ar
aserio has quit [Ping timeout: 255 seconds]
<zao>
Great, because I don't know :)
<zao>
For my bot, I just issued an user token with no rights.
<zao>
Enough to query for PRs and commits of public repos, I believe.
<K-ballo>
zao: your bot?
<zao>
K-ballo: The part of my grand soak-testing plan that figures out what to test.
<zao>
By fetching all repo refs, polling github API, and explicit IRC requests.
<zao>
(or something)
<K-ballo>
where is this bot?
<zao>
In pieces on some of my home machines.
<zao>
The goal is to make some use out of the Ryzen 7.
<zao>
So a build of the codebase on a single compiler and Boost version, aiming for a short turnaround from PR commit to tests, and running tests for many iterations to see if they're stable.
<zao>
Which is something I need to build pretty much from scratch, doesn't slot in well with buildbot exactly.
<zao>
Doesn't help that I have no idea what I'm doing when it comes to building such daemons.
<zao>
:)
<K-ballo>
that's the fun part!
<zao>
Been touching node.js for days without throwing up much!
<zao>
I've got singularity figured out enough to have an image with a prebuilt Boost and Clang compilers, that I can mount a source/build tree into and run a build and run tests with network isolation in one container.
<zao>
(so I can run several test suites at once without them colliding on ports and stuff)
<zao>
I've still got to write the runner that starts and monitors such processes, and the service that triggers them and figures out what to build.
<zao>
Intent is to run it on all PRs until they're merged.
<zao>
(also master, but that should be eternally green, shouldn't it? :P)
<zao>
Off to chill with the parents, there's glögg!
<K-ballo>
master is... well... difficult
<jbjnr>
zao: the reason I asked is because I started implementing a bot using pygithub
<jbjnr>
I can query all PRs and then spawn builds for them on a CSCS machine
<jbjnr>
I will add options to set the compiler and boost version etc etc
<hkaiser>
jbjnr: I hope you're not seriously implementing your own github bot/integration :/
<hkaiser>
didn't you want to use some existing CI system?
<jbjnr>
hkaiser: I'm just experimenting - all we need is to build all PR's + master and see the test results. CDash can show the results, the simply python bot can pull the PRs - just want to see hiow easy it is to get a simple bot running
<jbjnr>
partly so that when cscs meets next week, I can show them
<hkaiser>
jbjnr: is building sufficient, shouldn't we also run the tests?
<jbjnr>
yes of course I'm running the tests
<hkaiser>
k
<jbjnr>
I didn't think I needed to say that
<jbjnr>
(this is my spare time)
<hkaiser>
sure ;)
<hkaiser>
just asking
<jbjnr>
next week, cscs has a CI meeting and they will tell us that we can't have this/that/the other because a/b/c ... and it will take 6 months ...
<hkaiser>
nod
<hkaiser>
would it be possible for those results to be visible to everybody?
<jbjnr>
yes, they will go to the cscs cdash server that you can already see
<jbjnr>
the difference will be we will see warnings/build/update