IRC logs for #baserock for Saturday, 2017-02-11

*** rdale has quit IRC03:31
*** gtristan has joined #baserock04:39
* gtristan notices that ybd MR 300 was merged differently than what he originally saw06:08
gtristaninstead of a 'sha:' field, there is now a 'tree:' field06:08
gtristanI dont know what to do with a 'tree:' field, I need a 'sha:'06:08
gtristanThere's nothing you can really do with a tree sha, except "know it", it's just not useful beyond that.06:21
gtristanodd, ok the code looks like it's doing (both ?) but maybe I encountered a bug06:24
gtristancause shas are just not coming up in the saved definitions.yml06:24
* gtristan palmface06:25
gtristan${target}.yml, case closed06:25
gtristanThis line is a bit confusing:
gtristanIt updates the output ${target}.yml with ref: ${unpetrify-ref}... so it says, yet the ${target}.yml has the loaded ref in ref as expected06:38
* paulsherwood waves06:48
paulsherwoodgtristan: that may be a bug06:49
paulsherwoodupdate_manifest is only reporting - i didn't touch it when making the #300 change, so it may be reporting the wrong thing now06:50
* paulsherwood thinks there are a couple of things wrong with the manifest stuff06:51
paulsherwoodwhile i'm on i can explain the use-case - i wonder if you've thought of it for bst06:51
paulsherwood- user generates a new release of a stack06:52
paulsherwood- last 'release' may be last definitions commit, or last tag, or some other ref06:53
paulsherwood- needs to provide (as part of the release) a list of all component changes since last release06:53
paulsherwood- for all components which have *not* changed, may need to generate a statement to that effect, or just not report on them06:54
paulsherwood- for components which have changed, the format of the change list ideally would be configurable06:55
paulsherwoodso ybd has a release-cmd: setting which allows us to configure what is generated for the delta06:56
*** gtristan has quit IRC06:56
paulsherwoodin other news, how would you feel about supporting tree instead of commit in the cache-key *as an option*06:57
paulsherwoodthere's no need for all users to share the same cache-key alg version/options07:02
*** gtristan has joined #baserock08:43
gtristanpaulsherwood, I lost power and went off to eat lunch... I was wondering in the mean time, maybe we can ditch the manifest entirely ? It seems to me that if we fill in some blanks in the generated file with MR 300, whatever it is people do with manifests, they could also do with that file no ?08:46
* gtristan got lost a bit with manifests08:46
gtristanback to cache-key again, I'm not entirely averse to adding the option, but I *really* think its going to be a nearly worthless optimization08:49
gtristanpaulsherwood, I would rather live with commit sha for a while without adding extra noise - and if it *does* turn out to be an optimization worth doing, then so be it08:50
gtristan*however*, if we do that optimization, the tree sha should additionally be recorded in project metadata (this can be automated with the `bst track <target>` feature)08:51
gtristani.e.: rule of thumb, you never need gits, or network connectivity, to calculate cache keys08:52
gtristanregarding release management and deltas; I'm not convinced it should be implemented by the tool itself (I'm not sure the tool should have any knowledge of what your last "release" was)08:56
gtristanAnd certainly, storing your project does not require a particular type of VCS, it's project data; can be stored in a tarball, or in CVS for all the tool should care08:57
gtristanthat said, the intent of the --format option to `bst show` is to allow powerful scripting around it08:58
*** toscalix has joined #baserock08:58
gtristanthe hope is that whatever additional stuff (like release management) should be easily scriptable08:58
gtristanmorning toscalix08:59
gtristantoscalix, I looked at your slides, is there any recording ?09:00
toscalixI believe so but not sure09:00
toscalixI would have to ask gary09:00
toscalixhopefully in a few days the vm will be ready09:01
toscalixthe idea is t present it at ELC09:01
gtristanah, maybe I should wait for the big show :)09:02
gtristanwhen is that ?09:02
toscalixin two weeks09:05
toscalixi would suggest you to wait because we are fixing a couple of issues that prevent lava from testing09:06
gtristanah, ok let me know :)09:06
toscalixI will09:06
gtristanI was interested last time you gave the similar talk in Manchester :)09:06
toscalixit has taken us very long to finish this. It was complicated though. A lot of different technologies involved.09:07
*** toscalix has quit IRC09:13
paulsherwoodfor those who haven't seen the slides, what is 'this'?09:32
gtristankernel CI, and testing in general09:41
paulsherwoodgtristan: how close are you to a bst that i could run to build (say) current baserock definitions?09:43
gtristanpaulsherwood, I put the conversion script on the side (although it's a good start so far, MR 300 helps a lot), would need to spend a day or two on that and test the result to say for sure09:44
gtristan(right now I'm trying to push the rpm-metadata updating automation through, get it out of the way)09:45
gtristanguestimation: around one week of work away (including a deployment)09:48
*** edcragg_ has quit IRC10:24
*** jude_ has quit IRC10:25
*** leeming has quit IRC10:25
*** rdale has joined #baserock13:01
*** rdale has quit IRC13:09
*** gtristan has quit IRC13:53
*** locallycompact has joined #baserock17:05
*** locallycompact has quit IRC17:12
*** locallycompact has joined #baserock18:02
*** edcragg has joined #baserock18:31
*** jude_ has joined #baserock18:32
*** leeming has joined #baserock18:32
*** edcragg has quit IRC18:35
*** edcragg has joined #baserock18:37
*** locallycompact has joined #baserock19:35
*** locallycompact has joined #baserock23:10

Generated by 2.15.3 by Marius Gedminas - find it at!