| *** cosm has quit IRC | 00:35 | |
| *** cosm has joined #baserock | 00:48 | |
| *** gtristan has quit IRC | 07:04 | |
| *** franred has joined #baserock | 07:12 | |
| *** franred has quit IRC | 07:16 | |
| *** ctbruce has joined #baserock | 07:28 | |
| *** franred has joined #baserock | 07:28 | |
| *** gtristan has joined #baserock | 07:33 | |
| *** rdale has joined #baserock | 07:42 | |
| *** fay_ has joined #baserock | 07:59 | |
| *** toscalix has joined #baserock | 08:01 | |
| *** jonathanmaw has joined #baserock | 08:16 | |
| *** _longines has quit IRC | 08:32 | |
| *** edcragg has joined #baserock | 08:41 | |
| *** franred_ has joined #baserock | 08:54 | |
| *** franred has quit IRC | 08:58 | |
| *** ssam2 has joined #baserock | 09:13 | |
| *** ChanServ sets mode: +v ssam2 | 09:13 | |
| *** Zara has left #baserock | 09:16 | |
| paulsherwood | folks, in discussions elsewhere i undertook to document some requirements for the kind of deterministic build tooling we are interested in... | 09:42 |
|---|---|---|
| paulsherwood | https://goo.gl/oiDPXs | 09:42 |
| paulsherwood | ssam2: you mentioned that there's something already on the wiki? | 09:42 |
| paulsherwood | i don't think i've ever done a table in a wiki before... | 09:43 |
| ssam2 | yeah | 09:43 |
| ssam2 | wiki.baserock.org/definitions/comparison-with-other-formats/ | 09:44 |
| ssam2 | http://wiki.baserock.org/doing-stuff-with-baserock/ also has some tables (but because there are links inside the cells, the ikiwiki markdown becomes *super* ugly) | 09:45 |
| ssam2 | i'm dubious about 'new user can get started in minutes, not hours' -- i think "days, not months" is more realistic | 09:47 |
| ssam2 | if there's a build tool where i could be productive within hours of finding it, we should definitely switch to that right away ;-) | 09:48 |
| ssam2 | in fact, rather than commenting on the document, maybe i should just share what i came up with in a similar vein ... | 09:49 |
| ssam2 | http://paste.baserock.org/onepefuyil | 09:50 |
| persia | ssam2: how do you imagine avoiding combinatorial explosion? I imagined just automating validation so that humans did not care much, but see no way to avoid the underlying issue. | 10:24 |
| ssam2 | actually... a perfectly good solution is managing it rather than avoiding it | 10:24 |
| ssam2 | e.g. the approach Fedora Atomic currently takes where you build a filesystem tree from RPMs, then commit the exact tree to OSTree | 10:24 |
| ssam2 | when you pull an upgrade, it's exactly the same set of bits for everyone because you pull a whole new tree | 10:25 |
| ssam2 | so it avoids the combinatorial explosion you get from letting the package-manager do an upgrade one step at a time | 10:25 |
| ssam2 | but actually that's not what I was talking about there... | 10:25 |
| ssam2 | I was thinking more about the problem with BitBake where you can set variables anywhere and expand them anywhere else and override them in a third place | 10:25 |
| persia | Sure, removing the uncertainty of ordered incremental installs is critical. | 10:26 |
| persia | Oh, that is also bad. | 10:26 |
| ssam2 | I should reword that requirement, given that even I managed to misinterpret it :-) | 10:26 |
| persia | I was thinking of the problem of thousands of commits on thousands of projects of which one picks hundreds. | 10:27 |
| ssam2 | right. i don't think there's any way around that | 10:27 |
| persia | Getting the right set of projects is the first hard thing (as "dependencies" vary in application-specific ways), and selecting commits becomes the next hard problem. | 10:28 |
| persia | Oh well. I was hoping you had a massive insight, hidden inside a single clause :) | 10:29 |
| ssam2 | "copy what other people do" is the best I can offer :-) | 10:29 |
| persia | I think I prefer the army-of-tobots-trying-everything-in-parallel approach. Most of the humans being copied are also just guessing wildly. | 10:31 |
| ssam2 | if you can find a robot (or tobot) that understands what I want the software to do, great | 10:33 |
| ssam2 | beyond "execute without crashing", I think it's a lot of work to educate them on how to evaluate stuff | 10:33 |
| persia | Some things robots can evaluate easily: does this combination compile? Does it link? | 10:51 |
| ssam2 | sure, that's the easy part | 10:52 |
| persia | With a bit more effort: are symbols resolved in a syntactically compatible way? Are other classes of dependency resolved in a syntactically valid way? | 10:52 |
| persia | Yes, but the amount of human effort currently applied to deal with these is large. | 10:53 |
| ssam2 | i updated my list a bit ... http://paste.baserock.org/exalihedop | 10:55 |
| persia | If we further assert that any project should have a branch for users (maybe master, maybe current-release, whatever), then the robots can try all the commits in the branch to detect mist issues, and present the human with the solder job of behaviour specification and implementation selection. | 10:57 |
| paulsherwood | ssam2: i like your list | 10:57 |
| persia | I also. I think I have more opinions, but want to think a bit. | 10:59 |
| ssam2 | feel free to evolve it. although I doubt we'll ever agree on one list of requirements to rule them all :-) | 11:02 |
| paulsherwood | ssam2: well, as a first pass, we'd have them in a git repo and accept pull requests | 11:03 |
| rdale | point 16. should be '..has the latest releases..' not have | 11:04 |
| persia | I'd rather review merge candidates: it is difficult for multiple parties to collaborate on a pull request. | 11:07 |
| SotK | persia: +1 | 11:08 |
| ssam2 | rdale: ta | 11:08 |
| ssam2 | make sure to update http://wiki.baserock.org/developer-experience/ http://wiki.baserock.org/overview/ and http://wiki.baserock.org/wishlist/ to point at said Git repo instead of listing old requirements :-) | 11:09 |
| paulsherwood | gtristan, ssam2 - any thoughts on christoph's 'image won't boot' using the ybd+aboriginal approach? | 11:28 |
| * paulsherwood is excited someone else is trying it | 11:28 | |
| * gtristan reads emails... | 11:32 | |
| gtristan | ssam2, when you tried it... did you build with CROSS_COMPILER_HOST=x86_64 ? | 11:37 |
| * gtristan is curious because he mostly tested with the i686 host... | 11:37 | |
| ssam2 | i think i did, yeah ... | 11:41 |
| ssam2 | presumably that message means the kernel is totally broken | 11:42 |
| gtristan | it looks like kernel wont boot in qemu indeed | 11:43 |
| * gtristan suspects that if this is a message from ./dev-environment.sh or the aboriginal-controller scripts, that it may be a too old qemu ? | 11:47 | |
| paulsherwood | gtristan: maybe reply asking christoph to discuss on irc? | 11:51 |
| gtristan | paulsherwood, already sent | 11:56 |
| paulsherwood | ack | 11:58 |
| *** gtristan has quit IRC | 12:32 | |
| *** gtristan has joined #baserock | 12:43 | |
| *** cosm has quit IRC | 13:02 | |
| *** cosm has joined #baserock | 13:14 | |
| *** CTtpollard has quit IRC | 14:00 | |
| *** CTtpollard has joined #baserock | 14:08 | |
| *** anahuelamo_ has joined #baserock | 14:55 | |
| *** anahuelamo has quit IRC | 14:55 | |
| *** rdale has quit IRC | 15:08 | |
| *** rdale has joined #baserock | 15:15 | |
| *** franred_ has quit IRC | 15:38 | |
| *** jonathanmaw has quit IRC | 16:07 | |
| *** ctbruce has quit IRC | 16:24 | |
| *** janderJLR has joined #baserock | 16:41 | |
| *** fay_ has quit IRC | 16:48 | |
| *** toscalix has quit IRC | 16:57 | |
| *** edcragg has quit IRC | 17:07 | |
| *** rdale has quit IRC | 17:16 | |
| *** ssam2 has quit IRC | 18:05 | |
| *** janderJLR has quit IRC | 23:41 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!