| * paulsherwood likes ssam2's changes, but wonders how they are done, where the code is. no sign of changes to definitions.git or infrastructure.git | 06:04 | |
| *** gtristan has quit IRC | 07:34 | |
| *** gtristan has joined #baserock | 07:54 | |
| *** fay_ has joined #baserock | 08:00 | |
| franred | paulsherwood, https://gerrit.baserock.org/#/c/1339/ , I think | 08:31 |
|---|---|---|
| perryl | the code lives in trove-setup | 08:32 |
| perryl | iirc | 08:32 |
| *** gtristan has quit IRC | 08:36 | |
| *** toscalix has joined #baserock | 08:37 | |
| franred | perryl, yes, it does so the link I posted are the changes made by ssam2. | 08:37 |
| *** CTtpollard has quit IRC | 08:54 | |
| *** CTtpollard has joined #baserock | 08:59 | |
| *** bashrc_ has joined #baserock | 09:05 | |
| *** toscalix has quit IRC | 09:07 | |
| *** toscalix has joined #baserock | 09:07 | |
| *** franred has quit IRC | 09:09 | |
| *** gtristan has joined #baserock | 09:31 | |
| *** ssam2 has joined #baserock | 09:33 | |
| *** ChanServ sets mode: +v ssam2 | 09:33 | |
| *** franred has joined #baserock | 09:36 | |
| *** jonathanmaw has joined #baserock | 09:40 | |
| *** edcragg has joined #baserock | 09:50 | |
| *** ctbruce has joined #baserock | 09:54 | |
| *** toscalix has quit IRC | 09:58 | |
| *** toscalix has joined #baserock | 09:58 | |
| *** CTtpollard has quit IRC | 09:59 | |
| *** CTtpollard has joined #baserock | 10:00 | |
| *** fay_ is now known as faybrocklebank | 10:08 | |
| *** mwilliams_ct has joined #baserock | 10:22 | |
| *** Lachlan1975 has joined #baserock | 10:25 | |
| *** tiagogomes_ has quit IRC | 11:06 | |
| *** edcragg has quit IRC | 11:08 | |
| *** edcragg has joined #baserock | 11:09 | |
| *** tiagogomes_ has joined #baserock | 11:19 | |
| *** edcragg has quit IRC | 11:35 | |
| *** edcragg has joined #baserock | 11:37 | |
| *** toscalix has quit IRC | 12:02 | |
| *** bashrc_ has quit IRC | 12:02 | |
| *** nowster has quit IRC | 12:02 | |
| *** jonathanmaw has quit IRC | 12:02 | |
| *** Lachlan1975 has quit IRC | 12:02 | |
| *** CTtpollard has quit IRC | 12:02 | |
| *** ctbruce has quit IRC | 12:02 | |
| *** franred has quit IRC | 12:02 | |
| *** edcragg has quit IRC | 12:02 | |
| *** tiagogomes_ has quit IRC | 12:02 | |
| *** ctbruce has joined #baserock | 12:02 | |
| *** CTtpollard has joined #baserock | 12:02 | |
| *** Lachlan1975 has joined #baserock | 12:02 | |
| *** toscalix has joined #baserock | 12:02 | |
| *** tiagogomes__ has joined #baserock | 12:02 | |
| *** nowster has joined #baserock | 12:02 | |
| *** jonathanmaw has joined #baserock | 12:02 | |
| *** franred has joined #baserock | 12:02 | |
| *** bashrc_ has joined #baserock | 12:02 | |
| *** edcragg has joined #baserock | 12:02 | |
| *** gtristan has quit IRC | 12:12 | |
| *** ssam2 has quit IRC | 12:12 | |
| *** toscalix has quit IRC | 13:32 | |
| *** bashrc_ has quit IRC | 13:32 | |
| *** tiagogomes__ has quit IRC | 13:32 | |
| *** jonathanmaw has quit IRC | 13:32 | |
| *** franred has quit IRC | 13:32 | |
| *** edcragg has quit IRC | 13:32 | |
| *** CTtpollard has quit IRC | 13:32 | |
| *** Lachlan1975 has quit IRC | 13:32 | |
| *** ctbruce has quit IRC | 13:32 | |
| *** nowster has quit IRC | 13:32 | |
| *** bashrc_ has joined #baserock | 13:32 | |
| *** jonathanmaw has joined #baserock | 13:32 | |
| *** edcragg has joined #baserock | 13:32 | |
| *** ctbruce has joined #baserock | 13:32 | |
| *** CTtpollard has joined #baserock | 13:32 | |
| *** nowster has joined #baserock | 13:32 | |
| *** toscalix has joined #baserock | 13:32 | |
| *** Lachlan1975 has joined #baserock | 13:32 | |
| *** 16WAAO5A6 has joined #baserock | 13:32 | |
| *** franred has joined #baserock | 13:33 | |
| *** toscalix has quit IRC | 14:00 | |
| paulsherwood | franred: aha, thanks! | 14:01 |
| franred | ls | 14:05 |
| franred | oops | 14:05 |
| paulsherwood | :) | 14:07 |
| *** toscalix has joined #baserock | 14:07 | |
| *** gtristan has joined #baserock | 14:14 | |
| *** ssam2 has joined #baserock | 14:14 | |
| *** ChanServ sets mode: +v ssam2 | 14:14 | |
| *** CTtpollard has quit IRC | 14:19 | |
| *** CTtpollard has joined #baserock | 14:22 | |
| *** paulw has joined #baserock | 14:34 | |
| paulsherwood | in another place i've been discussing names.... | 15:15 |
| paulsherwood | please don't all sigh or cry bikeshed :) | 15:15 |
| paulsherwood | it's been suggested that 'layer' is a much more useful word than stratum | 15:15 |
| *** paulw has quit IRC | 15:15 | |
| paulsherwood | we shied away from this to avoid confusion with bitbake layers... | 15:15 |
| paulsherwood | but maybe that's wrong, given there's a clear implication of one thing on top of another | 15:16 |
| rdale_ct | how do they differ from baserock strata then? | 15:16 |
| paulsherwood | any strong opinions? | 15:16 |
| paulsherwood | well, i'm not an expert but bitbake layers are not described in yaml iiuc, and can have more logic | 15:16 |
| paulsherwood | also 'deployment' has been suggested instead of 'cluster' | 15:17 |
| paulsherwood | (nb this would initially only be changes in ybd internal representation, to see if it improves legibility) | 15:17 |
| ssam2 | deployment is clearly better than cluster to me | 15:21 |
| paulsherwood | i agree :) | 15:21 |
| ssam2 | as for 'layer'... i think it's just as inaccurate as 'stratum' | 15:21 |
| ssam2 | 'group' would be accurate... but too generic | 15:21 |
| franred | a stratum is technically a layer (so it won't change anything) - no strong opinion on the change. I assume that cluster was referencing that you can deploy multiple systems at the same time, so once again, Im not against it. | 15:22 |
| paulsherwood | i wanted 'group' for stratum too | 15:27 |
| paulsherwood | level, or tier, maybe :) | 15:27 |
| rdale_ct | a 'level of components' doesn't make sense, a 'tier of components' is better, but i still prefer 'layer' | 15:28 |
| paulsherwood | i still prefer 'group' but fine :) | 15:29 |
| richard_maw | 'layer' works better to describe the mechanism, since you can only compose a system by layering layers on top of each other | 15:31 |
| richard_maw | if you start allowing dependencies directly on chunks, then 'group' becomes more appropriate, since then it's just a convenience for grouping chunks together | 15:32 |
| paulsherwood | i was assuming we would move to dependencies on chunks at some point | 15:32 |
| paulsherwood | (while still supporting depedency on strata/group/whatever) | 15:33 |
| richard_maw | then I'd go for group | 15:33 |
| paulsherwood | rdale_ct: i think we have +3 for group here :) | 15:34 |
| pedroalvarez | are we moving to dependencies on chunks then ?? :D | 15:34 |
| paulsherwood | pedroalvarez: afaik ybd would already support it (or that was my intention) but i've not tested it since early forays into the data structure while coding the definitions parsing in 2014 | 15:36 |
| rdale_ct | 'group' has a linux meaning and using 'layer' avoids confusion with user/groups | 15:37 |
| paulsherwood | ssam2, richard_maw ^^ are you still preferring group ? | 15:38 |
| paulsherwood | i know this is bikeshedding, but our names have been a problem for a long time, would like this to be a clear step in the right direction if possible | 15:39 |
| richard_maw | yes, group is generic enough that it's obvious that it requires extra context, in filesystems this is user groups, in our definitions they would be chunk/package/whatever groups | 15:39 |
| ratmice | the other day was reading: http://web.mit.edu/Saltzer/www/publications/nbo/nbo.pdf | 15:40 |
| ratmice | a bit surprised by how many of the naming related terms in that paper are still in use today | 15:40 |
| * richard_maw throws "atom" into the mix for replacing chunk names | 15:41 | |
| rjek | "package" | 15:41 |
| paulsherwood | ratmice: that looks like a good read for the train :) | 15:42 |
| paulsherwood | package is already loaded, even moreso than component? | 15:43 |
| * rjek thinks the meaning is clearer to newbies | 15:44 | |
| paulsherwood | you're probably right | 15:44 |
| richard_maw | package does conflate input source with output artifact, hence the clumsy term "source package" | 15:45 |
| richard_maw | won't be a problem for us, since source packages aren't artifacts | 15:45 |
| rdale_ct | chunks can be split, and calling them 'atoms' would imply that they are, er 'atomic' would 'artifact splitting' doesn't make much sense with them | 15:45 |
| richard_maw | but could be a conceptual model issue | 15:45 |
| paulsherwood | so far i'm favouring 'deployment', 'system', 'group' and 'component'... last call... any strong objections? | 15:47 |
| * richard_maw wonders whether systems need to exist | 15:48 | |
| richard_maw | long term anyway | 15:48 |
| richard_maw | short term I don't think we can come up with anything better | 15:48 |
| paulsherwood | if they don't, then it has to be possible to apply 'system integration commands' to groups? | 15:49 |
| CTtpollard | is group a package group? | 15:49 |
| 16WAAO5A6 | s/group/collection? | 15:49 |
| ssam2 | systems should just be special kinds of groups | 15:49 |
| paulsherwood | lol. group is about to be ybd's internal representation of the current 'stratum' concept. | 15:49 |
| paulsherwood | ssam2: +1 | 15:49 |
| paulsherwood | 16WAAO5A6: more letters, and less popular in our straw poll :) | 15:50 |
| * richard_maw thinks systems should not be, and that it's just convention to have a top-level group defined that isn't depended on by anything | 15:50 | |
| ratmice | rdale_ct: chunks can be split? does not artifact splitting split 'artifacts', into different chunks? | 15:50 |
| richard_maw | a group is imbued with system-ness by virtue of the fact that you are selecting it as the build target on the command-line, either directly, or via a deployment | 15:51 |
| paulsherwood | richard_maw: oh, so just run all implied s-i-commands in those cases? | 15:52 |
| richard_maw | yep | 15:52 |
| paulsherwood | works for me :) | 15:52 |
| richard_maw | whether a group is a system is just a point of view | 15:52 |
| richard_maw | kind-of philosophical, but cuts out the need for an explicit concept | 15:53 |
| rdale_ct | you can say 'top layer', but you can't say 'top group' | 15:53 |
| pedroalvarez | hahah | 15:53 |
| paulsherwood | supergroup :) | 15:53 |
| richard_maw | rdale_ct: the top-layer doesn't imply the system as a whole | 15:53 |
| richard_maw | paulsherwood: a supergroup is just any group that contains/requires other groups | 15:53 |
| richard_maw | hence supergroups are just groups | 15:54 |
| richard_maw | you could have a convention to call the 'top group' the system if you wanted | 15:54 |
| ratmice | or the root.. | 15:54 |
| SotK | "a group which is not a subgroup" | 15:54 |
| richard_maw | another issue with calling them layers, is that a layer is divisible from the things it depends on | 15:55 |
| richard_maw | the implication you could peel a layer off something and put it on top of something else entirely | 15:55 |
| paulsherwood | richard_maw: i was joking, while thinking of Cream and other 70s supergroups :) | 15:55 |
| richard_maw | mathematically the name isn't without merit | 15:56 |
| paulsherwood | ok, i think for ybd in this step it should be 'deployment', 'system', 'group' and 'component', with the stretch goal of trying to remove the 'system' as discussed above | 15:57 |
| * richard_maw is still concerned about the terminology of how components interact with split artifacts, since that was terminology we hadn't got right before either, and it's more difficult than just replacing the name of a concept we were already sure of | 15:58 | |
| paulsherwood | i take your point, richard_maw - that needs more thought | 16:00 |
| ssam2 | I had a go at making a generic data model for build+integration instructions by the way | 16:00 |
| ssam2 | here is a clumsy attempt at visualising its current state: https://github.com/ssssam/software-integration-ontology/blob/master/docs/ontograf-2016-01-27.png | 16:00 |
| paulsherwood | ybd has one artifact per component. istm that splitting is an operation that gets performed on artifacts, not components? | 16:00 |
| ssam2 | (the "Project" entity is tying in with the existing DOAP data model and the "Package" entity is tying in with SPDX, you can ignore them) | 16:01 |
| ssam2 | thinking about it, having components and artifacts is super confusing | 16:01 |
| ssam2 | both really generic terms that could mean exactly the same thing | 16:01 |
| paulsherwood | true | 16:01 |
| ssam2 | source-component would be clearest (but probably too long) | 16:02 |
| paulsherwood | erk :) | 16:02 |
| ratmice | i'm kind of partial to calling things more by what they contain e.g. 'source heirarchy' vs hrm, ssam2 got there first :) | 16:02 |
| ssam2 | Morph has always called these things Source internally | 16:02 |
| richard_maw | paulsherwood: I'm thinking split artifacts should be another definition type which go in a different file, refer to a chunk/source/component and select which files that should be part of it | 16:02 |
| rdale_ct | i would call chunks 'components' which can be split into 'packages' | 16:03 |
| pedroalvarez | this bike is too big and has too many wheels .. :) | 16:04 |
| paulsherwood | pedroalvarez: agreed :) | 16:04 |
| rdale_ct | well, terrible names are a really important baserock problem | 16:04 |
| richard_maw | and you can depend on a group (includes everything the group "contains"), a "chunk" which contains all files produced by the build, or a "split artifact" which contains a subset of the files produced by the build | 16:04 |
| ssam2 | note that in the data model I tried to produce, I also tried to describe what each entity *is*, which was a useful exercise | 16:05 |
| pedroalvarez | subcomponents | 16:05 |
| richard_maw | rdale_ct: I'm liking the idea of packages for split artifacts, not sure component is right for that any more, since component could be a generic term that encompasses packages | 16:05 |
| ssam2 | e.g. 'artifact': "A file or set of files that is interesting for some reason." | 16:05 |
| richard_maw | ssam2: what do you call the combination of build instructions, sources and dependencies that after building, produces something that can be used? | 16:08 |
| rdale_ct | a 'build unit'? | 16:08 |
| ratmice | build tree? | 16:09 |
| ssam2 | richard_maw: definitions? | 16:10 |
| richard_maw | I like package because it implies the selection of which files should be included, but I don't think artifact fits in the conceptual model, as packages are "artifacts" by a definition | 16:11 |
| ssam2 | to use established baserock terms | 16:11 |
| ssam2 | if I was talking in a context where 'definitions' wasn't established, I think I'd try to spell out explicitly what I meant instead of trying to find a word | 16:11 |
| richard_maw | ssam2: I view definitions as the textual representation from the yaml document tree, rather than the internal concept they are parsed into | 16:12 |
| richard_maw | so you can have group definitions, being the text you write to define a group | 16:13 |
| ssam2 | ok | 16:13 |
| richard_maw | but what is the equivalent of a chunk definition | 16:13 |
| ssam2 | I would call the data structure that a build tool operates on a 'build graph' | 16:14 |
| ssam2 | that's a pretty common term I think | 16:14 |
| richard_maw | we kind of need a word that is indivisible | 16:14 |
| richard_maw | I don't think component necessarily works, since it's common to see subcomponents | 16:14 |
| ssam2 | chunk? :-) | 16:14 |
| richard_maw | you could use component to describe both groups or chunks | 16:14 |
| richard_maw | ssam2: aye, for purity I think it fits, but it's not an intuitive name | 16:15 |
| * paulsherwood hopes for terms that newbies can grok, without need for a comp sci background | 16:16 | |
| richard_maw | hm, rdale's "build unit", while possibly verbose, is both correct and more self-describing than [build] chunk | 16:17 |
| richard_maw | there's a bit of ambiguity of what a "build" is | 16:17 |
| richard_maw | since build describes both the top-level system build, and the lower-level component build | 16:18 |
| paulsherwood | richard_maw: i think of top-level as assembly | 16:19 |
| paulsherwood | ssam2: how easy is it to generate that png? i wonder i'm tempted to suggest that we try for an 'official' resolution of this as one or more pull-requests to your repo | 16:20 |
| ssam2 | it's a total pain to generate it | 16:20 |
| ssam2 | involves taking a screenshot of a big Java app called Protégé, with lots of babysitting to get a good layout first | 16:21 |
| paulsherwood | ouch | 16:21 |
| ssam2 | there may be a better way | 16:21 |
| richard_maw | ssam2: ugh, can we just use dot? | 16:21 |
| ssam2 | Tracker has some stuff in to convert OWL to dot, I think | 16:21 |
| ssam2 | it would definitely be good to have the data model formally specified somewhere | 16:22 |
| ssam2 | probably not on my github though :-) | 16:22 |
| persia | A note on the semantics of "package": many folk seem to think packages should support install-time integration scripts. If this term is used, and one wants to be able to have reproducible or comprehensible images, be very careful. | 16:22 |
| richard_maw | paulsherwood: if we can emphasise assembly as the operation to convert a system/group selected to be the system into a system artifact, then yes, I think we could use "build" for the low-level bit | 16:22 |
| richard_maw | persia: hm, that would be staging area construction time integration scripts, which we've managed to avoid so far, by the few things that needed it putting extra stuff in pre-configure-commands | 16:23 |
| persia | Yes. Also, many people believe you can "install a package" post-deploy. I'm not saying don't use it, just be careful that it isn't misunderstood due to heavy overloading. | 16:24 |
| paulsherwood | richard_maw: currently ybd has assembly as the process of traversing the definitions to create a target, building necessary components along the way, and combining them as the required artifact. | 16:26 |
| paulsherwood | i guess you mean assmebly should only be the combine step? | 16:26 |
| richard_maw | exactly | 16:26 |
| paulsherwood | ok | 16:26 |
| richard_maw | when building lego, you do the assembly part, someone else has built all the blocks and provided instructions on how to put them together | 16:27 |
| paulsherwood | good point. so traverse, build, assemble? is there a better verb than traverse? | 16:27 |
| richard_maw | hm, there's parse, but that's more about turning the tree of yaml documents into something you understand, whereas building the graph is a step after that | 16:28 |
| richard_maw | analyse possibly | 16:28 |
| richard_maw | or use graph as a verb maybe | 16:28 |
| * paulsherwood is finally admitting, to the assembled internet multitudes, that the ybd code is hard to understand | 16:28 | |
| paulsherwood | there, i said it. don't all chortle too loudly :) | 16:28 |
| richard_maw | this is in particular why I found the variables labelled "this" so difficult | 16:29 |
| pedroalvarez | :) | 16:29 |
| paulsherwood | ack. | 16:29 |
| richard_maw | we have all these concepts floating around, and if we don't use the proper label, we need an incredible amount of context to know what's happening | 16:29 |
| ratmice | hrm wrt 'build unit' I was thinking 'origin' might work | 16:30 |
| richard_maw | ratmice: hm, sounds more related to where the source code came from to me, but that may just be because the default git remote is labelled origin | 16:30 |
| *** 16WAAO5A6 has quit IRC | 16:31 | |
| paulsherwood | i must admit i'm being tempted by 'unit' over component (it's shorter, for a start) | 16:32 |
| rdale_ct | i'm not sure 'unit' works by itself 'build unit' is about the granularity of the build at the bottom level | 16:34 |
| * richard_maw is favouring 'build' | 16:36 | |
| richard_maw | given the top-level operation is assembly, if we were using unit or component, it would be build unit or build component | 16:37 |
| paulsherwood | whatever chunk moves to, it has more significance than just being a 'build unit' - from an outside perspective, it's the name of a specific project/program | 16:37 |
| paulsherwood | i would hate to have to rever to every project as a 'build unit' as much as i've hated using 'stratum/strata' | 16:38 |
| rdale_ct | yes, you might be right | 16:38 |
| richard_maw | paulsherwood: I'm not sure project is right either, since that's more about how upstream organises themselves, rather than what we build | 16:39 |
| richard_maw | a project may produce many things we build | 16:39 |
| richard_maw | and a build may produce many programs or libraries | 16:39 |
| paulsherwood | true - i'm not suggesting project, but that's the common parlance for some aspects of this concept outside baserock | 16:39 |
| richard_maw | aye, and most projects, mostly small ones, are easily mappable to 1 source code repository and 1 build to produce the 1 program | 16:40 |
| richard_maw | but using it as terminology gets very clunky when this isn't the case | 16:41 |
| rdale_ct | debian builds 'binary packages' from a 'source package' | 16:42 |
| richard_maw | so we're back to a "build" for the translation from source code into artifacts/packages | 16:43 |
| paulsherwood | ack | 16:44 |
| *** tiagogomes_ has joined #baserock | 16:45 | |
| richard_maw | it's not a clean comparison, since "source packages" are pre-processed to bundle up the build instructions with the source code, whereas we don't have this bundling step | 16:45 |
| rdale_ct | we have a reference to a git repo, instead of the actual source - but the thing we now call a 'chunk' as build instructions plus source just like a source package to me | 16:48 |
| *** tiagogomes_ has quit IRC | 16:48 | |
| ssam2 | well, 'source package' and 'binary package' don't seem so bad. and should meet the criterion of being already established | 16:48 |
| *** tiagogomes_ has joined #baserock | 16:48 | |
| richard_maw | rdale_ct: aye, except that a "source package" is an artifact in debian's build process, while it's an internal detail in ours | 16:48 |
| ssam2 | why not 'source artifact' and 'binary artifact' or 'source component' and 'binary component' ? | 16:49 |
| rdale_ct | i like the component pair | 16:49 |
| paulsherwood | assuming we stay with 'artifact' for the result of 'build' on a 'component/chunk/build-unit' - do we have a different name for the result of 'assemble' on a 'group' or is it just another kind of artifact? | 16:49 |
| richard_maw | for which bits? source artifact implies that at some point we spit out a tarball of source code | 16:49 |
| richard_maw | paulsherwood: I'm thinking of artifact closer to its dictionary definition by this point, in that it's anything produced, hence cacheable | 16:50 |
| paulsherwood | output of build, tarred. | 16:50 |
| paulsherwood | but i'm ok with output of build or assemble, tarred. | 16:51 |
| richard_maw | I wouldn't bother specifying the format necessarily | 16:51 |
| richard_maw | since it shouldn't matter whether it's a disk image, loose files, or something else entirely | 16:52 |
| paulsherwood | fair enough, but we continue with artifact for all kinds of outputs (chunk, strata, system) | 16:52 |
| richard_maw | ack, whether stratum artifacts need to exist is another matter | 16:53 |
| paulsherwood | agreed | 16:53 |
| rdale_ct | where have we ended up with 'source xxxx' and 'binary xxxx'? | 16:57 |
| rdale_ct | for me xxxx: component > package > artifact | 16:59 |
| paulsherwood | i'm currently assuming 'artifact' is cached. unclear what splitting generates, or where 'package' fits | 17:04 |
| rdale_ct | a 'source component' builds a 'binary component' which can be split into 'binary sub components' | 17:06 |
| richard_maw | paulsherwood: I'm thinking a "package" is the result of a split, but that you can depend on a build directly, which has a default package containing everything, or the package | 17:06 |
| paulsherwood | why wouldn't 'split' just be something done as part of 'assemble'? | 17:07 |
| richard_maw | in debian parlance, split artifacts are "packages" or "binary packages", while "source packages" are packaged up "build" instructions with the sources | 17:07 |
| paulsherwood | rdale_ct: 'source component' 'binary component' 'binary sub components' are too complicated, imo | 17:08 |
| richard_maw | paulsherwood: because assemble is the top-level bit | 17:08 |
| paulsherwood | richard_maw: ack. but what's the use-case for splitting a component on its own? | 17:09 |
| *** faybrocklebank has quit IRC | 17:09 | |
| rdale_ct | a 'source component' builds a 'binary artifact' which can be split into 'packages' | 17:10 |
| richard_maw | paulsherwood: you mean that you don't have an explicit step for producing a "package", rather that you filter the "build"'s output when using the "package"? | 17:10 |
| * richard_maw had considered that to be a possible optimisation | 17:10 | |
| paulsherwood | richard_maw: yes, i think so | 17:10 |
| richard_maw | yeah, no reason you can't do that | 17:11 |
| richard_maw | I take it your model has assembly as both the construction of the top level system artifact, and the construction of the staging areas that builds are run in too? | 17:11 |
| paulsherwood | currently, yes. but i'm happy with the idea of traverse, build, assemble as above - in which case staging probably gets created in traverse | 17:12 |
| paulsherwood | (or maybe not, unclear) | 17:13 |
| richard_maw | can't, you need the result of some builds before you can assemble the staging area AIUI | 17:13 |
| richard_maw | I have no problem with build and assemble being corecursive | 17:13 |
| richard_maw | but we made system assembly different from staging area assembly different for optimisation reasons | 17:14 |
| paulsherwood | yes. traverse could deal with that. and build is actually (check if already built, then check remote cache, then build) | 17:14 |
| *** ctbruce has quit IRC | 17:14 | |
| richard_maw | paulsherwood: I think we might be hitting an impedence mismatch here, since in my conceptual model traverse builds a data structure that gets executed, while I think yours has traverse causing assemblies and builds | 17:15 |
| rdale_ct | i'm not sure that ybd traverses anything because it doesn't create a build graph | 17:15 |
| paulsherwood | in part i like the traverse/build/assemble idea because the assembly code is currently almost as hard as the definitions code to grok. it has to be multi-instance, idempotent, atomic | 17:15 |
| richard_maw | rdale_ct: we've had this discussion before | 17:15 |
| richard_maw | rdale_ct: ybd has an implied one rather than an explicit one | 17:16 |
| paulsherwood | yes :-) | 17:16 |
| rdale_ct | in terms of naming functions within ybd, i can't see the word 'traverse' being useful | 17:16 |
| paulsherwood | in the previous discussion i had to admit i didn't understand what a graph was, because folks seemed to be thinking i was being wilfully obtuse | 17:16 |
| paulsherwood | rdale_ct: ok | 17:16 |
| paulsherwood | any alternative suggestions? | 17:17 |
| rdale_ct | i think 'assemble' and 'build' are fine, they just need to include what they are building or assemblying, which they don't at the moment - eg 'assemble_system' | 17:18 |
| rdale_ct | i don't go a bundle on 'do_' as a prefix either, i would rather just have 'build()' rather than 'do_build()' - it doesn't seem to mean anything to me | 17:19 |
| paulsherwood | trouble with that is that we can apply ybd to any level... and previosly we established that a system is only a subset of 'group' really :) | 17:19 |
| paulsherwood | rdale_ct: agreed - that's a recent hack, to wrap build() | 17:20 |
| richard_maw | there's a separate question of whether we should be able to do that, previously there was contention because we wanted to have higher-level definitions able to pass down parameters like the architecture | 17:21 |
| richard_maw | now, I'm happy to be able to build groups directly | 17:21 |
| rdale_ct | can the system-integration commands be run on a group at any level - or do they only make sense to run them on what we now call 'systems'? | 17:22 |
| paulsherwood | any level, i think | 17:22 |
| richard_maw | shouldn't be a problem, we want groups to include all the commands they need to be able to do that | 17:22 |
| *** ssam2 has quit IRC | 17:23 | |
| *** toscalix has quit IRC | 17:27 | |
| *** jonathanmaw has quit IRC | 17:27 | |
| *** edcragg has quit IRC | 17:27 | |
| *** franred has quit IRC | 17:27 | |
| *** tiagogomes_ has quit IRC | 17:27 | |
| *** bashrc_ has quit IRC | 17:27 | |
| *** CTtpollard has quit IRC | 17:27 | |
| *** nowster has quit IRC | 17:27 | |
| *** Lachlan1975 has quit IRC | 17:27 | |
| *** CTtpollard has joined #baserock | 17:28 | |
| *** tiagogomes__ has joined #baserock | 17:28 | |
| *** Lachlan1975 has joined #baserock | 17:28 | |
| *** nowster has joined #baserock | 17:28 | |
| *** bashrc_ has joined #baserock | 17:28 | |
| *** toscalix has joined #baserock | 17:28 | |
| *** jonathanmaw has joined #baserock | 17:28 | |
| *** edcragg has joined #baserock | 17:28 | |
| *** franred has joined #baserock | 17:28 | |
| *** jonathanmaw has quit IRC | 17:42 | |
| rdale_ct | i'll copy the transcript of this discussion about baserock names and send it to the mailing list | 17:47 |
| richard_maw | cool, if someone has time a chart would be valuable, but I've already been distracted by this topic for too long | 17:51 |
| *** franred has quit IRC | 17:56 | |
| *** bashrc_ has quit IRC | 18:00 | |
| *** gtristan has quit IRC | 18:05 | |
| *** edcragg has quit IRC | 18:12 | |
| *** toscalix has quit IRC | 18:17 | |
| *** Lachlan1975 has quit IRC | 18:47 | |
| *** rdale_ct has quit IRC | 19:33 | |
| *** gtristan has joined #baserock | 23:29 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!
