| *** bochecha has quit IRC | 00:48 | |
| *** semanticdesign has quit IRC | 01:47 | |
| *** tristan has quit IRC | 05:03 | |
| *** tristan has joined #buildstream | 05:51 | |
| *** jude has joined #buildstream | 07:35 | |
| *** jonathanmaw has joined #buildstream | 08:20 | |
| *** ssam2 has joined #buildstream | 09:10 | |
| *** tlater has joined #buildstream | 09:22 | |
| *** tiagogomes has quit IRC | 09:22 | |
| *** tiagogomes has joined #buildstream | 09:23 | |
| *** tlater has quit IRC | 09:45 | |
| *** tlater has joined #buildstream | 09:47 | |
| *** givascu has joined #buildstream | 09:48 | |
| ssam2 | tristan, do you consider the layout of an artifact to be an API surface of buildstream, or an implementation detail ? | 10:00 |
|---|---|---|
| ssam2 | I don't mean its actual on disk representation, but the logical filesystem layout, i.e. a `files/` dir, a `logs/` dir, and a `metadata/` dir | 10:01 |
| tristan | ssam2, it's a thing I've been thinking about more and more to be honest | 10:10 |
| tristan | some things in there clearly need to be stable, while it has originally been an unstable thing | 10:10 |
| tristan | metadata needs to be stable, because of public data | 10:10 |
| ssam2 | right | 10:10 |
| ssam2 | i mean, the layout is simple enough that I can't really picture a situation where you'll need to break it | 10:11 |
| tristan | If you want to run with a plan for signing artifacts, it will need to be stable also | 10:11 |
| tristan | Right, me too | 10:11 |
| tristan | At least, backwards compat | 10:11 |
| ssam2 | yeah | 10:11 |
| tristan | ssam2, I'm not averse to declaring it stable and back compat | 10:12 |
| ssam2 | ok cool | 10:12 |
| ssam2 | i think adding source info to the metadata would be useful too | 10:12 |
| ssam2 | so you could work out which repo(s) a project was built from, without having to manually parse the build log | 10:13 |
| tristan | Yes, we can probably get away with literal dumps without any Source support for that | 10:13 |
| tristan | However, extra care would be needed for the tracking cases | 10:14 |
| ssam2 | yeah, you want know both 'ref' and 'track' i guess | 10:14 |
| tristan | especially when doing `bst build --track` without saving | 10:14 |
| tristan | ssam2, that and, its just plain easier and more straight forward to just dump the source as it was originally represented | 10:14 |
| tristan | also it's potentially reusable by buildstream | 10:15 |
| ssam2 | makes sense | 10:15 |
| tristan | if ever we want some automation for any reason | 10:15 |
| ssam2 | well, with variables and conditionals already expanded i guess | 10:15 |
| tristan | yes | 10:15 |
| ssam2 | otherwise, we may as well dump the whole .bst file :-) | 10:15 |
| tristan | that would not be bad, except such a thing doesnt really exist :) | 10:15 |
| tristan | ah the unexpanded one, yeah; but would be irrelevant I think | 10:16 |
| ssam2 | you'd need the rest of the context for it to make sense | 10:16 |
| ssam2 | at which point, just... don't lose your source repo... | 10:16 |
| tristan | Oh yeah; another hitch to that is expanding the aliases | 10:17 |
| ssam2 | hmm, one other thing which I would really like, but is perhaps not something to go in the core, is a way of knowing details of the repo that contained the .bst files | 10:17 |
| ssam2 | that can be really useful for working out how an artifact was built | 10:18 |
| tristan | yeah; I dont want that in the core either | 10:18 |
| ssam2 | is there some way it could work as a plugin ? | 10:18 |
| tristan | but if there is a way to integrate it or add support, lets think of a clean unintrusive one | 10:18 |
| ssam2 | as a strawman, could there be a git_annotation plugin that sets public data on everything further down ? | 10:18 |
| tristan | one which doesnt assume anything about how you received your project, ever, or what VCS you used to revision it, if you did use one | 10:19 |
| tristan | No plugins can see reverse dependencies | 10:19 |
| ssam2 | right | 10:19 |
| tristan | And you're only allowed to programatically mutate your own element's public data (and read-only on dependencies) | 10:20 |
| ssam2 | right | 10:20 |
| ssam2 | what if we had a way to pass the annotation in from outside buildstream? so users could provide a 'describe-my-git-repo` script, and do something like `bst build --public-data=$(describe-my-git-repo)` ... | 10:21 |
| tristan | ssam2, not sure where it's going, but if for instance; you wanted to dump random stuff buildstream doesnt care about into an element's public data; just because you might want to read it back from an artifact... that could probably be scripted | 10:21 |
| ssam2 | ok, that sounds like a pretty good extension point | 10:22 |
| tristan | I dont think it needs to be with a switch | 10:22 |
| tristan | I mean, we dont really need any extra support for loading and rewriting files with ruamel.yaml | 10:22 |
| ssam2 | i'm lost.. are you suggesting poking round in the artifact cache after the fact to extend the metadata? | 10:23 |
| ssam2 | or saying users do this after `bst checkout` ? | 10:24 |
| ssam2 | i guess that could work actually | 10:24 |
| tristan | I am assuming you want some annotation log of the element.bst to exist in each element's artifact, that you can read back from the artifact in some way later | 10:24 |
| tristan | or you want annotation of... something else ? I'm also thinking that annotation means `git annotate` | 10:25 |
| tristan | and I'm also thinking that you are talking about annotating the project, not it's sources | 10:25 |
| ssam2 | I was using "annotate" to mean "attach any extra metadata that the user feels like attaching" | 10:25 |
| tristan | ssam2, based on those assumptions; I am saying you can git clone the project, and run a script which annotates each element, and [over]writes the result in a special member of each element's public data | 10:25 |
| tristan | anything that goes into public data, will just be in the resulting artifact | 10:26 |
| ssam2 | so you have a script that edits the .bst files on disk before each build ? that sounds horrible... | 10:26 |
| tristan | sure | 10:26 |
| tristan | ssam2, another thing I've been pondering and desiring for a while now, is a way to stream a buildstream project | 10:27 |
| tristan | I.e. using the '--' built into yaml | 10:27 |
| ssam2 | ah yeah, i remember discussing this before | 10:27 |
| ssam2 | in the context of flatpak conversions | 10:27 |
| tristan | with that; one could do it both ways | 10:28 |
| tristan | from project to stream, and stream to project | 10:28 |
| tristan | And buildstream could read a project stream in stdin | 10:28 |
| tristan | ssam2, that could allow for ./run-annotation-script.sh | bst build | 10:28 |
| tristan | without rewriting the checkout | 10:28 |
| ssam2 | right; yeah that might work | 10:28 |
| ssam2 | best thing for me to do might be to produce a proof of concept in that case | 10:29 |
| tristan | then; there is the question, which is happily outside of buildstream's hands, about reproducibility of artifacts | 10:30 |
| tristan | If you put non-reproducible stuff in public-data, I expect it to effect cache keys | 10:30 |
| tristan | yes it will | 10:30 |
| tristan | (git annotations should be fine and reproducible, though, just making the note) | 10:31 |
| ssam2 | right. which I think is what we want here | 10:32 |
| *** adds68 has quit IRC | 10:32 | |
| ssam2 | if you want to store random data in the artifact, just store it *in* the artifact, after all | 10:32 |
| ssam2 | the point here is to store extra stuff that is relevant for reproducibility/provenance | 10:32 |
| tristan | we store non-reproducible stuff in an artifact, but only we do | 10:32 |
| tristan | ssam2, in any case; I feel that if you want to construct a workflow like this, you dont really want annotations; commit shas should be better all around | 10:34 |
| tristan | i.e. they are just as strong at knowing what the data was... and you can consume them in scripts | 10:34 |
| tristan | if you ever think of a reason to | 10:34 |
| ssam2 | sure, I basically want each artifact to tell me, "this was built from commit xxxx of https://example.com/definitions" | 10:35 |
| tristan | yep, sounds sensible | 10:35 |
| tristan | beware of recursive pipelines up ahead :) | 10:35 |
| ssam2 | right, true | 10:35 |
| *** adds68 has joined #buildstream | 10:36 | |
| tristan | Not sure this is the right avenue to be honest - conflating what data is used to build with where it came from | 10:37 |
| tristan | there may be a more practical workflow | 10:37 |
| ssam2 | the only other method I can think of without sticking special cases into buildstream's internals, is having some kind of --extra-metadata commandline flag | 10:53 |
| gitlab-br-bot | push on buildstream@74-prevent-artifacts-from-containing-files-in-buildstream-build (by Tristan Maat): 16 commits (last: Ensure that artifact file permissions are set in the right order) https://gitlab.com/BuildStream/buildstream/commit/a968bab76201856a67c876be25745fee912c136b | 10:56 |
| gitlab-br-bot | buildstream: merge request (74-prevent-artifacts-from-containing-files-in-buildstream-build->master: Add warnings when staging to /buildstream/build) #93 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/93 | 10:56 |
| tristan | ssam2, yeah I mean - workflows to achieve whatever it is you want to achieve; just without trying to encode stuff into your artifacts to do it | 10:59 |
| tristan | as in, how does a group work with buildstream to do; what you wanna do | 11:00 |
| tristan | anyway; maybe, maybe not, it's worth some thought, though | 11:00 |
| *** adds68 has quit IRC | 11:01 | |
| *** adds68 has joined #buildstream | 11:01 | |
| ssam2 | one particular use case I have in mind for the artifact metadata is the sysroots produced by Baserock | 11:16 |
| ssam2 | the idea is those will get committed to https://ostree.baserock.org/releases/ and used for many years to bootstrap many builds | 11:16 |
| ssam2 | if they do get reused far and wide, eventually someone will be faced with this binary blob being part of their build and noone remembering where it came from. But if it carries a stamp that says "I was built from this commit of this repo!" then such situations are not so bad | 11:18 |
| ssam2 | inside an enterprise or something we can perhaps mandate good practices, but in the open source world there will always be cowboys ! | 11:18 |
| tristan | hmmm | 11:21 |
| tristan | ssam2, I think there might be better ways around this | 11:21 |
| tristan | ssam2, for instance; if we're talking about a sysroot deployment; we can do like we plan to do for flatpak, and design an element at the end which spits out some metadata | 11:22 |
| tristan | at the end of a pipeline you can read anything public on all dependencies | 11:22 |
| tristan | ssam2, that could; at least potentially produce something more practical for that purpose | 11:23 |
| ssam2 | but that element would need to get the details of the Git repo from somewhere | 11:23 |
| ssam2 | which can by definition not be VCS agnostic | 11:23 |
| tristan | ssam2, *would* it | 11:24 |
| tristan | ssam2, if you can reconstruct what you had to come to that result - why do you need to know the git repo which produced that same data from some other origin ? | 11:25 |
| ssam2 | i guess there's two things here | 11:25 |
| ssam2 | one is being able to reconstruct how the artifact was build in order to make a change; the other is being able to find the upstream that produced it | 11:26 |
| ssam2 | *was built | 11:26 |
| tristan | Anyway; I'm not specifically strongly against permitting third party stuff landing in artifacts | 11:26 |
| tristan | But if we're going to land anything at all - those things should be driven by concrete use cases | 11:26 |
| ssam2 | sure. is the baserock sysroots one good enough? or are more use cases needed to justify it? | 11:27 |
| tristan | ssam2, I dont believe the use case necessitates knowing anything about the VCS, if any, which was used to store the buildstream project | 11:28 |
| tristan | I mean; you want to take that binary blob and be able to build it again, right ? | 11:28 |
| ssam2 | like i said, there's two things | 11:28 |
| ssam2 | one is including an identifier of the upstream, which could be any free form text | 11:28 |
| tristan | Yeah, so I should also note - as a side - that project.conf already supports some general public data settings | 11:29 |
| ssam2 | ok, cool | 11:29 |
| tristan | Although I suspect it's element-type-specifict | 11:29 |
| ssam2 | so there's just being able to build it from sources | 11:29 |
| tristan | specific* | 11:29 |
| ssam2 | rather, being able to build it *without* sources | 11:29 |
| ssam2 | seems difficult to achieve that without dumping pretty much everything into the metadata, no? | 11:29 |
| tristan | also, reconstructing the source project from an artifact, is not exactly going to be easy :) | 11:30 |
| tristan | But still; it's probably a desirable thing | 11:30 |
| ssam2 | it seems a lot simpler to just allow adding a VCS stamp, and say "don't lose your source code" | 11:30 |
| tristan | ssam2, regarding recursive pipelines; stay in sync with juergbi ... but there is going to be an element type for representing external projects | 11:31 |
| ssam2 | interesting, OK | 11:31 |
| tristan | ssam2, and that element type is going to have an abstract Source, like any element | 11:32 |
| tristan | That Source being dumped is probably interesting | 11:32 |
| ssam2 | right! yes, very interesting | 11:32 |
| *** semanticdesign has joined #buildstream | 11:37 | |
| *** anthonywilliams has joined #buildstream | 12:08 | |
| gitlab-br-bot | push on buildstream@list-composition-directives (by Tristan Van Berkom): 9 commits (last: _options/optionpool.py: Use _yaml.composite() instead of _yaml.composite_dict()) https://gitlab.com/BuildStream/buildstream/commit/24efda780d0843591ac592ebfc7b028f5dccf557 | 12:18 |
| *** sstriker has joined #buildstream | 12:25 | |
| gitlab-br-bot | push on buildstream@remove-arches (by Tristan Van Berkom): 16 commits (last: _options/optionpool.py: Use _yaml.composite() instead of _yaml.composite_dict()) https://gitlab.com/BuildStream/buildstream/commit/24efda780d0843591ac592ebfc7b028f5dccf557 | 12:26 |
| tristan | hmph... gitlab busy today :-/ | 12:27 |
| * tristan suspects this is not gitlab being busy, but that gitlab.com's runners are not responding | 12:31 | |
| tristan | integration_unix has been waiting an hour on tlater's merge request: https://gitlab.com/BuildStream/buildstream/pipelines/12882345 | 12:32 |
| *** sprocket has joined #buildstream | 12:45 | |
| *** semanticdesign has quit IRC | 13:09 | |
| *** semanticdesign has joined #buildstream | 13:11 | |
| *** sprocket has quit IRC | 13:19 | |
| *** tristan has quit IRC | 13:23 | |
| *** tristan has joined #buildstream | 13:26 | |
| ltu | NB ALL: meeting is starting on this channel in 30 minutes. | 13:29 |
| tristan | tlater, sorry for not mentioning that before; just added one tiny adjustment to the staging error merge request | 13:34 |
| tristan | my bad, should have mentioned that before I guess :-/ | 13:34 |
| tristan | thankfully, gitlab is chugging along again | 13:35 |
| tlater | tristan: What's the context on this? | 13:35 |
| tlater | Oh, !93? | 13:35 |
| tlater | Ah, alright | 13:36 |
| tristan | yup: https://gitlab.com/BuildStream/buildstream/merge_requests/93/diffs#note_43687069 | 13:36 |
| tlater | Sorry, didn't notice, got a bunch of spam mail and hadn't checked yet... | 13:36 |
| tristan | I just commented now | 13:36 |
| tristan | branch is perfect, just dont want error message checking in test cases | 13:36 |
| tristan | if we want to get more fancy, we can start creating more machine readable errors (ala LoadErrorReason) | 13:37 |
| tristan | tlater, I think the ^C in bst shell issue fell through the cracks, or does it have a new revision up ? | 13:37 |
| * tristan was looking forward to closing that one :) | 13:38 | |
| tlater | tristan: I've been testing the different platforms quite extensively... | 13:38 |
| tristan | Ah sweet | 13:38 |
| tlater | I'll put up another revision in 1-2 hours | 13:38 |
| tristan | Unfortunately I dont see a way to regression test it | 13:38 |
| tristan | but meh, a fix will be great :) | 13:38 |
| tristan | ok... big rebase coming up | 13:39 |
| tristan | probably no conflicts though | 13:39 |
| * tristan prepares to merge list-composition-directives | 13:40 | |
| tristan | pipelines have mostly passed, linux_integration did, and unix_integration is gonna take a while but there's no reason to fail there if it passes on linux | 13:41 |
| tristan | also, /me excited to see updated docs | 13:41 |
| tlater | tristan: On the C-c merge request, it seems that killing the process in the exception handler is necessary | 13:41 |
| tlater | Otherwise we get an error in the child python process | 13:42 |
| gitlab-br-bot | push on buildstream@master (by Tristan Van Berkom): 9 commits (last: _options/optionpool.py: Use _yaml.composite() instead of _yaml.composite_dict()) https://gitlab.com/BuildStream/buildstream/commit/24efda780d0843591ac592ebfc7b028f5dccf557 | 13:42 |
| tristan | tlater, that doesnt make sense to me :-/ | 13:42 |
| tristan | hold sec | 13:42 |
| tristan | ummm | 13:43 |
| tristan | still | 13:43 |
| tristan | tlater, how do we know that that wont cause bash to exit when running `/bin/sh -i` in bst shell ? | 13:43 |
| tristan | I suppose bash will setsid() by itself ? | 13:44 |
| tristan | and is expected to ? | 13:44 |
| tlater | Oh, hm, that's annoying | 13:44 |
| tristan | yeah I think not, I made sure that works | 13:44 |
| * tlater tries anyway | 13:44 | |
| tristan | and annoyingly, it works by *sharing* the process group | 13:44 |
| *** Angelos has joined #buildstream | 13:45 | |
| tlater | Yeah, it dies, unfortunately | 13:45 |
| tristan | which means, if the bubblewrap child process receives a signal, so do we, cause we're in the same group | 13:45 |
| tlater | Just 'pass' causes an exception in the unix platform and a zombie in the linux platform though :/ | 13:45 |
| tristan | hmmm | 13:46 |
| tristan | unfortunate | 13:46 |
| tristan | needs some more thought then :-/ | 13:46 |
| tristan | tlater, I knew this one would be a hard problem hehe | 13:46 |
| tristan | welcome to signals and job control ! | 13:46 |
| tlater | \o/ | 13:46 |
| * tlater will solve the checkout exception first instead | 13:47 | |
| *** cs_shadow has joined #buildstream | 13:57 | |
| *** hashpling has joined #buildstream | 13:59 | |
| ltu | OK, shall we begin? | 14:00 |
| tristan | Yay \o/ ! | 14:00 |
| tristan | nice turnout | 14:00 |
| * tristan tries to resolve wiki... slooowly | 14:01 | |
| sstriker | indeed | 14:01 |
| * tristan resorts to email | 14:01 | |
| tristan | sstriker, nice to see you around here :) | 14:01 |
| ltu | tristan, shall we ask folk to confirm if they're taking part with a raised hand or something? | 14:03 |
| tristan | ltu, lets start, I just realized | 14:04 |
| tristan | GNOME is having a mass reboot session | 14:04 |
| ltu | I'm not sure on the protocol: that may not be required. | 14:04 |
| ltu | ok | 14:04 |
| tristan | hence lack of wiki | 14:04 |
| ltu | alright so item one: | 14:04 |
| * persia laments the lack of mootbot | 14:04 | |
| ltu | === Blockers for BuildStream 1.0 release === | 14:04 |
| ltu | Suggested by: tristan | 14:04 |
| ltu | 'No feature additions beyond the recent format changes we agreed on, we'd just like to shake the tree and get a hold on what bugs need to be closed for a 1.0 release. ' | 14:04 |
| ltu | .... | 14:04 |
| tristan | Alright thanks ltu :) | 14:05 |
| ssam2 | o/ | 14:05 |
| tristan | So for me this has been an invaluable exercise when initially releasing Glade, it may be less intensive because we already have some eye | 14:05 |
| tristan | s | 14:05 |
| tristan | What I'd like to get out of this agenda point, is a clearer picture of what we are comfortable with in terms of tidying up before 1.0 | 14:06 |
| tristan | ssam2... go ahead | 14:06 |
| ssam2 | was just going to suggest two things on my plate which would break things | 14:06 |
| *** daniel has joined #buildstream | 14:07 | |
| ssam2 | 1 being the multiple cache support proposal, and the other being stricter errors on overlaps | 14:07 |
| tristan | Right, OK - as this is a bit more involved than agenda points... I have a scratch area I'm going to collect | 14:07 |
| *** daniel is now known as Guest64284 | 14:07 | |
| tristan | Ok, I think stricter errors on overlaps is reasonable | 14:08 |
| tristan | Is there a reason why we think multiple cache support should block 1.0 ? | 14:08 |
| sstriker | Overlaps in terms of produced files? | 14:08 |
| ssam2 | in terms of: i stage 3 dependencies and each provides /bin/sh | 14:09 |
| persia | sstriker: In terms of two elements that have the same file, where only one can be in a combined element. | 14:09 |
| sstriker | *nod* thanks | 14:09 |
| ssam2 | multiple cache support could break user configurations | 14:09 |
| ssam2 | i guess we could have backwards compatibility though | 14:09 |
| ssam2 | so doesn't really need to block 1.0 | 14:09 |
| tristan | ssam2, that is a good point | 14:09 |
| persia | Could or must? If must, I wonder if we can add something to make it could in 1.0. If could, can there be a simple migration script for users? | 14:10 |
| tristan | However - I feel that one time breaking user configuration post 1.0 for this is not a huge concern | 14:10 |
| sstriker | I concur | 14:10 |
| juergbi | would be nice to avoid it, though | 14:10 |
| ssam2 | fine by me | 14:10 |
| persia | Nice to avoid, but part of the signal sent by a new major version number is the potential to break config. Difference between 1.1 and 2.0 | 14:11 |
| tristan | juergbi, certainly - and I would like it to be stable in 1.2 (or whatever is "next stable") | 14:11 |
| ssam2 | i think backwards compat is not too hard, the current proposal suggests replacing the dict with a list. we can handle both cases | 14:11 |
| tristan | Back compat for user configuration will be doable, but I believe we need to break it once for canonical URIs | 14:11 |
| tristan | Which I believe is orthogonal to multiple cache support | 14:12 |
| ssam2 | my understand is you want it as a prerequisite | 14:12 |
| * persia is unconvinced that the canonical URI design is sufficiently complete to avoid delaying the 1.0 release for a long time | 14:12 | |
| ssam2 | but the old URIs would continue to work | 14:12 |
| ssam2 | *my understanding | 14:12 |
| tristan | ssam2, yes - would they ? that would be relatively high cost and annoying no ? | 14:13 |
| ssam2 | on the server side, no changes needed at all | 14:13 |
| ssam2 | client side... it doesn't /seem/ bad, but i have been wrong before :-) | 14:13 |
| tristan | ssam2, however it imposes something on the server side which is inconvenient, I think | 14:13 |
| juergbi | i also wouldn't expect it to be high cost but haven't thought about it much | 14:14 |
| tristan | ssam2, I.e. we always have to continue supporting ssh push / http pull - for linux, forever | 14:14 |
| tristan | ssam2, whereas, with a single uri, if we change things behind the scenes, no big deal | 14:14 |
| tristan | In any case I think this is not a huge point of contention | 14:15 |
| tristan | My thoughts are that A.) we can break configuration API once for the sake of canonical URI for push/pull ... and B.) that need not block 1.0 | 14:15 |
| tristan | But a one time break will be expected and noted in release notes. | 14:16 |
| tristan | (for artifact client side URI configuration only) | 14:16 |
| tristan | That would make it, not a blocker - Is that alright ? | 14:16 |
| ssam2 | fine by me | 14:16 |
| juergbi | ok, but i would keep compatibility, if it's easy enough | 14:17 |
| sstriker | I can live with that | 14:17 |
| tristan | juergbi, what I certainly dont want, is a gray area where we "try to keep compat" long term without a promise | 14:18 |
| tristan | juergbi, which is why I feel like ironing out the kinks once and explicitly breaking, is nice | 14:18 |
| tristan | it allows for a point of no return, and stricter future | 14:18 |
| persia | I want that. I would like to see compatibility kept for everything, if possible, but only a few promises, as too many constrain too much. | 14:19 |
| tristan | Agreed, it is for certain that; when we make aggressive changes to the artifact server... sysadmin work will be required | 14:19 |
| tristan | However that should be doable without breaking client config | 14:20 |
| juergbi | do we want a version number in config files? | 14:21 |
| tristan | Alright - I'm marking this down, we're straying off course - it's not a blocker, but further discussion may be needed on the policy of breakage of user configuration. | 14:21 |
| juergbi | fair enough | 14:21 |
| tristan | juergbi, My thought is no, until we do | 14:22 |
| tristan | That is largely a bridge we can cross when we get there | 14:22 |
| persia | If we think we will want a version number in the future, better to start with one now. | 14:22 |
| juergbi | agreed | 14:22 |
| persia | Crossing the bridge later is painful. | 14:22 |
| juergbi | no version can be considered 'version 1' or so | 14:22 |
| tristan | persia, a versionless configuration file, is version 0, or 1 | 14:22 |
| tristan | exactly | 14:22 |
| * persia has crossed that bridge lots of times, and is always happier when someone has already thrown a rope over the span | 14:22 | |
| tristan | persia, in other buildstream cases, you are correct, I disagree about this one. | 14:23 |
| tristan | As this was raised - I'm marking it down | 14:24 |
| tristan | Initial Revision for configuration | 14:24 |
| tristan | However, I dont think it's a blocker | 14:24 |
| tristan | I have only 2 blockers on the list as of now (I meant to spend time reviewing what I wanted to add, but then didnt :-/) | 14:25 |
| tristan | I should at least enumerate those | 14:25 |
| tristan | - https://gitlab.com/BuildStream/buildstream/issues/113 | 14:25 |
| tristan | The above is distinguish between `bst build --track` and `bst build --track-save` | 14:26 |
| persia | GNOME finished rebooting: shall we use https://etherpad.gnome.org/p/buildstream20171017 for notes? | 14:26 |
| tristan | Because `bst build --track` will have a possibly unwanted side-effect of rewriting the project | 14:26 |
| tristan | persia, after the meeting, ltu will be updating the wiki with action points and such | 14:27 |
| tristan | ltu, and here is one | 14:27 |
| tristan | ACTION: Tristan to update the bug list with blocker bugs | 14:27 |
| ltu | ok | 14:27 |
| tristan | So, I dont think there is any contention for issue 113, I've discussed it with Sam, and it's fairly simple to do | 14:28 |
| tristan | And not doing it before 1.0 means we break things if we ever do it later | 14:28 |
| juergbi | agreed | 14:28 |
| tristan | The other is https://gitlab.com/BuildStream/buildstream/issues/97 - Apply pep 3102 to all public API surfaces | 14:29 |
| sstriker | we should definitely do those | 14:29 |
| sstriker | Can I continue on the track one for one more min? | 14:29 |
| persia | +1 on landing 113 before 1.0 | 14:29 |
| sstriker | More related, not the same | 14:29 |
| tristan | sstriker, yes please sorry to get ahead :) | 14:29 |
| sstriker | The current behaviour of bst build --track is to do recursive tracking | 14:29 |
| sstriker | Which is not always desired (I'd argue it usually isn't) | 14:30 |
| tristan | Ah, very good point | 14:30 |
| tristan | in contrast with `bst track` | 14:30 |
| sstriker | Right | 14:30 |
| sstriker | I suggest a behaviour change before 1.0 | 14:30 |
| tristan | Yes, I concur, I'm not sure what it will be, but will file a bug | 14:31 |
| tristan | it could be multiple --track <element> --track <element>, or it could use a config file | 14:31 |
| tristan | but lets brainstorm that separately | 14:31 |
| sstriker | +1 | 14:32 |
| sstriker | Assume that is a potential blocker due to behavioural change | 14:32 |
| tristan | Certainly | 14:33 |
| tristan | So... moving on... (mini timer in my head...)... | 14:33 |
| tristan | pep 3102 is a nitpik of mine, but means a stronger python API surface | 14:34 |
| persia | I like pep 3102, but feel like it could be added later, if nobody gets around to the tedious bits. | 14:34 |
| sstriker | +1 on that one. Will reap benefits later | 14:34 |
| persia | As long as there are no major API changes between 1.0 and 1.2, safe to defer. If major API changes are expected, then we should do now. | 14:34 |
| tristan | What it means is: def function(positional1, positional2=default_value, *, keyword_arg1=default_value...) | 14:34 |
| sstriker | Not sure that it can, given positional arguments? | 14:34 |
| juergbi | strictly speaking, it breaks backward compatibility, so +1 as blocker | 14:35 |
| tristan | So, if everything distinguishes, and positional arguments (possibly with default values) are reduced, it means that we can always move args to become positional, but not the reverse | 14:35 |
| tristan | So it really is a thing about back compat of API | 14:35 |
| tristan | persia, yes it implicitly breaks API, and adds a measure of protection for future extensibility | 14:36 |
| sstriker | +1 for taking this hit now rather than later | 14:36 |
| tristan | Ok, marked that... | 14:37 |
| tristan | Has anyone any other blocker ideas ? | 14:38 |
| tristan | I am tempted to consider things such as: Need early exit and comprehensive error when host kernel lacks CONFIG_USER_NS - https://gitlab.com/BuildStream/buildstream/issues/92 | 14:38 |
| persia | I would like a canonical artifact serialisation format, but I don't know whether that needs to be defined before the first release or can come later. | 14:38 |
| tristan | persia, serialization format; do you mean: Stability of artifact content as an API surface ? | 14:39 |
| persia | Probably :) | 14:39 |
| tristan | Well, ssam2 and I discussed this here today briefly | 14:40 |
| tristan | But I feel like this is better punted to second stable line | 14:40 |
| tristan | Lets take some more time to learn about this before calling this part stable | 14:40 |
| persia | I'm fine with punting, if it is safe to punt. Just wanted to check. | 14:41 |
| tristan | Thoughts ? | 14:41 |
| sstriker | tristan: while #92 is annoying, I'm not sure it is a blocker. | 14:41 |
| tristan | sstriker, yeah; I was going to ask if I should be considering these | 14:41 |
| sstriker | They can be addressed in patch releases | 14:41 |
| tristan | There are annoying things, like the ^C behavior in the interactive shell, which are also annoying | 14:42 |
| tristan | But things about not detecting the dependencies well and having unpleasant surprises, mean immediate fail for some new users | 14:42 |
| sstriker | Won't break backward compat though. Question is what do you want the experience bar to be for 1.0 | 14:42 |
| tristan | But I'm personally ambivalent about calling that a blocker | 14:42 |
| juergbi | maybe mark it as nice to have for 1.0? | 14:42 |
| sstriker | Becuase if we consider these things we open up the door for a number of others | 14:42 |
| tristan | sstriker, that is also a _very_ good question | 14:43 |
| tristan | Ok - so in the interest of sure footed progress, I will disregard those from blockers. | 14:43 |
| persia | Given the timing, I think 1.0 should prefer a safe and likely backwards-compatible API to user experience. For 1.2, there are lots of things to make it better, but more users sharing how they experience it will help us make that list. | 14:43 |
| sstriker | staging performance, startup performance, incremental builds, would be what springs to mind. Think that's better left for next point release if we are on a timed release schedule. | 14:44 |
| sstriker | +1, exactly. | 14:44 |
| tristan | I'll note that I will not tie GNOME to stable BuildStream 1.0 | 14:44 |
| tristan | But will hope that in the future we can depend on stable BuildStream, perhaps via distro packages | 14:45 |
| persia | tristan: I think GNOME can move to 1.1 without an issue. But I think long-term, it would be nice to release BuildStream simultaneously with GNOME, and have the released BuildStream work with the released GNOME for the life of both. | 14:45 |
| tristan | persia, that still implies that GNOME will use unstable buildstream internally in advance of a release | 14:46 |
| persia | tristan: Yes, and intentionally :) | 14:46 |
| tristan | persia, which I think is "okay", but will hope to avoid after one or two release cycles | 14:46 |
| sstriker | I am not sure it is desirable to tether the releases | 14:46 |
| tristan | If it does happen, it will be because of an explicit feature request from GNOME | 14:47 |
| tristan | indeed, it creates friction | 14:47 |
| persia | I think it is important to allow GNOME to do that, but not to force GNOME to do either. | 14:47 |
| tristan | That will be discussed in the next agenda point though I think. | 14:47 |
| tristan | So... lets wrap this up first | 14:47 |
| tristan | I dont have other blockers on my plate | 14:48 |
| tristan | Anyone ? | 14:48 |
| tristan | Ok | 14:48 |
| * tristan simultaneously ran through the buglist to double check. | 14:48 | |
| tristan | ltu, since you announced the last one, would you like to do the honors ? | 14:49 |
| tristan | :) | 14:49 |
| ltu | alright | 14:49 |
| ltu | I think a lot of it will have just been covered then | 14:49 |
| ltu | second agenda point is: | 14:49 |
| ltu | === Release Schedule === | 14:49 |
| ltu | 'We should discuss how/if BuildStream releases will align with GNOME releases. Also I think we should inform everyone about the release cycle and also the devel / stable branch (more of an 'announcement' than a discussion perhaps).' | 14:49 |
| persia | I was under the impression that, as a GNOME project, BuildStream was strongly encouraged to follow the GNOME release schedule. In practice, I don't think it matters much. | 14:50 |
| tristan | Ok so before we split hairs, lets note the difference between following the GNOME release schedule, and tethering the relases | 14:50 |
| tristan | The difference I see here, is that GNOME releases need not block on BuildStream in general | 14:51 |
| tristan | I.e. not tethered | 14:51 |
| tristan | Following the schedule for our stable releases, I think is orthogonal for that | 14:51 |
| tristan | *to | 14:51 |
| tristan | Also persia is exactly correct; strongly encouraged but doesnt matter a great deal | 14:52 |
| sstriker | Concur. I also like the "strongly encouraged" vs "must" | 14:52 |
| sstriker | (not suggesting we don't at this stage) | 14:53 |
| tristan | So, if people are unfamiliar with the GNOME release schedule, it's pretty simple: https://wiki.gnome.org/Schedule | 14:53 |
| tristan | I would posit that we target the *next* GNOME release... I think 3.30, as our second stable | 14:54 |
| tristan | Giving us more time for our first cycle, because we're late to the party anyway | 14:54 |
| persia | So, the concern I was expressing earlier is that I think that if GNOME modules have BuildStream definitions, the BuildStream version that supports those definitions should be maintained about as long as those modules, just from an end-user experience point of view. It might take a couple cycles to get there. | 14:55 |
| tristan | And I would "generally" like to follow the hard dates | 14:55 |
| tristan | Ah | 14:55 |
| tristan | persia, that is not in our court, however | 14:55 |
| tristan | persia, with my brand spanking new release team hat on however, I can say that in general there is some maintenance at least of last stable | 14:56 |
| tristan | jjardon[m], could enlighten us more, though. | 14:56 |
| persia | How is the length of support of some release of buildstream not in our court? | 14:56 |
| tristan | persia, Ahh ok I misunderstood | 14:56 |
| persia | Right, so I just want the BuildStream release & support model to be something that would allow the behaviour I described. Whether otherr folk in GNOME decide to do so is up to them. | 14:57 |
| tristan | So you mean, that we continue to backport bug fixes to our stable branches, for the stable versions which are still required by GNOME maintained modulesets. | 14:57 |
| * persia may go discuss the matter with them, but that is outside the scope of this meeting. | 14:57 | |
| tristan | persia, does that match your thinking ? | 14:57 |
| tristan | I.e. "at least" as far back as maintained GNOME stable releases go | 14:58 |
| persia | Some bug fixes: there's a difference between "crashes", "misspelling happens to be a disturbing word", etc. and "not as fast as I want". | 14:58 |
| persia | But otherwise, yeah. | 14:58 |
| tristan | Ok, I certainly approve | 14:59 |
| tristan | It may one day come down to a matter of resourcing :) | 14:59 |
| tristan | but lets ride with that | 14:59 |
| persia | It always does :) | 14:59 |
| tristan | So asides from this; When I say I would "generally" like to follow the hard dates - I also feel that some of this does not apply to us, in the same way as it does for GNOME | 15:01 |
| tristan | I.e. we wont have string freeze - until such a day that we might implement i18n properly for our frontend(s) | 15:01 |
| tristan | And, I dont think we care about UI freeze either, this is very centric to how documenters/designers are preparing what the next "GNOME UX" will look and feel like | 15:02 |
| juergbi | yes, i think we can ignore those | 15:02 |
| persia | More generally, I suggest BuildStream not observe freezes until there is a group that is separate from the developers that needs to do follow-on preparation work for release. | 15:02 |
| tristan | But an API freeze one month before code freeze, and then release; seems reasonable to me | 15:03 |
| persia | So, if there are translation volunteers, honor string freeze, etc. | 15:03 |
| tristan | persia, right; for translations; we would need to first do work to make it translatable | 15:03 |
| tristan | but yes | 15:03 |
| tristan | For us though, it means we can develop an internal model where we A.) Land bigger features early in the cycle... B.) Reject features after a feature freeze... C.) Leave us some time to address issues before release, without new features landing | 15:05 |
| tristan | persia, this is something I want, and will reduce cost of maintenance overall | 15:05 |
| sstriker | that sounds sane | 15:05 |
| juergbi | i agree | 15:05 |
| tristan | So, to me, doing it on a 6 month cadence alongside GNOME, is not a problem; its all around good stuff to do :) | 15:06 |
| ssam2 | +1 | 15:06 |
| sstriker | +1 | 15:06 |
| tristan | Alright, ltu; would you like to take the action of summarizing that somewhere on the wiki ? | 15:06 |
| tristan | or would it be rude to voluntell you that :D | 15:07 |
| tristan | heh | 15:07 |
| ltu | sure, doing it atm | 15:07 |
| ltu | :) | 15:07 |
| ltu | that's exactly what i wanted to email out after the meeting and confirm :) | 15:07 |
| tristan | ACTION: ltu to summarize release schedule policy from our discussion | 15:07 |
| ltu | alright, last point on the agenda, a nice easy one: | 15:07 |
| ltu | === Next meeting date === | 15:07 |
| ltu | Exactly 4 weeks from now? That would be Tuesday 14 November. Then every 4 weeks re-occurring? | 15:08 |
| jjardon[m] | tristan: what is the question? R-T only maintains the current stable and the next release (current unstable) | 15:08 |
| tristan | ltu, I think you're a bit quick on the trigger there | 15:08 |
| ltu | hhmm, ok... | 15:08 |
| tristan | jjardon[m], ok - good to know :) | 15:08 |
| jjardon[m] | tristan: actually, we support the current stable only for a while, until we release .2 | 15:09 |
| tristan | In any case; I think we've spoken enough about that, but just in case - Anything that we should be getting straight about BuildStream's release cycle ? | 15:09 |
| jjardon[m] | then is the community who upgrade the modulesets, if needed | 15:09 |
| tristan | jjardon[m], please - this is not random discussion, we're having a monthly team meeting right now | 15:09 |
| tristan | jjardon[m], if you would like to join, just please follow the discussion :) | 15:09 |
| jjardon[m] | tristan: you ping me | 15:10 |
| tristan | I mentioned you yes... | 15:10 |
| * jjardon[m] dissapears | 15:10 | |
| tristan | Ok... Any other points to discuss about BuildStream release schedule ? | 15:10 |
| tristan | Just wanted to give people a chance to ring in... | 15:11 |
| tristan | Ok sorry ltu - next point then | 15:11 |
| tristan | === Next meeting date === | 15:11 |
| ltu | yeah, sorry for jumping ahead there. | 15:11 |
| persia | I like every 4 weeks rather than every month. | 15:11 |
| ltu | makes more sense to me. | 15:11 |
| tristan | So that is fine with me | 15:11 |
| tristan | Also always lands on a tuesday, nice - no mondays no fridays is a rule I think | 15:12 |
| sstriker | +1 here too. I'm assuming this is the best time for everyone? | 15:12 |
| tristan | I think so, I mean I have to be up late, but it's only me and I dont mind, and 10 am EST is nice and after first cup of coffee | 15:13 |
| tristan | while BST lands in midday | 15:13 |
| * persia has lots of IRC meetings on Tuesdays, making it a very good day. This also happens not to conflict, if we assert it stays 14:00 UTC, and doesn't move. | 15:13 | |
| tristan | Oh ! | 15:13 |
| tristan | Wait | 15:13 |
| juergbi | DST is ending in Europe/US before the next meeting | 15:13 |
| tristan | You guys are going to run one hour away | 15:13 |
| juergbi | do we keep UTC or British time? | 15:13 |
| persia | tristan: 14:00 UTC will always be the same for you. Just some folk have to change. | 15:13 |
| tristan | persia, ah thanks :D | 15:13 |
| tristan | yes | 15:13 |
| juergbi | yes, probably best | 15:13 |
| ltu | I was thinking to always keep to UTC. | 15:14 |
| ltu | OK so that seems to be confirmed then. I'll remind everyone one week before the next meeting of course | 15:15 |
| persia | Nice thing about keeping UTC is that it avoids the annoying times when different governments do DST on different schedules. Doesn't affect us now, as most folk change before the next meeting, but it could in the future. | 15:15 |
| sstriker | kk, i'll need to change some things on my end to make that work. UTC is a bit painful, as it tends to conflict with meetings that do move with US timezone | 15:15 |
| sstriker | There is exactly 4 weeks of the year where timezones are out of whack. I'd rather take that than a meeting that is on a different time depending on half of the year | 15:16 |
| tristan | Ummm | 15:16 |
| tristan | I propose we move this to a side channel | 15:17 |
| tristan | For future meetings | 15:17 |
| sstriker | kk | 15:17 |
| persia | +1 on discussion of timezones after the meeting | 15:17 |
| sstriker | 4 weeks we can settle on | 15:17 |
| tristan | I have no issue with lurkers at all, and encourage it; but better to avoid distractions from gitlab bots and those who, very understandably, have no idea we're having a meeting :D | 15:18 |
| tristan | so -> #buildstream-meeting, and log the minutes | 15:19 |
| juergbi | ok, sounds fine to me | 15:19 |
| ltu | ok | 15:19 |
| tristan | So that's not a huge agenda point | 15:20 |
| tristan | shall we open the floor for any other points ? | 15:21 |
| ltu | tristan, the other other thinh i had was: === Any other business === | 15:21 |
| ltu | thing* | 15:21 |
| tristan | ltu, exactly :) | 15:21 |
| ltu | :) | 15:21 |
| gitlab-br-bot | buildstream: merge request (102-run-ci-as-non-root-user->master: Resolve "Run CI as non-root user") #104 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/104 | 15:22 |
| gitlab-br-bot | buildstream: merge request (102-run-ci-as-non-root-user->master: WIP: Resolve "Run CI as non-root user") #104 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/104 | 15:22 |
| tristan | So, in the future with a #buildstream-meeting channel happening exclusively for meetings; we can always just end with that | 15:22 |
| sstriker | I think we would be getting ahead of ourselves if we discussed what the focus would be for beyond 1.0. Maybe more for next meeting. | 15:22 |
| tristan | And people can feel free, but not obligated, to hang around longer | 15:23 |
| tristan | Unless there are any adamant points raised last minute, hopefully they can be raised directly before the meeting :) | 15:24 |
| tristan | sstriker, agreed, that is also quite an open topic we cant discuss very efficiently right now | 15:24 |
| tristan | Actually, we should probably be doing that next week yes | 15:25 |
| tristan | *month | 15:25 |
| tristan | next 4 weeks... because assuming we're closing in on first stable; we should be looking at those mountainous feature branches that contributors have their mouths watering and wanting to land :) | 15:25 |
| tristan | And thinking, lets get to merging this early-cycle | 15:26 |
| tristan | sstriker, like that ? | 15:26 |
| persia | Indeed: by next time, we should have released, and be able to merge a few things and discuss the remainder. | 15:26 |
| tristan | I had not observed the timing of it but indeed it's already close to "early next cycle" | 15:27 |
| *** hashpling has left #buildstream | 15:28 | |
| *** Guest64284 has quit IRC | 15:28 | |
| tristan | For today, are we ready to adjourn ? | 15:29 |
| ltu | nothing more from me | 15:29 |
| ssam2 | nothing from me | 15:30 |
| sstriker | +1 | 15:30 |
| juergbi | _o_ | 15:30 |
| tristan | We didnt cover this in release schedule, but petty detail, I'd like to also follow GNOME style release numbering | 15:30 |
| tristan | even minor number = stable, odd minor number = devel | 15:31 |
| persia | +1 | 15:31 |
| tristan | That's all :) | 15:31 |
| tristan | Ok - thank you all for coming in such great numbers ! | 15:31 |
| tristan | Was a pleasure :) | 15:32 |
| tristan | jjardon[m], Sorry to have seemed to snap this way, we will use a separate channel for meetings in the future (and you're TOTALLY welcome to join in :)) | 15:32 |
| tlater | Sorry for triggering the gitlab CI bot | 15:33 |
| * tlater forgets it does that | 15:33 | |
| tristan | yeah separate room will be better | 15:34 |
| tristan | We'll make sure to announce here as well directly before starting | 15:34 |
| persia | Can we have mootbot? | 15:34 |
| persia | Is there a general gimpnet mootbot, or would it need a tender? | 15:34 |
| * tristan doesnt know what that is, is it a funny quote bot ? | 15:34 | |
| * tristan always wanted a bot that starts randomly telling 'ur mamma' jokes when the channel gets too quiet | 15:35 | |
| tristan | but I think people wouldnt like it :) | 15:35 |
| ssam2 | https://meetbot.gnome.org/ exists | 15:36 |
| persia | https://wiki.debian.org/MeetBot and https://wiki.ubuntu.com/ScribesTeam/MootBot and https://git.openstack.org/cgit/openstack-infra/meetbot are three instances I know of today. There may be more. | 15:36 |
| tristan | persia, there is something that Services does I think, about starting/stopping logging and minutes | 15:36 |
| persia | ssam2: That's probably the right one to choose :) | 15:36 |
| tlater | Is there an easy way to get an element with everything it needs to run stages/builds in the tests? | 15:37 |
| * tlater is a little stuck on unit testing :/ | 15:38 | |
| tristan | persia, here: https://wiki.gnome.org/Sysadmin/IRC | 15:38 |
| tristan | persia, I think it's indeed proxied through Services | 15:38 |
| tristan | who may be doing other stuff other than meetbot | 15:38 |
| tristan | looks like there is a process for registering | 15:39 |
| persia | Indeed. It would be my preference to replace brlogger with logbot, and register a meetbot if meetings are held here. | 15:39 |
| persia | If meetings are to be held in #buildstream-meeting or similar, meetbot should go there. | 15:40 |
| tristan | agreed | 15:40 |
| persia | Is that something you can sort? | 15:40 |
| tristan | haha you caught that ! | 15:41 |
| tristan | sly persia | 15:41 |
| tristan | I am able, ok | 15:41 |
| persia | Cool. Thanks :) | 15:41 |
| tristan | ACTION: Tristan to arrange the bot for next meeting | 15:41 |
| tristan | Regarding brlogger ... I dunno about that one | 15:42 |
| persia | Why not? | 15:42 |
| tristan | maybe requires a service I dont know if GNOME runs one | 15:42 |
| tristan | separate things | 15:42 |
| persia | If GIMPnet typically provides a service, and BuildStream is a GNOME project, alignment makes sense. | 15:42 |
| persia | The same Sysadmin/IRC page explains how to add logbot | 15:42 |
| * tristan rechecks the wiki | 15:42 | |
| tristan | persia, you should keep in mind we did have a semi-controversial discussion on d-d-l years ago, and concluded that if any logging whatsoever is going to happen, it _must_ be indicated in the topic | 15:43 |
| tristan | And I'm not sure that something other than the meetings bot was implemented | 15:43 |
| tristan | however, maybe we can use the same bot for constant logging of #buildstream too ? | 15:43 |
| persia | Yes. The current /topic says "IRC logs: <<URL>>". I would expect that to be true with a different URL. | 15:43 |
| persia | Yes the meeting channel should also be logged. GNOMie/MeetBot/MootBot/whatever makes mistakes sometimes: while the summaries are lovely, backup is good. | 15:44 |
| tristan | "Other details: logbot" | 15:45 |
| tristan | appears on the wiki page | 15:45 |
| tristan | I dont know how long ago it's from, or who is Byron Jones, and if he still runs that bot | 15:45 |
| persia | Doesn't hurt to email him :p | 15:45 |
| persia | Bot seems to be running, as is the log site. | 15:46 |
| tristan | ok ok, I'll put aside some time for that - instead of spending time drafting crazy crypto features :) | 15:46 |
| tristan | good ? | 15:46 |
| * tristan ducks | 15:46 | |
| *** Angelos has quit IRC | 15:47 | |
| * persia fails to submit a large relatively prime number to be logged by brlogger | 15:47 | |
| tristan | Something to think about... Creating BuildStream projects for creating distro packages, of BuildStream | 15:53 |
| tristan | we could start with jonathanmaw's dpkg work and create a ppa with that :) | 15:53 |
| tristan | also, might give me something to talk about at fosdem :) | 15:54 |
| persia | heh. Side effect of providing nice "hello world" examples of how to create distro packages with buildstream. | 15:56 |
| tristan | w00t ! | 15:58 |
| tristan | docs update: http://buildstream.gitlab.io/buildstream/formatintro.html#format-directives | 15:58 |
| *** sstriker has quit IRC | 16:01 | |
| jjardon[m] | tristan: haha no problem at all! sorry I interrupted your meeting | 16:09 |
| tristan | jjardon[m], no worries :) | 16:11 |
| tristan | jjardon[m], I hope you will come 4 weeks later :) | 16:11 |
| tristan | bochecha was intending to lurk... I wanted to tell him about declarative list composition... | 16:12 |
| *** jude has quit IRC | 16:27 | |
| *** ssam2 has quit IRC | 16:28 | |
| gitlab-br-bot | push on buildstream@74-prevent-artifacts-from-containing-files-in-buildstream-build (by Tristan Maat): 1 commit (last: Add warnings when staging to /buildstream/build) https://gitlab.com/BuildStream/buildstream/commit/a8f3fcb146903fb19a2d6edd111f3fa820e3a81b | 16:36 |
| *** bochecha has joined #buildstream | 16:36 | |
| gitlab-br-bot | buildstream: merge request (74-prevent-artifacts-from-containing-files-in-buildstream-build->master: Add warnings when staging to /buildstream/build) #93 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/93 | 16:36 |
| *** bochecha has quit IRC | 16:40 | |
| *** bochecha has joined #buildstream | 16:40 | |
| gitlab-br-bot | buildstream: merge request (102-run-ci-as-non-root-user->master: WIP: Resolve "Run CI as non-root user") #104 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/104 | 16:43 |
| gitlab-br-bot | push on buildstream@102-run-ci-as-non-root-user (by Tristan Maat): 1 commit (last: .gitlab-ci.yml: Drop root privileges for some tests) https://gitlab.com/BuildStream/buildstream/commit/2a263d095cd4755feb1228220c1f83d723b186cd | 16:43 |
| gitlab-br-bot | buildstream: merge request (102-run-ci-as-non-root-user->master: Resolve "Run CI as non-root user") #104 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/104 | 16:44 |
| *** bochecha has quit IRC | 16:50 | |
| *** jonathanmaw has quit IRC | 17:08 | |
| *** tlater has quit IRC | 17:11 | |
| *** cs_shadow has quit IRC | 19:58 | |
| *** givascu has quit IRC | 20:49 | |
| *** tristan has quit IRC | 21:11 | |
| *** semanticdesign_ has joined #buildstream | 21:44 | |
| *** semanticdesign has quit IRC | 21:46 | |
| *** semanticdesign_ has quit IRC | 22:22 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!