| paulsherwood | persia: did you intend irony there, or an actual insight? | 06:27 |
|---|---|---|
| paulsherwood | changing the text will often (but not always) change the behavour, but other things affect behaviour too | 06:28 |
| *** paulwaters_ has quit IRC | 07:10 | |
| *** paulwaters_ has joined #trustable | 07:10 | |
| *** noisecell has joined #trustable | 07:42 | |
| *** Kinnison has quit IRC | 07:48 | |
| *** Kinnison has joined #trustable | 07:49 | |
| *** willbarnard has joined #trustable | 07:56 | |
| *** weyfonk has joined #trustable | 08:21 | |
| *** willbarnard has quit IRC | 08:29 | |
| *** willbarnard has joined #trustable | 08:30 | |
| *** toscalix has joined #trustable | 08:34 | |
| *** paulwaters_ has joined #trustable | 09:24 | |
| flatmush | STANDUP! Order: flatmush, noisecell, willbarnard | 09:50 |
| flatmush | ## Ben Brewer (flatmush) | 09:50 |
| flatmush | * Done | 09:50 |
| flatmush | - Test kernel rebuild time for demo -- 20 minutes | 09:50 |
| flatmush | - Discussions about easiest way to get CI running | 09:50 |
| flatmush | * Doing | 09:50 |
| flatmush | - Rebase minimal distro on definitions so we can use its CI runners | 09:50 |
| flatmush | - Prepare for demo on Friday | 09:50 |
| flatmush | ## Francisco Redondo Marchena (noisecell) | 09:50 |
| noisecell | * Done | 09:50 |
| noisecell | - Update some packages | 09:50 |
| noisecell | * Doing | 09:50 |
| noisecell | - Set the dependencies/build to avoid overlaps when building the image. | 09:50 |
| noisecell | - This seems not to be a trivial task. | 09:50 |
| noisecell | - Create white-list for stage1 and stage2 | 09:50 |
| noisecell | ## Will Barnard (willbarnard) | 09:50 |
| willbarnard | * Doing | 09:51 |
| willbarnard | - Analyzing certification requirements for ISO 26262/IEC 61508 | 09:51 |
| flatmush | ## Discussion | 09:51 |
| paulwaters_ | _o_ | 09:51 |
| noisecell | _o_ | 09:51 |
| flatmush | 10 9 8 7 6 5 4 3 2 1 | 09:51 |
| willbarnard | _o_ | 09:51 |
| flatmush | STANDUP ENDS! | 09:51 |
| noisecell | ta flatmush | 09:54 |
| persia | paulsherwood: Actual insight. The approach taken by morph, ybd, buildstream is that when an input changes, the output is expected to change, so all the things that depend on that output should be rebuilt. This carries the implication that we know how something behaves if we know which version of things was used to build it. | 10:07 |
| persia | There exists a (large) set of changes that do not require rebuilds of depending objects, for which this ends up being wasted effort. Also, there exist a large number of updates that can be made smaller where such rebuilds aren't required. | 10:08 |
| persia | Unfortunately, allowing such things means that one cannot infer a manifest of a system based on the top-level components, recursively determining subcomponents, rather one should compose a manifest of a system based on each of the many components, only ensuring they are compatible. | 10:09 |
| persia | I have yet to think about this enough to have a good understanding of what sort of nomenclature makes sense for relations between components and subcomponents, or how to determine when behaviours are expected to be identical, such that one can safely update a subcomponent without updating things that depend on it. | 10:10 |
| persia | My experience in the distro environment is that one does this mostly ad-hoc, based on testing when things don't work, but that doesn't lend itself to predictive automation. | 10:11 |
| flatmush | I would assume the best way is to have the headers (or interface) for any dependency as a separate part of the artifact where possible, and depend on that, so re-builds are only forced when interfaces change | 10:11 |
| flatmush | of course in most cases, projects don't much care about the idea of an interface further than a vague goal to be backwards compatible | 10:12 |
| flatmush | so rebuilds would still be very frequent | 10:12 |
| persia | flatmush: For the libary case, where it is possible to get sensible symbol descriptions, I think that mostly works. | 10:40 |
| persia | Of course, it is possible to make a change that is both ABI compatible and massively changes behaviour, so one may need some mechanisms to verify that hasn't been done. | 10:40 |
| persia | For the executable case, I have yet to think of a way to capture behaviour that can usefully result in build avoidance. | 10:41 |
| flatmush | if the interface doesn't change and the behaviour does, then I'd say that's a bug, and there's very little you can do about it | 10:42 |
| persia | For example, if component A requires component B to be executed during the build process (for component A), and component B is updated, it is complicated to determine if component A needs to be updated. | 10:42 |
| persia | flatmush: Key is to *detect* it. | 10:42 |
| flatmush | buildstream doesn't currently do anything for this case anyway | 10:42 |
| flatmush | if you update a bst element and the interface is unchanged, but the behaviour is different, the first you'll know of it is when a test on the final image fails, assuming you even test that specific change | 10:43 |
| persia | No. As I said at the start of this, morph, ybd, and buildstream all make an assumption that I now consider false. That assumption ends up requiring more frequent and larger updates to address security issues, etc. On the other hand, it avoids a tangled mess of thought which we're discussing now. | 10:43 |
| flatmush | I don't really consider this a tangled mess of thought tbh | 10:44 |
| persia | If you update a bst element and the interface is unchanged, the dependencies will all be rebuilt anyway (and assigned new cache keys), so there's no possibility of single-element updates. | 10:44 |
| flatmush | the rebuild doesn't matter | 10:44 |
| flatmush | if the interface is unchanged, whatever built before, will build again | 10:44 |
| persia | Why not? | 10:44 |
| persia | bst has no concept of "interface changed" vs. "interface unchanged" | 10:44 |
| flatmush | if an interface doesn't change, and behaviour does, the rebuild does nothing to mitigate that | 10:44 |
| flatmush | indeed | 10:44 |
| flatmush | imagine I change malloc to call abort internally | 10:44 |
| persia | The important part is the assignment of a different cache key. | 10:45 |
| flatmush | in buildstream, everything would rebuild | 10:45 |
| flatmush | but it'd still be broken | 10:45 |
| flatmush | the rebuild doesn't guarantee that packages work together | 10:45 |
| flatmush | only testing can tell us that anyway | 10:45 |
| persia | Technically not very much would rebuild, because the breakage happens at such a low level that many build tools stop working, but I get your point. | 10:45 |
| flatmush | bst does nothing to detect package compatibility currently as far as I'm aware | 10:45 |
| persia | Your awareness matches mine. | 10:46 |
| flatmush | the only way to find these things is via large amounts of testing | 10:46 |
| flatmush | so back to the main point, if we have interface artifacts that things depend on, you reduce some rebuilds, and have the exact same behaviour as we have now | 10:46 |
| persia | The problem with that model is that one then requires that large amounts of testing for every little security update, which leads to the "don't update anything ever" school of thought. | 10:46 |
| noisecell | the problem is no all packages also add a dependency package description. So bst elements become like debian-control files | 10:47 |
| flatmush | sure, but do you know of a better model? | 10:47 |
| persia | If we want to be able to consume updates in a timely manner for systems composed of thousands to tens of thousands of components, then we need something else. | 10:47 |
| flatmush | lots of work tbh | 10:47 |
| flatmush | that's what lots of updates require | 10:47 |
| persia | noisecell: I consider bst element defintions to be a combination of debian/control & debian/rules, but yes. | 10:47 |
| flatmush | automated testing will mitigate some things, but the issues will still require a random engineer googling stuff | 10:47 |
| noisecell | persia, yes it is a merge of both, but we were discussing dependencies in this case, though | 10:48 |
| persia | To my mind, if we can detect when things could potentially work together vs. cannot work together, we are in a position to reduce the volume of testing, I think. | 10:48 |
| persia | noisecell: Yes. | 10:48 |
| flatmush | sounds like magic to me | 10:48 |
| persia | flatmush: Yep, although I prefer to call it "sufficiently advanced technology". Needs more thought. | 10:49 |
| flatmush | will this thought lead to a concrete solution ;) | 10:49 |
| persia | I hope so. I'll share if it does. | 10:50 |
| persia | (for that matter, I'll probably share if I just get to a concrete vocabulary and/or am able to express my new idea properly) | 10:51 |
| *** traveltissues has joined #trustable | 10:56 | |
| *** willbarnard has quit IRC | 11:24 | |
| *** willbarnard has joined #trustable | 11:44 | |
| *** willbarnard has quit IRC | 12:41 | |
| *** willbarnard has joined #trustable | 12:41 | |
| *** willbarnard has quit IRC | 14:05 | |
| *** willbarnard has joined #trustable | 14:07 | |
| *** paulwaters_ has quit IRC | 15:02 | |
| *** willbarnard has quit IRC | 15:56 | |
| *** weyfonk has quit IRC | 17:09 | |
| *** toscalix has quit IRC | 17:15 | |
| *** traveltissues has quit IRC | 21:07 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!