| *** tristan has joined #buildstream | 04:16 | |
| gitlab-br-bot | buildstream: merge request (tristan/project-refs->master: Optionally load and store source references in project.refs) #314 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/314 | 07:56 |
|---|---|---|
| gitlab-br-bot | buildstream: merge request (tristan/project-refs->master: Optionally load and store source references in project.refs) #314 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/314 | 08:11 |
| gitlab-br-bot | buildstream: merge request (tristan/project-refs->master: Optionally load and store source references in project.refs) #314 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/314 | 08:12 |
| juergbi | sorry, stupid gitlab | 08:12 |
| tristan | :) | 08:13 |
| juergbi | edited unfinished comment | 08:15 |
| tristan | and replied | 08:20 |
| *** Prince781 has quit IRC | 08:20 | |
| tristan | juergbi, I think lets go with the former; merge them both to a `projects` key at toplevel | 08:22 |
| tristan | juergbi, I was thinking, your self-junction use case might want to build the same element twice with different refs | 08:23 |
| tristan | But... | 08:23 |
| tristan | That should anyway be achievable with project options | 08:23 |
| tristan | and project name is a more natural choice I think | 08:24 |
| tristan | juergbi, sound good ? ... maybe I'm missing something ? | 08:24 |
| juergbi | tristan: only just now saw the messages | 08:30 |
| juergbi | yes, i'm not hard set on either option. going with the former is fine with me | 08:30 |
| tristan | right, should have that done in an hour or maybe two I think (test cases and docs need updating) | 08:31 |
| juergbi | ok. i think the rest looks good | 08:35 |
| tristan | oops, just found an internal api docs problem I'll fix too | 08:39 |
| tristan | Source._save_ref() has completely wrong API docs | 08:40 |
| tristan | not completely, just *mostly* wrong :) | 08:41 |
| juergbi | oops, didn't look too closely at that | 08:41 |
| juergbi | focused on the big picture :) | 08:41 |
| tristan | I'm happy with test coverage | 08:48 |
| tristan | The actual code changes are rather small, but the edge cases to cover are many | 08:49 |
| jennis | tristan, !327 and !323 have been reviewed, both regard documentation, would you be able to have a look? | 09:12 |
| tristan | jennis, give me... around 30min... and if you're available let's have a chat about that too | 09:15 |
| jennis | tristan: sure :) | 09:16 |
| *** ernestask has joined #buildstream | 09:24 | |
| gitlab-br-bot | buildstream: merge request (tristan/project-refs->master: Optionally load and store source references in project.refs) #314 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/314 | 09:29 |
| *** jonathanmaw has joined #buildstream | 09:36 | |
| gitlab-br-bot | buildstream: merge request (278-filter-documentation-could-be-better->master: Resolve "Filter documentation could be better") #304 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/304 | 09:48 |
| gitlab-br-bot | buildstream: merge request (278-filter-documentation-could-be-better->master: Resolve "Filter documentation could be better") #304 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/304 | 09:49 |
| tristan | OK - let's pull the trigger on project.refs ! | 09:50 |
| gitlab-br-bot | buildstream: issue #248 ("Do not automatically update git checkout with refs") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/248 | 09:50 |
| gitlab-br-bot | buildstream: merge request (tristan/project-refs->master: Optionally load and store source references in project.refs) #314 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/314 | 09:50 |
| gitlab-br-bot | buildstream: issue #248 ("Do not automatically update git checkout with refs") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/248 | 09:50 |
| *** aday has joined #buildstream | 09:51 | |
| jonathanmaw | Hi tristan, do you have time to look at whether https://gitlab.com/BuildStream/buildstream/merge_requests/304/diffs resolves the issue you had with the filter element's documentation? | 09:56 |
| jonathanmaw | Hi juergbi, do you have time to look at https://gitlab.com/BuildStream/buildstream/merge_requests/317 ? | 09:56 |
| juergbi | planning to review the pending MRs today, yes | 09:57 |
| jonathanmaw | tvm juergbi | 09:57 |
| *** jmac_ has quit IRC | 10:10 | |
| tristan | jonathanmaw, comments up on 304 | 10:14 |
| jonathanmaw | ta tristan | 10:15 |
| *** dominic has joined #buildstream | 10:24 | |
| *** jmac has joined #buildstream | 10:28 | |
| tlater | Hm, I'm looking at a proposal from ssssam[m] and Nexus to make the full "~/.cache/buildstream" directory size quota-able | 10:37 |
| tlater | Which goes into the detail of managing the size of sandbox directories and such | 10:37 |
| Nexus | ah yes, that | 10:38 |
| tlater | This definitely solves a few issues #135 currently doesn't cover, but it does seem like simply expiring cache elements would be enough to at least get gnome adoption down | 10:38 |
| tlater | tristan: What's your opinion on ^ ? | 10:38 |
| * tlater thinks the more full solution would take a fair bit longer. | 10:39 | |
| tristan | tlater, one thing at a time I believe | 11:06 |
| gitlab-br-bot | buildstream: merge request (278-filter-documentation-could-be-better->master: Resolve "Filter documentation could be better") #304 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/304 | 11:07 |
| tristan | tlater, ~/.cache/buildstream/build area should be solved by the "caching failed builds" issue anyway; there's not much point in leaving those on disk when *anyway* we are supposed to have a plan for reconstructing a failed build sandbox regardless if it happened locally or remotely | 11:07 |
| tristan | sources are going to be a different beast, but I think they are of least concern here | 11:08 |
| jonathanmaw | tristan: I've updated my documentation change. I'm not entirely sure I understand the main intent of your comment, as I'm not sure of the fine points between "this element expects $foo" and "it is useful to do $foo for $reason" | 11:08 |
| Nexus | So, i'm looking into implementing the "Build Tree Caching" Do we want to have the enabled/disabled arguement in the user config or the project config? | 11:21 |
| juergbi | i believe it needs to be project config and even affect the cache key | 11:22 |
| juergbi | if we make the build tree part of the artifact | 11:23 |
| juergbi | (unless we make it unconditional after all) | 11:23 |
| tlater | juergbi: It should definitely contain the build tree sha, no? | 11:24 |
| tlater | Otherwise we could create the same artifact twice, but have it contain different build trees | 11:24 |
| juergbi | if it's part of the artifact, the build tree sha will be in the merkle tree anyway | 11:25 |
| juergbi | but the build tree sha shouldn't be in the cache _key_ | 11:25 |
| * paulsherwood thinks that 'tree' is being used too many ways these days | 11:26 | |
| Nexus | *cahing of the build directory created in the sandbox* | 11:27 |
| *** sstriker has joined #buildstream | 11:30 | |
| juergbi | yes. I'm used to git's tree objects and I quite like it but it's somewhat ambiguous | 11:30 |
| paulsherwood | +1 | 11:36 |
| gitlab-br-bot | buildstream: merge request (issue-243_dpkg_import_source_plugin->master: Created DPKG Source plugin for Issue #10) #305 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/305 | 11:43 |
| laurence | not sure how to add related MRs to issues on gitlab, but I think that !315 and !313 should be linted to #215, tlater | 11:43 |
| laurence | sorry if i'm being anal | 11:43 |
| tlater | laurence: No, you're right - I created the MRs from branches automatically created by gitlab, so I figured they'd be linked | 11:44 |
| tlater | Turns out that doesn't quite work as expected | 11:44 |
| tlater | ta for the note! | 11:45 |
| Nexus | juergbi: re: rename the plugin from `dpkg` to `deb` | 11:48 |
| Nexus | i don't see any issue with this, i wanted to see if anyone else had concerns | 11:49 |
| juergbi | jjardon[m] and tlater added a thumbs up on gitlab | 11:51 |
| juergbi | i haven't heard any concerns of a rename | 11:51 |
| Nexus | kk, then i'll go ahead with the rename | 11:51 |
| juergbi | ta | 11:52 |
| gitlab-br-bot | buildstream: issue #95 ("please provide some real examples") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/95 | 12:05 |
| gitlab-br-bot | buildstream: merge request (issue-243_dpkg_import_source_plugin->master: Created DPKG Source plugin for Issue #10) #305 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/305 | 12:06 |
| Nexus | juergbi: Are we assuming that, if no key is set in the project conf for `build tree caching`, it is disabled? | 12:07 |
| juergbi | I don't know. the optionality is to be decided | 12:07 |
| tristan | jennis, I'm very sorry; I will be with you shortly... | 12:07 |
| tristan | jennis, are you around ? or did I fall flat into your lunch hour ? | 12:22 |
| jennis | i'm here! | 12:24 |
| jennis | tristan ^ | 12:24 |
| tristan | Ah | 12:27 |
| *** aday has quit IRC | 12:27 | |
| *** aday has joined #buildstream | 12:28 | |
| tristan | jennis, sigh; ok - I've had a lot of communications today - and the docs story is always a nightmare | 12:28 |
| tristan | we are bottlenecking with "I have so many docs patches to throw at you" but "I have not proposed a real long term plan of how the documentation will be structured !" | 12:29 |
| jennis | no worries tristan, the good news is that is that the branches contain relatively small changes that are going to more of a kick start | 12:29 |
| jennis | branches related to !323 and !327 | 12:29 |
| tristan | jennis, 327 looks non-controversial to me; I like the current theme, but if people want it to look like readthedocs, so be it | 12:30 |
| tristan | I find it petty, but whatever | 12:30 |
| tristan | it changes the theme, but it does not make the sidebar suddenly become useful; that is something we probably want to fix | 12:31 |
| tristan | jennis, the problem with 323 on the other hand is, this is a lot of changes thrown at us in a single patch | 12:31 |
| jennis | There does seem to be a "depth" difference | 12:31 |
| tristan | I dont like reviewing 323 as a single change, that can be a long time to land; at first sight, I dont like that the "What is BuildStream" has become, especially that it lists stuff like "Right now we can do foo, bar and baz !" | 12:32 |
| jennis | quickly back to !327, I thin the theme deals with navigation in a *slightly* better way | 12:34 |
| tristan | So, actually I dont want to land 323 at all before we have a plan | 12:35 |
| gitlab-br-bot | buildstream: merge request (jjardon/theme_change->master: Change theme to sphinx_rtd_theme) #327 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/327 | 12:35 |
| Nexus | tristan: Do you have any thoughts on the "Should caching the build tree be optional?" If so what should the default be? | 12:35 |
| gitlab-br-bot | buildstream: merge request (jjardon/theme_change->master: Change theme to sphinx_rtd_theme) #327 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/327 | 12:35 |
| jennis | e.g. if I click go to "installing buildstream" I've then lost sight of "BuildSteam inside docker" and "using buildstream" in the ToC | 12:35 |
| tristan | jennis, I dont think the docker part was in the ToC, and !327 changes something else *besides* the theme | 12:38 |
| tristan | which is misleading and sneaky of jjardon[m] :) | 12:38 |
| jennis | To add to this, if you go to "Using BuildStream" in the current documentation, you lose the ToC completely https://buildstream.gitlab.io/buildstream/main_using.html#main-using | 12:38 |
| jennis | ahh ok | 12:38 |
| jennis | Well, that said, I feel that not losing sight of the top level is important | 12:38 |
| tristan | actually, I dont see how that can apply on master's doc/source/index.rst | 12:39 |
| tristan | it's changing lines which I dont even see | 12:39 |
| tristan | aha, after rebase it looks like that patch has changed, is gitlab lying to me ?? | 12:41 |
| tristan | Ah ok I see | 12:42 |
| tristan | jennis, so yes; this is a sneaky commit | 12:42 |
| tristan | the commit says it changes the theme, but it changes doc/source/index.rst to use a different way to express the toctree | 12:43 |
| tristan | Which *seems* like it makes the sidebar different | 12:43 |
| jennis | Ok, so we agree this is a commit that should be merged regardless of the theme? | 12:43 |
| tristan | Yes, I'd like to see it first, and honestly I never knew how to do that with the toctree stuff | 12:44 |
| jennis | aha yes it's good | 12:44 |
| tristan | jennis, if you are going to be my docs lieutenant for the time being; I will just trust you on that part | 12:44 |
| tristan | I'd rather postpone the "Lets make it look like readthedocs !!!" thing, to be honest | 12:45 |
| jennis | Right ok, i'll do an MR with this ToCtree change but no themechange | 12:45 |
| jennis | and we'll see how that looks? | 12:45 |
| jennis | Back to !323? | 12:46 |
| tristan | jennis, am I to trust that you are going to be my point of contact for getting docs off the ground ? | 12:46 |
| jennis | yes, I think jjardon[m] has a lot to say too | 12:46 |
| tristan | except he is not working on this; and I need a clear vision to come from one person | 12:47 |
| jennis | Sure, yeah you can trust me" | 12:47 |
| jennis | ! | 12:47 |
| tristan | jennis, Once we iron out the question of structure, then smaller isolated patches which add the docs we want to the places that are correct, will be easy to review | 12:47 |
| jennis | I agree | 12:48 |
| tristan | because, there will be already a "place that is correct" | 12:48 |
| tristan | now it's still mayhem | 12:48 |
| jennis | So we need to establish and agree on some structure from top level ASAP | 12:48 |
| jennis | Which is what !323 is attempting to do | 12:48 |
| tristan | well, !323 is not discussing that or attempting that at all | 12:51 |
| jennis | It alters the top level structure | 12:51 |
| tristan | it's adding new sections, rephrasing "What is BuildStream", and swapping things around; all in the same MR | 12:51 |
| tristan | which is just too much noise right now | 12:51 |
| tristan | lets completely forget that 323 exists | 12:52 |
| tristan | first we talk about structure, including even naming of .rst files | 12:52 |
| jennis | Right ok, we'll go from here then | 12:52 |
| tristan | I had started out by trying to make some consistency with my sub-level main_foo.rst files | 12:52 |
| tristan | the rest of them are still a bit of a mess | 12:52 |
| tristan | it's hard to tell where they are structurally, anyway | 12:53 |
| tristan | jennis, so first we need to think about *what*, what is the big picture of what will be documented | 12:53 |
| tristan | There is a patch from months ago which splits up invoking.rst into one section per bst command | 12:54 |
| tristan | jennis, I want to leverage automation in docs as much as possible, so it would be nice to apply that and have some use for it | 12:54 |
| tristan | I.e. that patch allows for the auto-generated `bst --help` style invocations to be *explained* in sections, and link out to other docs, or be linked *from* other docs | 12:55 |
| tristan | jennis, so that is one thing; we want to document what the commands are for, and be able to link to them from places | 12:55 |
| tristan | this allows people to "dig" through links in a nice and interesting way | 12:56 |
| tristan | jennis, another thing we need is, related to authoring projects; some examples of how to do various things | 12:56 |
| jennis | Ok, first point of action could be to sensibly rename the other files so that they reflect our current structure | 12:57 |
| jennis | ? | 12:57 |
| tristan | jennis, one thing I liked from paulsherwood's attempt last week, was that he started with the "manual" element | 12:57 |
| tristan | jennis, I am trying to give you a bunch of information which you are taking notes about, so that you can form a plan to feed back to me | 12:58 |
| jennis | right | 12:58 |
| tristan | so what I liked about starting examples with the "manual" element, is that it necessarily uses some variables, like say %{install-root}, and it explicitly sets build-commands, configure-commands etc | 12:59 |
| tristan | If we're going to have a "getting started" section, we should start with a "manual" element and move on to another, say "autotools" element | 12:59 |
| tristan | This helps teach the user what variables are doing; with most elements, we only need to set some variables | 13:00 |
| tristan | but the user should understand *how this impacts build-commands* | 13:00 |
| tristan | jennis, so stepping back a second, we've talked about so far, two "things" | 13:00 |
| tristan | one is the invoking.rst autogenerated content; i.e. "What the commands do" | 13:01 |
| tristan | And, now we're talking about a "Getting started" guide | 13:01 |
| jennis | yes, following :) | 13:01 |
| tristan | the "Getting started" guide should not be too elaborate, and it will not be enough | 13:02 |
| tristan | too much getting started sends the signal that, you will never get started | 13:02 |
| tristan | but it *cannot* cover everything, it should be enough to teach the user how to find out what they need to know, beyond that | 13:02 |
| tristan | I recall years ago learning Cocoa/Obj-C/Xcode in a matter of days - with a 12 page "Getting started" guide | 13:03 |
| jennis | It should include Paul's helloworld example also | 13:03 |
| tristan | jennis, it *can*, but I will say off the bat, I very much dislike what I'm seeing in 323 as an adaptation of that | 13:04 |
| tristan | I.e. it takes some shell script and dumps it into some literal thing | 13:04 |
| jennis | Yes, one of my comments was to have more of a walkthrough of this | 13:05 |
| tristan | this stuff needs to be *authored*, lets not start off with... just dumping terminal stuff | 13:05 |
| tristan | We should not be showing "echo blabla > foo.bst" here | 13:05 |
| jennis | however we decided that could be implemented in another branch after this landed | 13:05 |
| tristan | We should be presenting a foo.bst in the docs, using the `.. code:: yaml` blocks | 13:05 |
| jennis | ^ I totally agree | 13:06 |
| tristan | Right, I disagree, I dont want to shove crap in the repo | 13:06 |
| tristan | 323 should not land, really | 13:06 |
| jennis | Right ok | 13:06 |
| tristan | Beyond a getting started guide, we may want some more elaborate examples... "How do I" style | 13:07 |
| tristan | This is interesting for multiple reasons, A.) They are isolated pages which a contributor can send nicely isolated patches for | 13:07 |
| tristan | B.) They can link out to eachother for explanations of things which they may need to know before understanding the particular article | 13:08 |
| tristan | C.) They are an extension of Getting Started, without putting too much weight on Getting Started, which needs to be a bit of a walkthrough | 13:09 |
| tristan | We want the walkthrough to be very brief | 13:09 |
| tristan | Or, *I* think we do | 13:09 |
| tlater | On that note, we created the bst-examples repo with this sort of doc in mind - any way to tie that in? | 13:09 |
| tristan | tlater, probably; I dont like having docs in separate repos; that means we cannot block branches on proper amendments to documentation | 13:10 |
| * tlater has understood that at this point, and agrees we should avoid it | 13:11 | |
| tlater | But I also think it's useful to have these walkthrough projects available in a repo, so the reader can clone and run-along | 13:11 |
| tristan | tlater, *yes* | 13:12 |
| tristan | tlater, buildstream projects are lightweight; we can have 50 of them in the main documentation and it will not make the repo undesirably "big" | 13:12 |
| tristan | Also, we should be running CI on our examples, not for the sake of testing BuildStream, but for the sake of testing our examples do what we expect them to | 13:13 |
| tristan | jennis, so literal includes like we do with several things is a very nice thing for this kind of example | 13:13 |
| tristan | e.g., how we do it for every single element, literal include the accompanying .yaml file | 13:14 |
| gitlab-br-bot | buildstream: merge request (issue-243_dpkg_import_source_plugin->master: Created DPKG Source plugin for Issue #10) #305 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/305 | 13:16 |
| tristan | jennis, so now there are 3 things | 13:17 |
| tristan | 1.) Explanation of commands 2.) Getting started brief walkthrough 3.) Examples | 13:18 |
| gitlab-br-bot | buildstream: merge request (278-filter-documentation-could-be-better->master: Resolve "Filter documentation could be better") #304 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/304 | 13:18 |
| jennis | sorry i Was taking notes | 13:19 |
| tristan | jennis, I feel that 2 and 3 belong close to eachother in the ToC | 13:19 |
| tristan | No worry, I'm glad you are taking notes | 13:19 |
| tristan | channel is also logged, you may want to hold on to: https://irclogs.baserock.org/buildstream/%23buildstream.2018-03-20.log.html | 13:20 |
| tristan | link for today | 13:20 |
| jennis | haha thanks, I have the logs saved locally as well | 13:21 |
| jennis | I've noted all that. I will draft some sort of POA after lunch and send it to you. There are also some changes that I think can/should be made ASAP to our structure | 13:22 |
| tristan | jennis, one point of contention is going to be "What do we include in Getting Started ?" | 13:24 |
| jennis | Namely, one of the changes that !323 tried to implement: Splitting Documentation into "General documentation and "Reference documentation" | 13:24 |
| tristan | This should be derived at least in part by what we want to teach the user as the very basic knowledge | 13:25 |
| jennis | And also introducing the Getting Started Section | 13:25 |
| tristan | Last time I restructured, I made three sections; Using, Authoring Projects, Authoring Plugins | 13:25 |
| tristan | the authoring plugins is named differently, core reference or such | 13:26 |
| jennis | yes | 13:26 |
| tristan | which reminds me, there is a FOURTH thing | 13:26 |
| jennis | Under the Documentation Section | 13:26 |
| tristan | We have some API docs, but we dont have nice, clear explanations of what the Elements and Sources *have to do* | 13:26 |
| jennis | Now I'm asking if you think we should have Installing, Getting started, Documentation and Indices and tables as Sections within index.rst | 13:27 |
| tristan | For the format documentation, we are pretty tight, though; I think for that part we are really close to 100% well documented | 13:27 |
| tristan | This is of course, only useful to someone who has already gotten started :) | 13:27 |
| tristan | Well | 13:28 |
| tristan | jennis, I'm not sure; you want to split out project authoring and plugin authoring into something separate ? | 13:28 |
| gitlab-br-bot | buildstream: merge request (215-workspace-builds-might-not-rebuild-correctly-when-dependecies-are-updated->master: WIP: Resolve "Workspace builds might not rebuild correctly when dependecies are updated") #315 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/315 | 13:29 |
| tristan | jennis, I think that's okay, perhaps lets call that "Reference Documentation" | 13:29 |
| gitlab-br-bot | buildstream: merge request (jjardon/misc_fixes->master: Some little documentation fixes) #326 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/326 | 13:29 |
| jennis | And then Getting started to go under Documentation or to be it's own section? | 13:29 |
| tristan | jennis, Also, off the top of my head I think: Installing, Getting Started, Examples, Using (invoking.rst), Reference Documentation | 13:30 |
| jennis | ok | 13:31 |
| tristan | Or, maybe Using belongs under "Reference Documentation" as well, that one is a bit ambiguous | 13:31 |
| jennis | Atm: using, authoring projects, authoring plugins, is all under "Documentation" | 13:32 |
| tristan | Reference Documentation is exactly that, though; it's where you go to remember something when you need | 13:32 |
| tristan | Ah; I'm not even thinking in that sense | 13:32 |
| tristan | jennis, rather I'm thinking, these are main toplevel links which bring you to individually focused pages | 13:32 |
| tristan | jennis, the titles on the main page rather separate things, they are rather immaterial | 13:33 |
| tristan | they separate the important main links from "What is BuildStream", mostly | 13:33 |
| tristan | jennis, so I'm thinking, when you hit that main page, you are not bombarded with details of reference documentation; instead you are presented with a simple choice, red pill or blue pill | 13:34 |
| jennis | I agree with that, but I also disagree with the titles being immaterial, they should clearly and simply represent what you can find from this main page | 13:35 |
| jennis | But I will create a plan and a couple of MRs and see what you thin | 13:35 |
| jennis | think | 13:35 |
| tristan | jennis, I mean the headings on the main page - they are not a "node" in the ToC tree in my mind | 13:36 |
| tristan | jennis, I am saying this because it *completely* changes the context of what we have been talking about just now | 13:36 |
| tristan | I am thinking about nodes in which you dig | 13:36 |
| tristan | well, maybe it does not change it *that* much | 13:37 |
| jennis | ok, there is plenty of information here for me to digest + create some kind of plan | 13:38 |
| tristan | jennis, Alright; I look forward to a more complete proposal / game plan from you | 13:40 |
| tristan | jennis, and I will be grateful to have a single point of contact / lieutenant for this effort, this makes things much easier and streamlined for us to get off the ground | 13:41 |
| tristan | jennis, two last points... | 13:45 |
| tristan | jennis, first, lets use the alpine image which ssssam[m] cooked up for our integration tests, it is currently the smallest, and thus the fastest runtime to obtain | 13:45 |
| tristan | i.e. for any getting started material, and (ideally) for examples as well | 13:46 |
| tristan | also, it will suck if we have to start having many different images | 13:46 |
| tristan | ideally, we would rather use a bootstrap image from the freedesktop-sdk project; because that's an image built by BuildStream | 13:47 |
| tristan | jennis, but that can be a separate effort; when freedesktop-sdk provides a nicely trimmed output that is fairly small, we can swap out alpine for it *across the board* | 13:47 |
| tristan | jennis, second point: well it's not really a point, but I want you to think about what we are going to achieve in "Getting Started", i.e. what things will we teach the user, and what kind of elements we're going to use | 13:48 |
| tristan | I think something simple like; building something on top of the alpine image, using both the manual style first, and then say; building the same thing with autotools... | 13:49 |
| tristan | and workspacing the code, making a change to the code, and using `bst shell` to launch it an debug it | 13:49 |
| tristan | should be rather enough, but there can and will be conflicting views :) | 13:49 |
| jjardon[m] | tristan new theme doesn't work correctly if you don't change the TOC stuff | 13:50 |
| tlater | "We should cover the details of bst source-bundle" | 13:50 |
| tlater | ;P | 13:51 |
| tristan | jjardon[m], but the TOC changes improve things without changing the theme, right ? | 13:51 |
| tristan | tlater, and we should have test coverage for that... and I'm sure toscalix would like to use a variety of `bst source-bundle` for the purpose of compliance, i.e. "just the sources, and exactly these sources" but perhaps without the generated build scripts | 13:52 |
| tristan | tlater, would also be nice if `bst source-bundle` does *not* include things like... the .git/ subdirectory of git repos; does it already do this ? | 13:53 |
| tlater | I frankly don't remember | 13:53 |
| tristan | seems an interesting thing compliance-wise... lets make a tarball of "all the sources which exactly went into this" | 13:53 |
| tristan | yeah, it was a while ago | 13:53 |
| gitlab-br-bot | buildstream: merge request (issue-243_dpkg_import_source_plugin->master: Created DPKG Source plugin for Issue #10) #305 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/305 | 13:53 |
| tristan | it makes up for a good amount of our ~17% of code that is still not covered by tests | 13:53 |
| tlater | It certainly needs a refactor too | 13:54 |
| tlater | Do we have an open issue for this yet? | 13:54 |
| jjardon[m] | tristan "lets completely forget that 323 exists" this doesn't encourage me or any other contributor to spend time trying to fix sonething | 13:54 |
| tristan | tlater, check | 13:54 |
| * tlater can't find one | 13:54 | |
| jjardon[m] | Which has been broken for months now BTW | 13:55 |
| tristan | jjardon[m], it's too much for me to handle, changes too many things; docs has been a big issue, read the backlog if you want to understand | 13:55 |
| tristan | jennis, it's closing time here, but I think we're off to a good start | 13:55 |
| *** tristan has quit IRC | 13:58 | |
| jjardon[m] | Wherever is in those commits is way better to what we have now | 14:03 |
| jjardon[m] | I don't understand why we can not merge that and keep improving in posterior mr | 14:03 |
| *** tristan has joined #buildstream | 14:04 | |
| jjardon[m] | Instead waiting some days/weeks/ months to have the perfect documentation | 14:04 |
| tristan | jjardon[m], I'm sorry if you feel discouraged, there are too many separate things, most/all of which I believe are not good enough to land yet | 14:05 |
| tristan | You may think "its better than nothing", I disagree, and wont land stuff before it's done well | 14:05 |
| jjardon[m] | Its better than the current docs | 14:06 |
| jjardon[m] | Not nothing | 14:06 |
| tristan | jjardon[m], 323 specifically, also does a lot of separate stuff at once, which means reviewing it is not an efficient use of time, some changes might be ready to land, while others will just block the whole thing. | 14:06 |
| jjardon[m] | But I guess we have to agree to disagree | 14:06 |
| tristan | jjardon[m], finally, jennis is going to be running point on docs until we at least ramp up and have structure and policy | 14:07 |
| tristan | he will be incorporating parts of 323 | 14:07 |
| jjardon[m] | (I'd feel the same if they were other person patches BTW) | 14:07 |
| jjardon[m] | Please update the MR's with what the current plan is , at least people that take a look there know what is happening | 14:09 |
| tristan | jjardon[m], to respond to what I had missed while moving away from coffee shop... "I don't understand why we can not merge that and keep improving in posterior mr" | 14:09 |
| tristan | We dont do things that way around here, basically. | 14:09 |
| tristan | When something is added, it should not require improvements until it does - if we were to work that way, then at least 80% of the incomplete stuff that we land on master, will never be improved | 14:10 |
| tristan | That is from experience, it's just a natural effect of letting stuff land | 14:10 |
| tristan | So, people may think that I don't care enough about docs, it's the opposite; I care a great deal. | 14:11 |
| gitlab-br-bot | buildstream: issue #310 ("`bst source-bundle` should get better documentation and receive test cases") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/310 | 14:12 |
| * tristan goes to obtain a late night dinner. | 14:12 | |
| tlater | o/ tristan | 14:12 |
| dominic | Can I just confirm that with issue #286 that it's going to be a fix on bubblewrap that we want upstream | 14:12 |
| tristan | dominic, issue says "We should upstream a patch for this and then conditionally start using the feature in BuildStream on sites which have a recent enough version of bwrap." | 14:13 |
| tristan | dominic, we cannot close 286 until we have done both parts of that sentence | 14:14 |
| tristan | dominic, it also implies that we need to start version checking bwrap, which we have been careless about; but we still use only bwrap CLI args that are available since... a very long time. | 14:14 |
| tristan | (except one case, where we feature test for it instead, which juergbi added; that should be transformed into a version check at the same time) | 14:15 |
| * dominic nods | 14:15 | |
| dominic | ty tristan | 14:15 |
| tristan | :) | 14:15 |
| jjardon[m] | tristan the MR about the docs can go as it is. Its notthing incorrect about it, althoug of course it can be improved | 14:18 |
| jjardon[m] | tristan as I said, the sedult would be much better than what we currently have now | 14:18 |
| jjardon[m] | tristan and I care about this too, if not I would not have spend my thrusday evenenin doing it | 14:19 |
| jjardon[m] | tristan and btw, Im not suggesting merge it as is; it already include modification jennis have suggested. But hold on improving something that is curently broken because we want to have something much better I do not think is the best approach | 14:21 |
| jjardon[m] | tristan Its my opinnion, as I said before we can agree on disagree | 14:22 |
| gitlab-br-bot | buildstream: issue #278 ("Filter documentation could be better") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/278 | 14:33 |
| gitlab-br-bot | buildstream: merge request (278-filter-documentation-could-be-better->master: Resolve "Filter documentation could be better") #304 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/304 | 14:33 |
| *** Prince781 has joined #buildstream | 14:37 | |
| laurence | skullman, something I should have mentioned earlier: landing 'UI for inspecting build logs and failed builds from the artifact cache' is dependent on 'Caching Build Tree' which Nexus is currently working on. | 14:51 |
| laurence | I don't *think* you'll be blocked at all though, as I imagine development can start already without Build Tree Caching being implemented | 14:52 |
| skullman | laurence: AIUI the majority of the work is not going to be dependent on Caching Build Tree. | 14:54 |
| laurence | skullman, great | 14:55 |
| tristan | jjardon[m], as I mentioned in the conversation above, I dont like changing the "What is BuildStream" to start mentioning such specifics, I also would not accept the example paulsherwood came up with the way it was presented; in needs explaining and proper formatting, not using "echo foo > foo.bst" in the example, the fact that this comes with a re-organization of the ToC right now, when jennis is about to prepare a more complete plan for | 14:55 |
| tristan | organizing of things, doesnt help either | 14:55 |
| tristan | jjardon[m], the timing is actually bad, because accepting docs patches will become much easier once jennis has gotten us off the ground | 14:56 |
| jjardon[m] | tristan "What is Buildstream" was not changed in the initial MR, it was something actually suggested in the review | 14:56 |
| jjardon[m] | tristan tell me in the review to remove the Paul example then, or improve it | 14:57 |
| tristan | jennis, also, you might want to consider doing work on a `documentation` side branch for the time being, if people are going to be submitting patches against docs a lot during this time, they should probably be making merge requests targetting your side branch | 14:57 |
| tristan | jjardon[m], no, it's under jennis's control, not mine, until things are up and running he is the point of contact for general documentation | 14:58 |
| jjardon[m] | ??? | 14:58 |
| jjardon[m] | he was the one reviewing and accepting the MR as they are? | 14:59 |
| tristan | jjardon[m], yes, this is what we have been discussing today, until we have structure layed out, he is going to be documentation lieutenant | 14:59 |
| * jjardon[m] confused | 14:59 | |
| tristan | jjardon[m], not on master | 14:59 |
| tristan | jjardon[m], I know people are frantic about docs now, but jennis is working on a plan, that is going to be solved before we start landing things on master | 15:00 |
| tristan | what you and jennis have been discussing in MRs, I have not been watching | 15:00 |
| jennis | tristan, could that not lead to the side "documentation" branch getting clogged with changes that we don't want | 15:01 |
| tristan | jennis, only if you hurry to land things that you do not find to be ready | 15:01 |
| tristan | jennis, if you are the point of contact for this effort, you are maintainer of that branch until it's merged, if you accept that people contribute to your branch in that period, that is fine with me | 15:02 |
| jennis | tristan, ok, let's see how that goes | 15:03 |
| tristan | First we discuss structure and planning once you present your plan, when you think the first steps are ironed out in your branch, I'll spend the time to make a thorough review of that | 15:03 |
| tristan | jennis, you are not obligated, but you have expressed that you are incorporating jjardon[m]'s changes, if I understood correctly | 15:03 |
| jennis | Ok, also before all that, before I do this, we agreed that the changes made to the ToCTree were something that can be merged ASAP on its own branch? | 15:04 |
| tristan | So, for the time being, when it comes to patches for doc/source/* that is not related to existing well defined docs (i.e., all of this extra stuff), I am not going to take care of until we land your work. | 15:04 |
| jennis | ^^ ok no worries | 15:04 |
| tristan | jennis, we did, and if the theme change also has a practical benefit; i.e. it actually works on mobile and the current theme does not; then we can land that too | 15:05 |
| jennis | but just to clarify, it's changes like this you would expect in two different MRs? Or you're ok with two clear commits | 15:06 |
| jjardon[m] | tristan if you have looked to the MR, you could see that I have reworking things jennis have suggested. Seems that we have a new plan now; please update the MR so everyone is aware | 15:06 |
| tristan | jennis, this change I felt that; it makes the ToC better, i.e. the side bar becomes suddenly more useful - but this does not seem to require changing the theme, it still improves the sidebar | 15:07 |
| tristan | jennis, please update the MR | 15:07 |
| tristan | as jjardon[m] requests. | 15:07 |
| jjardon[m] | tristan jennis I have tried to change the sidebar only: it doesnt work in the current theme | 15:08 |
| tristan | ah, I thought jennis tried that earlier | 15:09 |
| tristan | jjardon[m], does the side bar expand/collapse on mobile ? | 15:09 |
| tristan | if so, I'm sold to land that right now | 15:10 |
| tristan | jennis, before I start eating, I should clarify regarding merge requests... | 15:10 |
| tristan | jennis, *your* branch will be one merge request, with probably many commits (no need to create an MR and spam the channel until it's close to ready) | 15:10 |
| jennis | No I was going to try it now | 15:10 |
| jjardon[m] | tristan with the new theme? I have not tried but other pages with that theme it does | 15:11 |
| tristan | jennis, however - we want to keep this exercise as quick as possible, so that means; we decide on policy, effect structural changes to the docs in your branch, and add the minimum amount of *ready* material | 15:11 |
| jennis | right agreed | 15:12 |
| tristan | jennis, i.e. we want a policy in place so that we can more effectively consume docs patches, and people submitting them find some structure, and that's it | 15:12 |
| tristan | yeah, we're on the same page; I didnt want people in channel to think this was going to be a long dragged out affair :) | 15:12 |
| jennis | good stuff, I'll send you the plan once it's done | 15:13 |
| tristan | jennis, we'll just merge !327 with the theme change - with an update to the HACKING file | 15:23 |
| tristan | dont bother splitting that, as jjardon[m] mentioned, the ToC stuff also doesnt work without theme change | 15:24 |
| tristan | I think there is a stray commit in another branch which fixes doc/source/conf.py to report the correct version, now that it appears in that new theme it would be good to apply that straight away too. | 15:25 |
| jennis | The stray commit was in !326 | 15:27 |
| jennis | So are both being merged? | 15:28 |
| jennis | !326 involves the conf.py change you mentioned as well a couple of title changes within install.rst | 15:29 |
| tristan | jennis, I mean the commit which does that in !326 | 15:30 |
| jennis | tristan, unless you're opposed to the title changes, it should be find to merge both | 15:30 |
| tristan | I was going to cherry pick it myself, but resisted the temptation because it doesnt change the docs at all; it does with the new theme, though. | 15:31 |
| tristan | jennis, looks like other comments are addressed there, so yeah whole branch can land too :) | 15:32 |
| juergbi | it also fixes the 0.1 version in the title, i presume | 15:32 |
| tristan | juergbi, ah, I missed that part :) | 15:32 |
| tristan | juergbi, wasn't looking at my browser's page title | 15:33 |
| gitlab-br-bot | buildstream: merge request (jjardon/theme_change->master: Change theme to sphinx_rtd_theme) #327 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/327 | 15:33 |
| gitlab-br-bot | buildstream: merge request (jjardon/theme_change->master: Change theme to sphinx_rtd_theme) #327 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/327 | 15:35 |
| Nexus | I'm currently working on implementing the caching of build trees. Where would put the tests to check that my changes work? | 15:43 |
| Nexus | juergbi, tlater any thoughts? | 15:45 |
| * tlater has forgotten the end goal of the build tree caching | 15:45 | |
| juergbi | probably need an integration test | 15:45 |
| tlater | Do we want the user to ever look at it? | 15:45 |
| juergbi | it's a mechanism with multiple end goals | 15:46 |
| juergbi | one is for incremental build right after opening a workspace | 15:47 |
| juergbi | another is inspecting a failed remote build | 15:47 |
| juergbi | and another is incremental non-workspace builds | 15:47 |
| jennis | ok, tristan I don't have permission to merge btw, do you mind doing ity | 15:47 |
| tlater | But I suppose none of this will be added in Nexus' branch | 15:48 |
| tlater | Hm, that makes it a bit tricky to test | 15:48 |
| Nexus | :( | 15:48 |
| juergbi | maybe add the first one in the same MR? | 15:48 |
| juergbi | might be simple enough | 15:48 |
| juergbi | we generally anyway don't want to add internal features that are not used yet | 15:49 |
| *** valentind has joined #buildstream | 15:52 | |
| Nexus | juergbi: so what is it id have to do? is there an issue i can look at? | 15:56 |
| juergbi | I don't see an open issue about this | 15:59 |
| juergbi | the basic idea is that 'bst workspace open' will populate the workspace with the cached build tree to allow incremental build | 16:00 |
| gitlab-br-bot | buildstream: merge request (issue-243_dpkg_import_source_plugin->master: Created DPKG Source plugin for Issue #10) #305 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/305 | 16:01 |
| juergbi | it's actually mentioned in #21 | 16:01 |
| gitlab-br-bot | buildstream: merge request (jjardon/misc_fixes->master: Some little documentation fixes) #326 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/326 | 16:04 |
| tristan | jennis, now you do | 16:07 |
| tristan | at least for now | 16:07 |
| tristan | :) | 16:07 |
| jennis | aha thanks, I've just found a typo which I'm going to fix as part of that branch | 16:09 |
| Nexus | juergbi: please could you create an issue for me, so i can get a better understanding of what's needed and have something to reference? i'm still not certain of what this task involves | 16:10 |
| gitlab-br-bot | buildstream: merge request (jjardon/misc_fixes->master: Some little documentation fixes) #326 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/326 | 16:10 |
| juergbi | tristan: do you have a quick comment on whether we have a policy against subclassing among mainline plugins (!305)? or is this a longer discussion? | 16:12 |
| gitlab-br-bot | buildstream: merge request (jjardon/misc_fixes->master: Some little documentation fixes) #326 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/326 | 16:13 |
| tristan | juergbi, commented | 16:17 |
| juergbi | ta | 16:17 |
| tristan | juergbi, my reply might be premature, but I think it's quite fine inside mainline, and it's also fine within bst-external | 16:18 |
| Nexus | so i should make it a subclass? | 16:18 |
| juergbi | i'd say so, yes. there is quite a bit of duplicated code right now | 16:18 |
| tristan | for bst-external like package inter-subclassing, I may be wrong, or forgetting some detail | 16:18 |
| tristan | Ah, it might not work, too | 16:19 |
| tristan | juergbi, it might work for Source plugins but not Element plugins | 16:19 |
| tristan | because of the type-wide .yaml templates | 16:19 |
| tristan | so yeah, at least for this case, it should be fine | 16:19 |
| juergbi | ok | 16:19 |
| laurence | juergbi, Nexus, my notes from the f2f conversation in Jan tell me that Element Specific Build Directories and Cache Build Tree are blockers for 4 use cases we thought of: Workspace Open to contain build tree, Non-workspaced incremental builds, Source code available in environment in order to debug and finally UI for inspecting build logs and failed builds from the artifact cache | 16:21 |
| gitlab-br-bot | buildstream: merge request (jjardon/theme_change->master: Change theme to sphinx_rtd_theme) #327 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/327 | 16:21 |
| laurence | My point here being that I'd thought we were approaching Cache Build Tree as a stand alone thing and then other 4 things to come after it | 16:24 |
| juergbi | laurence: the issue is that it doesn't really make sense to merge something that is not actually used it | 16:24 |
| juergbi | *yet | 16:24 |
| juergbi | among other things, you can't properly test it | 16:24 |
| juergbi | they are definitely separate commits / subtasks but at least one actual use case should be working with the MR | 16:25 |
| Nexus | so "Cache Build Tree" should actually be part of those 4 cases, not a blocker for them? | 16:25 |
| Nexus | since it's can't stand alone | 16:26 |
| Nexus | it | 16:26 |
| juergbi | it just shouldn't be merged stand-alone | 16:26 |
| Nexus | kk | 16:26 |
| juergbi | you can develop it stand-alone but for testing and merging you need one of those 4 | 16:26 |
| gitlab-br-bot | buildstream: merge request (jjardon/misc_fixes->master: Some little documentation fixes) #326 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/326 | 16:27 |
| laurence | alright, I see now, thanks juergbi, I shall get back in my cave and shut up :) | 16:27 |
| Nexus | of those 4, are there any currently fleshed out enough to be worked on? | 16:27 |
| juergbi | i expect the 'open workspace' one to be the simplest, so would suggest to do that as the first of the 4 | 16:27 |
| Nexus | kk | 16:27 |
| juergbi | Nexus: is the basic idea about opening the workspace with the cached build tree clear? details have to be worked out | 16:30 |
| Nexus | is this the same thing as "Workspace Open to contain build tree" ? | 16:31 |
| juergbi | yes | 16:31 |
| Nexus | So the basic idea being that, instead of opening a workspace with a new build, it pulls in the most recent cached build tree and uses that as its source instead? | 16:32 |
| Nexus | do i have that right? | 16:32 |
| gitlab-br-bot | buildstream: merge request (jjardon/misc_fixes->master: Some little documentation fixes) #326 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/326 | 16:33 |
| gitlab-br-bot | buildstream: merge request (jjardon/misc_fixes->master: Some little documentation fixes) #326 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/326 | 16:46 |
| *** Prince781 has quit IRC | 16:47 | |
| juergbi | Nexus: yes. at least for now we could restrict this to an exact cache key match to keep this simple | 16:49 |
| juergbi | i.e., only do this if we already have an artifact (with build tree) for the current cache key of the element | 16:49 |
| juergbi | in the future we could also support it for older builds but that should likely be part of the effort to support incremental non-workspace builds | 16:50 |
| Nexus | juergbi, tristan Do we want to make DebSource a subclass of TarSource? Wouldn't it be cleaner to make a base class for both? | 16:51 |
| juergbi | that would definitely also be a possibility | 16:51 |
| juergbi | however, TarSource already has _get_tar() that can be overridden, so subclassing TarSource might work without changes there | 16:52 |
| juergbi | i.e., I expect subclassing TarSource to be simpler and acceptable but I would also accept a new base class | 16:52 |
| juergbi | in that case, the refactoring (introducing new base class) should be a separate commit, though | 16:53 |
| jjardon[m] | tristan confirmed, https://buildstream.gitlab.io/buildstream/ works well in mobile :) | 16:53 |
| Nexus | is there a preference? | 16:53 |
| gitlab-br-bot | buildstream: merge request (jjardon/misc_fixes->master: Some little documentation fixes) #326 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/326 | 16:54 |
| juergbi | Nexus: I would take the simpler route (directly subclassing TarSource) unless you have a reason not to. this isn't about public API, so it could also be refactored later if a need arises | 16:54 |
| Nexus | kk | 16:54 |
| gitlab-br-bot | buildstream: merge request (richardmaw/build-status-extensions->master: WIP: Print summary of failed builds) #329 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/329 | 17:08 |
| gitlab-br-bot | buildstream: merge request (issue-243_dpkg_import_source_plugin->master: Created DPKG Source plugin for Issue #10) #305 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/305 | 17:16 |
| gitlab-br-bot | buildstream: merge request (fix_typo_on_homepage->master: index.rst: Fixed typo in About BuildStream) #330 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/330 | 17:18 |
| gitlab-br-bot | buildstream: merge request (fix_typo_on_homepage->master: index.rst: Fixed typo in About BuildStream) #330 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/330 | 17:19 |
| *** Prince781 has joined #buildstream | 17:30 | |
| gitlab-br-bot | buildstream: merge request (jjardon/getting_started->master: Add getting started section) #323 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/323 | 18:00 |
| *** jonathanmaw has quit IRC | 18:00 | |
| *** dominic has quit IRC | 18:01 | |
| gitlab-br-bot | buildstream: merge request (jjardon/getting_started->master: Add getting started section) #323 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/323 | 18:05 |
| *** Prince781 has quit IRC | 18:19 | |
| *** slaf- has joined #buildstream | 18:27 | |
| *** slaf- has joined #buildstream | 18:27 | |
| *** slaf has quit IRC | 18:29 | |
| *** slaf- is now known as slaf | 18:29 | |
| gitlab-br-bot | buildstream: merge request (jjardon/copyright->master: Some changes to the copyrigth / author lines) #331 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/331 | 20:23 |
| gitlab-br-bot | buildstream: merge request (jjardon/copyright->master: Some changes to the copyrigth / author lines) #331 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/331 | 20:24 |
| gitlab-br-bot | buildstream: merge request (jjardon/copyright->master: Some changes to the copyrigth / author lines) #331 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/331 | 20:25 |
| gitlab-br-bot | buildstream: merge request (jjardon/contributing->master: Add HACKING document to official docs) #332 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/332 | 20:26 |
| gitlab-br-bot | buildstream: merge request (jjardon/contributing->master: Add HACKING document to official docs) #332 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/332 | 20:27 |
| gitlab-br-bot | buildstream: merge request (jjardon/copyright->master: Some changes to the copyrigth / author lines) #331 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/331 | 20:27 |
| *** ernestask has quit IRC | 20:44 | |
| *** Prince781 has joined #buildstream | 20:50 | |
| *** sstriker has quit IRC | 21:00 | |
| *** tristan has quit IRC | 22:00 | |
| *** Prince781 has quit IRC | 22:11 | |
| *** Prince781 has joined #buildstream | 22:25 | |
| *** Prince781 has quit IRC | 22:36 | |
| *** valentind has quit IRC | 22:41 | |
| *** Prince781 has joined #buildstream | 22:48 | |
| *** aday has quit IRC | 22:59 | |
| *** Prince781 has quit IRC | 23:30 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!