IRC logs for #buildstream for Monday, 2018-04-02

*** mohan43u has quit IRC02:04
*** mohan43u has joined #buildstream02:07
*** mohan43u has quit IRC05:04
*** mohan43u has joined #buildstream05:08
*** tristan has joined #buildstream05:54
*** Prince781 has quit IRC05:58
*** tristan has quit IRC06:39
*** tristan has joined #buildstream06:44
*** toscalix has joined #buildstream08:12
*** mohan43u has quit IRC09:04
*** mohan43u has joined #buildstream09:08
*** solid_black has joined #buildstream10:32
*** slaf has quit IRC10:52
*** slaf has joined #buildstream10:55
*** mohan43u has quit IRC11:05
*** mohan43u has joined #buildstream11:08
*** solid_black has quit IRC11:12
*** solid_black_ has joined #buildstream11:14
*** solid_black has joined #buildstream12:27
*** solid_black_ has quit IRC12:28
*** solid_black_ has joined #buildstream12:35
*** solid_black has quit IRC12:35
*** solid_black_ is now known as solid_black12:37
tristanjuergbi, We have a mix of strict mode policy effective within a single pipeline13:22
tristanThis appears to be my fault13:22
tristanI wonder if this can be correct in any possibly universe, if not, I mean to correct the error13:23
juergbinot sure right now13:28
tristanOk, what I did, and it "looks" like I fucked up while doing it... is make the user configuration declare strict mode preference on a per project basis13:30
tristanThis is certainly correct and a good thing13:30
tristanThe problem is Context.get_strict() takes a project name, instead of always using the toplevel project13:30
tristanmeaning when we have junctions in play, we use different strict mode settings for different elements inside the same pipeline13:30
tristanIf this is intentional, I will not change it, but it looks quite error prone and incorrect13:31
tristanjuergbi, dont worry, I dont expect any answer right now... it's late here already, and I have a note about it so I will remind you this week :D13:31
tristanfwiw, I've landed a bunch of stuff in the last couple days, closed two bugs, refactored a bit, and threw away ~80 LOC in the process13:32
*** solid_black has quit IRC13:41
* paulsherwood is asked elswhere "is there any plan for bi/analytics for buildstream"13:59
tristanUmmm, a quick google search shows me that that is either something I should never really understand, or something that could be translated into terminology that makes sense to me :)14:01
tristan"Business Intelligence" ?14:01
tristansounds like sales-speak :)14:01
* tristan has to leave closing coffee shop...14:02
paulsherwood:)14:03
paulsherwoodi think it means (in this context) getting buildstream to generate statistics over time14:05
*** tristan has quit IRC14:05
paulsherwood(for example i've been frabbing ybd release-note functionality to generate repo stats as it goes)14:06
*** tristan has joined #buildstream14:09
tristanpaulsherwood, got your reply from the logger... and going to get some take out dinner and shut down the brain...14:10
tristanpaulsherwood, at first sight, I think that should be out of scope - rather, we should be open to providing machine readable logging (as we are attempting for benchmarking purposes), such that other automated systems can easily use that14:11
tristanas buildstream is not an on-going process; it seems that for ongoing collection of statistical data, that should be another component, integrated in CI or such14:12
tristangitlab does *some* minimal amount of that in terms of merge requests and CI statistics (for a project configured to run BuildStream in CI)14:13
tristanprobably more particular "stuff" (beyond "how many builds passed"), could be scraped with a bst logging aware CI runner/system, or by collecting artifacts from gitlab CI to view machine readable logs and do some number crunching14:15
tristanI suppose the first question one has to ask is "What kind of particular statistic do you want to see out of builds", and move forward from there14:15
tristan"How often are you failing to download source code from a third party server" might be interesting, for instance14:16
paulsherwoodthe two areas that i know are interesting are both time-series...14:28
paulsherwood1) how long a given pipeline takes (and same for each of its component steps), so we can spot when something starts taking more time14:29
paulsherwood2) how much code change/churn in total and for each component14:29
jmac1) Is part of the performance analysis plan14:39
tristan2) could probably be done using workspace features and comparing between builds, if you are already in a position where you have branches being tracked and CI being run14:46
tristani.e. once you have a strategy for how you continuously build something, you could pretty easily get those statistics based on the builds you've decided to run14:46
tristanfor added pleasure, you might get diffs of the resulting artifacts and get some ratio on how much that code churn effected the build results, too14:48
jmacInteresting idea14:56
*** solid_black has joined #buildstream15:31
*** solid_black has quit IRC15:37
*** toscalix has quit IRC15:44
*** mohan43u has quit IRC16:05
*** mohan43u has joined #buildstream16:08
*** valentind has joined #buildstream19:18
*** valentind has quit IRC19:49
*** valentind has joined #buildstream19:49
*** valentind has quit IRC20:02
*** mohan43u has quit IRC20:04
*** valentind has joined #buildstream20:07
*** mohan43u has joined #buildstream20:08
*** tristan has quit IRC20:55
*** mohan43u has quit IRC21:05
*** mohan43u has joined #buildstream21:08
*** xjuan has joined #buildstream21:52
*** xjuan has quit IRC22:40

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!