| *** noisecell has joined #buildstream | 05:38 | |
| *** noisecell has quit IRC | 05:41 | |
| *** ernestask has joined #buildstream | 06:31 | |
| *** bochecha_ has joined #buildstream | 07:18 | |
| *** toscalix has joined #buildstream | 07:34 | |
| *** tristan has joined #buildstream | 07:56 | |
| *** mohan43u has joined #buildstream | 08:11 | |
| *** jennis has joined #buildstream | 08:13 | |
| gitlab-br-bot | buildstream: merge request (valentindavid/359_cross_junction_elements->master: Allow names for cross junction elements) #454 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/454 | 08:16 |
|---|---|---|
| juergbi | toscalix: not sure whether that's clear to you, BuildStream 1.1.x are considered development releases that lead to the 1.2 stable release series | 08:16 |
| toscalix | it is | 08:16 |
| juergbi | with this the milestones 1.1 and 1.2 don't make much sense to me | 08:16 |
| gitlab-br-bot | buildstream: merge request (valentindavid/359_cross_junction_elements->master: Allow names for cross junction elements) #454 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/454 | 08:16 |
| juergbi | shouldn't it be 1.2 and 1.4? | 08:17 |
| *** jennis_ has joined #buildstream | 08:27 | |
| *** jennis has quit IRC | 08:28 | |
| *** jennis has joined #buildstream | 08:29 | |
| *** tristan_ has joined #buildstream | 08:36 | |
| *** tristan has quit IRC | 08:37 | |
| *** tristan__ has joined #buildstream | 08:37 | |
| *** jonathanmaw has joined #buildstream | 08:39 | |
| *** tristan_ has quit IRC | 08:39 | |
| *** bethw has joined #buildstream | 08:42 | |
| juergbi | hi cs_shadow, I've updated https://gitlab.com/BuildStream/buildstream-docker-images/merge_requests/29 Review would be appreciated | 09:07 |
| cs_shadow | juergbi: hey! Will take a look shortly, just getting ready to get to office :) | 09:08 |
| juergbi | thanks, no hurry | 09:09 |
| *** dominic has joined #buildstream | 09:09 | |
| *** tiago has joined #buildstream | 09:13 | |
| *** aday has joined #buildstream | 09:22 | |
| toscalix | Once the Gitlab changes has been introduced, we have spotted a use case the proposal did not covered. I have made a proposal to cover it | 09:28 |
| juergbi | toscalix: any comments on the 1.1/1.2 milestones? | 09:41 |
| toscalix | I said it is clear to me. tristan__ explained it to me some days ago, before I did the proposal. | 09:43 |
| toscalix | the milestone structure is flat, so in terms of Gitlab, there is no difference between v1.1.x serie and v1.2.x serie | 09:44 |
| toscalix | for us, they are different because, in theory, in the future the delivery process for both of them will be different, so the tasks we will execute on each case. | 09:45 |
| toscalix | but for Gitlab, milestones are just a collection of tasks related with time | 09:46 |
| gitlab-br-bot | buildstream: merge request (juerg/googlecas->master: WIP: Google CAS-based artifact cache) #337 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/337 | 09:46 |
| toscalix | probably something worth mentioning in the milestone description. I will add it right now | 09:46 |
| juergbi | toscalix: sure but I don't see how the new milestones make sense | 09:46 |
| juergbi | BuildStream_v1.1 · Feb 20, 2018–Sep 4, 2018 | 09:46 |
| juergbi | this is the development time leading up to 1.2, so I would call the milestone 1.2 | 09:47 |
| juergbi | BuildStream_v1.2 · Sep 5, 2018–Jun 5, 2019 | 09:47 |
| juergbi | no idea where you take that date range from with regards to 1.2 | 09:47 |
| juergbi | if this is for the next feature release after 1.2, it should be called 1.4 (and I expect it to end in March or April) | 09:47 |
| toscalix | it is a guess, based on when we released v1.0 | 09:47 |
| toscalix | related with the naming | 09:48 |
| juergbi | our plan was/is to follow the GNOME 6 month cycle starting with 1.2 | 09:48 |
| toscalix | ah, that is news to me. | 09:48 |
| toscalix | I will put in my todo to learn about this and accomodate the timing appropietly | 09:49 |
| juergbi | ok | 09:49 |
| toscalix | related with the naming, I have been here before. It is a matter of interpretation. In terms of development we are in the v1.2 cycle. That is a dev view | 09:49 |
| toscalix | but in terms of delivery...we are delivering v1.1.x versions | 09:50 |
| toscalix | until we deliver v1.2 From that point, we start to deliver 1.2.x versions | 09:50 |
| toscalix | and probably 1.3.x in parallel at some point | 09:51 |
| toscalix | so we will have stable versions being maintained in parallel with development versions | 09:51 |
| juergbi | toscalix: we can consider these features part of 1.1, yes. however, then the following feature phase has to be called 1.3, not 1.2 | 09:51 |
| juergbi | 1.2.x will not be feature releases | 09:51 |
| toscalix | but there will be tickets associated to it, like bugs, like release related features, communications, etc | 09:52 |
| toscalix | so we will need a milestone for it | 09:52 |
| toscalix | so probably what we need to reflect that is to add milestone 1.3 | 09:53 |
| toscalix | so we can move dev related tickets further if they do not make this cycle | 09:53 |
| juergbi | if this is just for stable / bug fixes, then there shouldn't be a due date | 09:53 |
| juergbi | unless we'll have separate milestones for 1.2.1, 1.2.2 | 09:54 |
| toscalix | we need them for tasks related with the release, right? | 09:54 |
| toscalix | if we need to make a release announcement for 1.2, that comes with a due date concept associated | 09:54 |
| juergbi | if the milestone is for 1.2.x releases after 1.2.0, we either have a single 1.2 milestone without due date or have 1.2.x milestones each with a short due date | 09:54 |
| juergbi | the 1.2.0 release is planned for September, I thought you wanted to put tasks belonging to the lead up to 1.2.0 into the 1.1 milestone | 09:55 |
| * juergbi is confused | 09:55 | |
| toscalix | I would like to prevent having a milestone per minor release for now, to simplify the gitlab structure | 09:55 |
| juergbi | that's fine with me but then the due date of the 1.2 mile stone doesn't make any sense to me | 09:55 |
| toscalix | it is when the v1.2 cycle ends. If we decide we will support v1.2 serie for two years, for instance, the due date will be that end of cycle date. | 09:57 |
| toscalix | so that date is not correct until we define how long the v1.2 stable version will be supported, which I assume it will be until v1.4 is out for now | 09:58 |
| juergbi | it seems a bit counter-intuitive to me to call that due date but maybe it's the best fit in gitlab, don't know | 09:58 |
| toscalix | if the current dates add confusion, I will think a better way to express the cycle | 09:59 |
| toscalix | with what we have decided. I am sure it can be improved | 09:59 |
| juergbi | we definitely need to fix the milestone description, though | 09:59 |
| toscalix | agree | 09:59 |
| juergbi | right now it's | 09:59 |
| juergbi | 1.1: | 09:59 |
| juergbi | Second feature release after the initial MVP release | 09:59 |
| juergbi | 1.2: Third release after the stable version was initially release. The expected highlights are: | 10:00 |
| juergbi | which doesn't make sense | 10:00 |
| gitlab-br-bot | buildstream: merge request (214-filter-workspacing->master: Make workspace commands on a filter element transparently pass through to their build-dependency) #317 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/317 | 10:00 |
| toscalix | I had no time on friday to put into these and other details. This is the text I had in nosoftware example | 10:01 |
| toscalix | I copied and pasted it | 10:01 |
| juergbi | no problem as long as you're aware of it | 10:01 |
| toscalix | give me a couple of days | 10:01 |
| *** tristan__ has quit IRC | 10:28 | |
| jennis | juergbi, I've noticed there is a bit of a conflict for landing both my remote expiry and your code implementing the CAS cache | 10:39 |
| jennis | I.e. no more pushreceive.py | 10:39 |
| jennis | I'm a bit unclear on what the plan is here for implementing remote expiry within CAS | 10:40 |
| jennis | Are you able to explain? | 10:40 |
| finn | jennis, are you approving my MR then migrating the examples? | 10:43 |
| jennis | I'm just about to have a look over it, then perhaps yes :) | 10:43 |
| tlater | finn: I'll do that once your MR is done | 10:43 |
| jennis | ok I'll leave that to tlater | 10:43 |
| * tlater should look at migrating the other examples as well, after all | 10:44 | |
| tlater | Though I might ask jennis to do the write-up, since that was the plan for this branch, I think? | 10:44 |
| jennis | tlater, I would like to use finn's example specifically as the helloWorld example | 10:44 |
| jennis | need to have this chat with tristan first though | 10:45 |
| tlater | Yeah, I'll leave writing the actual howto to you | 10:45 |
| jennis | yeah, that will be within the getting started guide | 10:45 |
| tlater | It would make sense to temporarily add the .rst file to the bst-examples repository | 10:45 |
| jennis | I agree, but first I need to change it | 10:45 |
| tlater | So that we can migrate the examples in one clean fell swoop | 10:45 |
| * tlater will be adding his howto to that repository, as well | 10:46 | |
| jennis | Gotcha, I'll make a note to do that | 10:46 |
| juergbi | jennis: yes, that code will have to be moved to casserver. however, it's not clear yet which MR will land first | 11:14 |
| juergbi | if your MR will land first, I'll probably fix it up myself in my branch. if my MR lands first, I will at least help. let's discuss this in detail when we get to that point | 11:15 |
| jennis | I see, this is what I suspected the case was | 11:16 |
| jennis | Thank you for clarifying | 11:16 |
| *** bethw has quit IRC | 11:27 | |
| jennis | Trying to think get my head around a use-case for junctions here. Would appreciate some insight. So I have a junction foo.bst, which depends on the project foo which contains an element bar.bst. This project is hosted on github and we're tracking the master branch. Now, in MY project, I try to build baz.bst, but this build fails because bar.bst (within the foo project) is incorrect. | 11:37 |
| jennis | So now the next step is to open a workspace for bar.bst and fix it, which let's assume I do | 11:38 |
| jennis | Now, to make this fix work in my project, what are the options? | 11:38 |
| jennis | in fact, what I'm more unsure of is the workspace aspect. If I have an element that is not building correctly because the source code is wrong, I open up a workspace and modify the source code, correct? | 11:44 |
| jennis | Now when I build this element again, buildstream will use my workspace, right...? So, let's assume that works and now that element is "fixed", can we then patch this using the workspace? So that the next dev won't have the element breaking | 11:45 |
| jennis | Apologies for my crude use of the words "fix" and "break" | 11:46 |
| tlater | jennis: You then have to upstream your patch. | 11:47 |
| tlater | I.e., whatever is in the workspace has to go to the source | 11:47 |
| jennis | I see, and is there an easy way to do this that isn't just duplicating what you've done? | 11:47 |
| jennis | with workspaces | 11:47 |
| tlater | `git push`? | 11:47 |
| tlater | Depends on the source type, of course | 11:48 |
| jennis | ahh of course | 11:48 |
| jennis | Ok so back to the original question, let's assume a git source, one way could be to create a branch with your changes and push that upstream and then set the junction to track this branch? | 11:49 |
| jennis | Or, the slower alternative, you get this branch merged upstream and keep the junction tracking master, just ensure that you're using the `track-all` option | 11:50 |
| tlater | Yes, that would be the intended way to do this. You can also override the element in question if the dependant doesn't want to update their repository. | 11:50 |
| jennis | Perfect, thanks | 11:50 |
| * tlater isn't sure how this is done in detail, but is aware that junctions have that feature | 11:50 | |
| jennis | Oh hang on | 11:51 |
| jennis | So you're saying that you can keep the junction tracking the master branch for all other elements and have it track your branch for a specific element? | 11:51 |
| jennis | i.e. the one you've modified and are unable to merge upstream | 11:52 |
| tlater | Oh, you have always been able to do that | 11:52 |
| tlater | That's what the `track` parameter on git sources is for | 11:53 |
| jennis | yes, but to do this for a single element within the project the junction refers to | 11:53 |
| tlater | But you don't have to actually update the repository containing the project you depend on | 11:53 |
| tlater | I *believe* - implementation may be pending, but was discussed at some point | 11:54 |
| * tlater thinks there might be some miscommunication here | 11:54 | |
| tlater | When you say "junction", what do you refer to? | 11:55 |
| jennis | A junction element, that refers to another project, i.e. it's source is another bst project | 11:55 |
| tlater | Right, so in that case you would either have to build/workspace an element form that junction directly, or depend on it, right? | 11:56 |
| tlater | I believe your usecase is creating a workspace from an element inside the dependant project. | 11:56 |
| jennis | yes ^ | 11:57 |
| jennis | So, assuming a git source, i'd clone that project, open a workspace for the element and make the changes | 11:57 |
| jennis | ahh this is another step... | 11:58 |
| jennis | Push a branch upstream to the source of the element, then make a branch of this project that includes this, then track that branch from my junction element | 11:58 |
| tlater | jennis: You do not need to clone the project :) | 11:59 |
| tlater | `bst workspace open` does that for you - it also links up the git source correctly afaik | 11:59 |
| tlater | But yes, that latter is my point - I believe that is unnecessary | 12:00 |
| jennis | but you won't be able to use that command in the current project | 12:00 |
| jennis | because the current project (with the junction in) won't *see* the element that lives within the project referred to by the junction | 12:00 |
| tlater | jennis: Could you elaborate on how you wouldn't be able to use that command? | 12:00 |
| tlater | I might be wrong, but I thought there was a way to access those elements directly? | 12:01 |
| * jennis didn't think there was | 12:01 | |
| tlater | Yeah, that's possible, I'm not certain. juergbi implemented this I think? He might be able to shine some light on overriding elements, too. | 12:02 |
| jennis | however, I hope I'm wrong about that :p | 12:02 |
| * tlater has unfortunately not kept close watch on junctions, as he doesn't really have much use for them yet | 12:03 | |
| tlater | jennis: Here we go: https://gitlab.com/BuildStream/buildstream/issues/321 | 12:04 |
| tlater | It's not documented yet, but definitely possible :) | 12:04 |
| juergbi | also see https://gitlab.com/BuildStream/buildstream/merge_requests/454 | 12:07 |
| tlater | Also: "addressing of cross project elements on the command line is not yet supported", so your usecase falls flat atm | 12:08 |
| tlater | Ah, but !454 is going to fix that, ta juergbi ;) | 12:08 |
| *** noisecell has joined #buildstream | 12:15 | |
| *** xjuan has joined #buildstream | 12:31 | |
| tlater | jennis, finn I left some comments on your collaborative example branch - sorry for being so picky here |: | 12:32 |
| *** bethw has joined #buildstream | 12:37 | |
| * paulsherwood wonders if there's a bst flatpak yet | 13:04 | |
| tiago | Can you run a linux container inside a container | 13:06 |
| skullman | depends what permissions the outer container leaves for the inner one | 13:11 |
| skullman | user namespaces are meant to allow you to do it to an arbitrary level IIRC | 13:12 |
| toscalix | paulsherwood: we were talking this morning about that. The answer is no. The goal is to arrive to GUADEC with a different answer. I am unable yet to forecast if tasks that are not currently being executed will make it for GUADEC or not. | 13:35 |
| toscalix | but I hope valentind can develop on this soon | 13:36 |
| jennis | tlater, juergbi, thank you for the links | 13:56 |
| valentind | paulsherwood, there is a plugin, but it is still a bit crude. We should improve it to call directly to flatpak on the finalize images. We also have to handle inclusion of project configuration so that people who want to build flatpak apps do not need to create a large project.conf file each time. | 14:05 |
| toscalix | valentind: is referring to #331 https://gitlab.com/BuildStream/buildstream/issues/331 | 14:06 |
| toscalix | valentind: is this problem a bug? | 14:07 |
| paulsherwood | sorry, it should have been clearer. i meant, is it possible to install bst as a flatpak? | 14:09 |
| valentind | Ah | 14:09 |
| valentind | That should be relatively easy. | 14:09 |
| paulsherwood | :) | 14:10 |
| valentind | paulsherwood, however flatpak is kind of made for desktop applications. It is not practical to call "flatpak run io.gitlab.buildstream.BuildStream" instead of "bst". | 14:11 |
| paulsherwood | hmmm. maybe not the right thing to do, then | 14:12 |
| tiago | It was original thought to package desktop applications. However, I read that flatpak-builder is being distributed as a flatpak | 14:12 |
| tlater | valentind: 'alias bst=flatpak run io.gitlab.buildstream.BuildStream' ? | 14:12 |
| valentind | Maybe some integration in GNOME Builder would be nice. | 14:13 |
| tiago | https://blogs.gnome.org/alexl/2018/04/27/flatpak-inception/ | 14:14 |
| valentind | I did not realize there was such kind of exports. Then we could do it. | 14:15 |
| * paulsherwood still confuses GNOME Builder with all the other 'build tools' | 14:16 | |
| *** xjuan_ has joined #buildstream | 14:35 | |
| *** xjuan has quit IRC | 14:38 | |
| gitlab-br-bot | buildstream: merge request (214-filter-workspacing->master: Make workspace commands on a filter element transparently pass through to their build-dependency) #317 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/317 | 15:03 |
| *** xjuan__ has joined #buildstream | 15:10 | |
| *** xjuan_ has quit IRC | 15:12 | |
| *** aday_ has joined #buildstream | 15:28 | |
| *** aday has quit IRC | 15:29 | |
| *** aday_ is now known as aday | 15:30 | |
| jennis | So it looks like `bst build --track-all <element>` does not update the ref of a junction element before it starts fetching the sub-project's elements | 15:45 |
| jennis | You have to manually update the junction element with `bst track` beforehand | 15:46 |
| juergbi | yes, junctions need to be tracked explicitly | 15:47 |
| jennis | I see, it doesn't seem to mention this in the junction documentation, however I may have just missed it | 15:48 |
| jennis | juergbi, is it worth writing an issue for this? I can't see an open one | 15:52 |
| juergbi | an issue to add this to the documentation? | 15:52 |
| jennis | No | 15:53 |
| jennis | To implement automatic tracking for junction elements | 15:53 |
| jennis | I'm just not sure how possible that is with the current codebase | 15:53 |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 15:53 |
| juergbi | jennis: the current behavior is intentional but maybe there are ways to improve it | 15:54 |
| jennis | Well may I suggest an example rather verbally | 15:55 |
| juergbi | track uses dependency tracking. strictly speaking, junction elements are not dependencies | 15:55 |
| juergbi | sure | 15:55 |
| jennis | I think that once `--track-all` is invoked, surely we could do some kind of grep of the projects elements to look for a junction element. And then explicitly track this before we begin the rest | 15:56 |
| juergbi | I'm not saying it's impossible but before any implementation approaches are discussed, we'd have to discuss if and how we want the behavior to change | 15:57 |
| juergbi | think about use cases, does different behavior than the current make sense as default, what configurability is required if any, etc. | 15:59 |
| juergbi | I don't currently see a critical/urgent need to change the way things work but that might be very subjective | 16:00 |
| jennis | mhmm it sounds like you're suggested that this approach may be too expensive, as we're going to have to loop through all elements of a project regardless of the fact it contains a junction element or not | 16:00 |
| jennis | This will only be a pain if you've got a project relying on a lot of other buildstream projects, right? | 16:01 |
| juergbi | while this could be a concern, I didn't mention anything like that at all | 16:02 |
| juergbi | I mentioned that we'd need to discuss what we want before we discuss how we achieve it | 16:02 |
| jennis | aha yes, but I was presuming that was the main concern :p | 16:03 |
| juergbi | imo, it's important that the behavior of tools is easy to understand/follow as a user | 16:03 |
| juergbi | and that often coincides with relatively simple implementation | 16:04 |
| juergbi | but that's besides the point | 16:04 |
| jennis | True, however as a (test) user, I would have assumed the behaviour of `bst build --track-all` would have updated the junction's ref | 16:05 |
| jennis | However, as you've mentioned, I agree that there is not critical/urgent need to change this | 16:06 |
| juergbi | yes, it's definitely not clear cut | 16:07 |
| jennis | But I will add a note to the documentation | 16:07 |
| jennis | which should suffice for now | 16:07 |
| jennis | If you agree...? | 16:07 |
| *** xjuan__ is now known as xjuan | 16:10 | |
| juergbi | jennis: clarifying this in the documentation definitely sounds good to me | 16:17 |
| juergbi | if youw ant to propose a behavior change, it may make sense to start a thread on the mailing list. ideally, with a clear proposal | 16:17 |
| *** Prince781 has joined #buildstream | 16:29 | |
| finn | I'm about to send my Remote Execution mail out, one mailing list will be: buildstream-bloomberg@lists.codethink.co.uk | 16:34 |
| finn | What's the bazel on? | 16:34 |
| toscalix | buildstream-list@gnome.org should be another one | 16:35 |
| toscalix | and the bazel ML is... | 16:35 |
| toscalix | https://groups.google.com/forum/#!forum/bazel-dev ? | 16:36 |
| ltu | finn, no need to send to the first list you mention, dw about that | 16:36 |
| toscalix | confirming | 16:36 |
| finn | toscalix, do I just post a new topic on there then? | 16:37 |
| juergbi | finn: no, don't send it to the regular bazel mailing list | 16:37 |
| toscalix | finn: this one https://groups.google.com/forum/#!forum/bazel-discuss | 16:37 |
| juergbi | https://groups.google.com/forum/#!forum/bazel-buildfarm | 16:38 |
| toscalix | ah, juergbi list then | 16:38 |
| juergbi | this is the one for remote execution | 16:38 |
| finn | So I create a NEW TOPIC? | 16:38 |
| toscalix | did not know about that one | 16:38 |
| ltu | Mailing lists that aren't mailman are confusing... | 16:39 |
| juergbi | you can subscribe and use regular mail interface | 16:39 |
| juergbi | no need to use the web API | 16:39 |
| juergbi | new non-reply mail will implicitly create topic, that should be fine | 16:39 |
| toscalix | finn: juergbi maybe answering this mail? https://groups.google.com/forum/#!topic/bazel-buildfarm/EuhfoCnYGe4 | 16:39 |
| juergbi | it would be a possibility but I don't see an issue in starting a new thread | 16:40 |
| toscalix | finn: I would follow juergbi advice, I am new to this list | 16:41 |
| gitlab-br-bot | buildstream: merge request (jennis/note_explicit_tracking_of_junctions->master: Add a note explaining that junction elements must be explictly tracked) #468 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/468 | 16:43 |
| gitlab-br-bot | buildstream: merge request (jennis/note_explicit_tracking_of_junctions->master: Add a note explaining that junction elements must be explictly tracked) #468 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/468 | 16:46 |
| finn | sorry, what's the alias for emailing a google group from your web client? | 16:46 |
| finn | like bazel-buildfarm@gmail.com? | 16:47 |
| gitlab-br-bot | buildstream: merge request (jennis/note_explicit_tracking_of_junctions->master: Add a note explaining that junction elements must be explictly tracked) #468 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/468 | 16:48 |
| finn | s/web client/mail client | 16:48 |
| jmac | I believe you just send an email to that address, yes. It may be moderated if you haven't sent an email from your address before. | 16:48 |
| gitlab-br-bot | buildstream: merge request (jennis/note_explicit_tracking_of_junctions->master: Add a note explaining that junction elements must be explictly tracked) #468 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/468 | 16:49 |
| finn | jmac, for future it's: bazel-buildfarm@googlegroups.com | 16:52 |
| jmac | Ah yes, sorry | 16:53 |
| jmac | That was in juergbi's email that you linked but I didn't spot the different | 16:53 |
| jmac | difference | 16:53 |
| *** bethw has quit IRC | 16:58 | |
| *** Prince781 has quit IRC | 16:59 | |
| *** dominic has quit IRC | 17:02 | |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 17:06 |
| jmac | gitlab seems very slow to push at the moment | 17:06 |
| * tlater has the same proble | 17:07 | |
| tlater | *m | 17:07 |
| toscalix | it is | 17:08 |
| toscalix | but it works | 17:08 |
| toscalix | slooooooow | 17:12 |
| *** tiago has quit IRC | 17:15 | |
| toscalix | finn: I am interested in keeping track of your mail/document on BuildStream gitlab. | 17:16 |
| toscalix | should I add a link to your mail in this ticket https://gitlab.com/BuildStream/buildstream/issues/387 ? | 17:20 |
| * ltu hasn't received an email yet...everyone else recieved one? | 17:25 | |
| toscalix | I did | 17:25 |
| toscalix | I will forward it to the BuidStream ML | 17:26 |
| ltu | was the buildstream list copied? it should be, i think | 17:26 |
| ltu | ah, ok, thanks toscalix | 17:26 |
| toscalix | along with the implementation of the enhacements on BuildStream gitlab, I am writing dow a policy draft: https://gitlab.com/BuildStream/nosoftware/alignment/blob/master/BuildStream_policies.md | 17:31 |
| toscalix | that will land on the project wiki or/and product docu. As soon as I am done with the implementation of the policy, I will send the draft to the ML for reviewing | 17:32 |
| toscalix | before publishing | 17:32 |
| *** toscalix has quit IRC | 17:38 | |
| gitlab-br-bot | buildstream: merge request (135-expire-artifacts-in-local-cache->master: WIP: Resolve "Expire artifacts in local cache") #347 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/347 | 17:40 |
| *** ernestask has quit IRC | 18:05 | |
| *** jonathanmaw has quit IRC | 18:11 | |
| *** aday has quit IRC | 18:54 | |
| *** aday has joined #buildstream | 18:55 | |
| *** aday has quit IRC | 19:42 | |
| *** bochecha_ has quit IRC | 20:56 | |
| *** bochecha_ has joined #buildstream | 21:15 | |
| *** Prince781 has joined #buildstream | 21:18 | |
| *** Prince781 has quit IRC | 21:39 | |
| *** aday has joined #buildstream | 21:46 | |
| *** xjuan has quit IRC | 21:49 | |
| *** aday has quit IRC | 21:53 | |
| *** aday has joined #buildstream | 21:55 | |
| *** aday has quit IRC | 22:10 | |
| gitlab-br-bot | buildstream: issue #402 ("Save only the most recent build cache for each element") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/402 | 22:19 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!