| *** GodSkinS has joined #buildstream | 01:36 | |
| *** leopi has joined #buildstream | 03:49 | |
| *** tristan has quit IRC | 03:59 | |
| *** leopi has quit IRC | 04:01 | |
| *** leopi has joined #buildstream | 04:31 | |
| *** tristan has joined #buildstream | 04:34 | |
| *** connection0 has joined #buildstream | 05:12 | |
| *** noisecell has joined #buildstream | 06:15 | |
| *** SKYWARN has joined #buildstream | 06:27 | |
| *** Xe29 has joined #buildstream | 06:46 | |
| *** ernestask has joined #buildstream | 06:57 | |
| *** noisecell has quit IRC | 07:07 | |
| *** toscalix has joined #buildstream | 07:19 | |
| *** toscalix has quit IRC | 07:44 | |
| *** bochecha has joined #buildstream | 07:47 | |
| *** toscalix has joined #buildstream | 07:48 | |
| *** tiagogomes has joined #buildstream | 07:48 | |
| *** tiagogomes has quit IRC | 07:54 | |
| *** tiagogomes has joined #buildstream | 07:55 | |
| *** coldtom has joined #buildstream | 07:57 | |
| *** noisecell has joined #buildstream | 07:57 | |
| gitlab-br-bot | buildstream: merge request (phil/437-junction-tutorial->master: Phil/437 junction tutorial) #550 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/550 | 07:58 |
|---|---|---|
| *** tiagogomes has quit IRC | 08:02 | |
| *** toscalix has quit IRC | 08:07 | |
| *** toscalix_ has joined #buildstream | 08:07 | |
| *** flatmush has joined #buildstream | 08:09 | |
| *** finn has joined #buildstream | 08:13 | |
| *** mablanch has joined #buildstream | 08:17 | |
| *** toscalix_ has quit IRC | 08:18 | |
| *** toscalix_ has joined #buildstream | 08:18 | |
| *** toscalix_ has quit IRC | 08:20 | |
| *** toscalix has joined #buildstream | 08:20 | |
| *** WSalmon has quit IRC | 08:21 | |
| *** mablanch24 has joined #buildstream | 08:21 | |
| *** tiagogomes has joined #buildstream | 08:22 | |
| *** mablanch24 has quit IRC | 08:25 | |
| *** tiagogomes has quit IRC | 08:25 | |
| *** tpollard has joined #buildstream | 08:45 | |
| gitlab-br-bot | buildstream: issue #526 ("Add configuration option to fail on warnings") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/526 | 08:48 |
| gitlab-br-bot | buildstream: merge request (jmac/virtual_directories->master: Abstract directory class and filesystem-backed implementation) #445 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/445 | 08:49 |
| *** WSalmon has joined #buildstream | 08:53 | |
| *** LambdaComplex has joined #buildstream | 09:01 | |
| gitlab-br-bot | buildstream: merge request (phil/437-junction-tutorial->master: Phil/437 junction tutorial) #550 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/550 | 09:15 |
| *** rdale has joined #buildstream | 09:18 | |
| tlater | Ah, thanks qinusty, I'll have a look at the branch in a minute | 09:30 |
| *** coldtom has quit IRC | 09:31 | |
| tlater | qinusty: I take it that screenshot is no longer up-to-date ;p | 09:33 |
| gitlab-br-bot | buildstream: merge request (tpollard/386->master: widget.py: Limit failure summary to currently failing elements) #561 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/561 | 09:34 |
| gitlab-br-bot | buildstream: merge request (chandan/sourcetransform->master: WIP: Allow source plugins to access previous sources) #568 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/568 | 09:45 |
| jmac | I'm unsure of the status of !445 now. Kinnison has reviewed it. juergbi, do you want to look over it again before we merge it? | 09:46 |
| * Kinnison thinks it looks good and jmac dealt with all the nits I found | 09:46 | |
| juergbi | I was planning to take at least another quick look | 09:47 |
| *** cs_shadow has joined #buildstream | 09:47 | |
| juergbi | however, wasn't the intent to merge it together with the CAS backend, i.e., when there are actual benefits? | 09:47 |
| gitlab-br-bot | buildstream: merge request (tpollard/386->master: widget.py: Limit failure summary to currently failing elements) #561 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/561 | 09:48 |
| Kinnison | I thought the intent was to merge this now so that any fallout can be seen sooner, while the CAS backend continues to be developed/cleaned up | 09:49 |
| jmac | I don't think the CAS backend provides any benefits either | 09:49 |
| jmac | I'm already spending significant time maintaining MRs since people are adding new work underneath it (e.g. export-to-tar) | 09:50 |
| * Kinnison nods | 09:51 | |
| * Kinnison thinks we should land 445 so that jmac is no longer on-hook for chasing those APIs at that level, and can focus on the next level up | 09:52 | |
| gitlab-br-bot | buildstream: merge request (chandan/sourcetransform->master: WIP: Allow source plugins to access previous sources) #568 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/568 | 09:53 |
| *** tiagogomes has joined #buildstream | 09:53 | |
| juergbi | ok, fine by me. I suppose that's acceptable now with the new policy, as long as we make sure the rest lands in time for 1.4 | 09:53 |
| jmac | When is the cut-off for 1.4? | 09:53 |
| tristan | Ok so... for myself I've tried to focus on a lot of master related stuff last week; but this week I really need to concentrate on the 1.2 branch | 09:53 |
| Kinnison | juergbi: the plan is surely to land it all as soon as we can :-) | 09:54 |
| juergbi | jmac: ~6 months | 09:54 |
| tristan | if juergbi is comfortable with this seemingly big complicated change on master, that is fine by me :) | 09:54 |
| juergbi | Kinnison: we normally want to avoid merging API additions/changes that haven't been properly validated yet by actual users/implementations | 09:55 |
| gitlab-br-bot | buildstream: merge request (valentindavid/498_bwrap_environment->master: Set environment in bwrap command line instead of its environment) #565 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/565 | 09:55 |
| Kinnison | juergbi: in this instance, all the users of the API have been updated though, and since the policy change so that master is considered "unstable" so long as the API is clean and ready by 1.4 we're okay, no? | 09:56 |
| toscalix | Hi jmac . I came across this issue https://gitlab.com/BuildStream/buildstream/issues/203 I wonder if, once reviewed, you guys plan to lan this fix in master before v1.2 release | 09:56 |
| Kinnison | juergbi: If you're strongly concerned, filing an issue to revisit the sandbox virtual directory API during the 1.3 cycle to ensure it's definitely what is wanted for 1.4 would be a sane approach | 09:56 |
| juergbi | Kinnison: the whole point of the API is to support the CAS backend, though. only validating the API with a local filesystem backend kind of misses the point | 09:56 |
| * Kinnison assumes toscalix has created a 1.4-blocker tag | 09:56 | |
| tlater | toscalix: Note that we aim to backport bugfixes anyway | 09:57 |
| jmac | toscalix: I merged that last week. It's Phil's issue. | 09:57 |
| tlater | I'd argue that one would be backported | 09:57 |
| Kinnison | juergbi: given the velocity of changes to master, I think it's unreasonable to expect the two MRs to land together | 09:57 |
| toscalix | jmac: thanks | 09:57 |
| juergbi | Kinnison: however, as the CAS backend already exists (in a different branch) and we're at the beginning of a new dev cycle, it should be fine to merge it already | 09:57 |
| gitlab-br-bot | buildstream: merge request (willsalmon/trackWarning->master: git.py: Add warning to git track if track and ref are not present) #580 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/580 | 09:58 |
| toscalix | Kinnison: the blocker label was created some time ago. We only use it for releases. It is not associated to a specific version but to the one is about to be released | 09:58 |
| gitlab-br-bot | buildstream: merge request (valentindavid/498_bwrap_environment->master: Set environment in bwrap command line instead of its environment) #565 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/565 | 09:58 |
| juergbi | I'll take another quick look at the MR and if we're missing something, we still have time to fix things up post merge, if needed | 09:58 |
| Kinnison | toscalix: given we have two versions in-train (1.2 and 1.4) it makes sense to have separate blocker tags, no? | 09:58 |
| tristan | toscalix, it's a good point though which Kinnison makes, it could make sense to start making one per release | 09:58 |
| tristan | toscalix, it falls under the category of "technical debt / deficit" which I meant to discuss | 09:59 |
| tristan | or, could be a good way for us to track those debts | 09:59 |
| toscalix | do you plan to have blockers simultaneously for v1.2 and v1.4 active? | 09:59 |
| tristan | Kinnison, basically we didnt come up with (yet) the exact strategy to track this sort of thing | 09:59 |
| gitlab-br-bot | buildstream: merge request (Qinusty/481->master: Add SKIPPED message type for actions being skipped) #562 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/562 | 10:00 |
| juergbi | maybe target milestone is good enough | 10:00 |
| * Kinnison nods tristan | 10:00 | |
| tristan | toscalix, Yes, we are currently landing things contingent on later work, those need a way to be identified, and blocking 1.4 from early on is one (pretty sane ?) way to do that | 10:00 |
| toscalix | blocker + milestone is not enough? | 10:00 |
| tristan | Ah, that could also work | 10:00 |
| tristan | Blocker tag with issue on milestone 1.4 | 10:01 |
| tristan | I'm pretty ambivalent which way, just so long as it works :D | 10:01 |
| toscalix | you can also use Urgent and the next milestone so we reserve blocker for release features or issues only | 10:01 |
| toscalix | with a comment on why is Urgent would be enough to understand why the ticket is there | 10:02 |
| tristan | toscalix, ideally both, I think that blocker sends the right message, though (the way we've currently been using that tag) | 10:02 |
| toscalix | I would recommend then to use the current label blocker, associated to the coming milestone, instead of creating new labels that are milestone specific | 10:04 |
| tristan | toscalix, Agree, I like this approach | 10:05 |
| * tristan now has also bought himself a good hour or two of triage work hehe | 10:05 | |
| * tristan puts on his TODO, find the existing issues filed so far of this nature, dress them appropriately with stones and miletags | 10:05 | |
| *** yar has joined #buildstream | 10:26 | |
| tlater | jjardon: Looks like we're running out of space on our runners: https://gitlab.com/BuildStream/buildstream-docker-images/-/jobs/84846081 | 10:27 |
| * tlater checks if clearing the cache helps | 10:27 | |
| gitlab-br-bot | buildstream: merge request (chandan/sourcetransform->master: WIP: Allow source plugins to access previous sources) #568 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/568 | 10:29 |
| gitlab-br-bot | buildstream: merge request (willsalmon/trackWarning->master: git.py: Add warning to git track if track and ref are not present) #580 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/580 | 10:33 |
| gitlab-br-bot | buildstream: merge request (phil/437-workspaces-tutorial->master: Phil/437 workspaces tutorial) #519 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/519 | 10:46 |
| tlater | toscalix: Btw, your issue template has two spaces in the tick boxes. I've seen a handful of people simply keep those tickboxes, but they don't render as actual tickboxes - think that's something we could fix?. | 10:49 |
| toscalix | ah, so the problem is the template. Will fix. Thanks | 10:50 |
| gitlab-br-bot | buildstream: merge request (tpollard/483->master: plugins/git.py: Fail if ref is not in given track) #564 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/564 | 10:51 |
| tlater | tpollard: Hey, would you mind rebasing your branch? https://gitlab.com/BuildStream/buildstream/merge_requests/561#9bb4742e68d4494087c183d5953c3f0feac0e101_528_527 | 10:55 |
| tlater | I'd do it for you, but I'd rather not muddy the author tags | 10:55 |
| tlater | Feel free to also set it to merge after the pipeline succeeds :) | 10:55 |
| tpollard | tlater: sure I can push a rebase | 10:55 |
| gitlab-br-bot | buildstream: merge request (chandan/sourcetransform->master: WIP: Allow source plugins to access previous sources) #568 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/568 | 10:56 |
| tpollard | tlater: I don't have merge powers yet though | 10:56 |
| tlater | Ah, right | 10:56 |
| * tlater fixes that | 10:56 | |
| tlater | Huh | 10:57 |
| tlater | You're just about the only person whose permissions I can't set | 10:57 |
| tlater | Odd | 10:57 |
| tlater | Perhaps because an owner gave you permissions in the first place? | 10:57 |
| tlater | Well, tell me when the rebase is up, I'll click the button for you. | 10:58 |
| gitlab-br-bot | buildstream: merge request (tpollard/386->master: widget.py: Limit failure summary to currently failing elements) #561 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/561 | 10:58 |
| tpollard | tlater: should be there now | 10:58 |
| gitlab-br-bot | buildstream: merge request (phil/436-add-ubuntu-install-intructions->master: Add Ubuntu install intructions) #525 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/525 | 10:59 |
| tristan | tlater, tpollard btw; I didn't start yet but I'm going to do another full pass over the permissions; because we made a bit of a mistake and need to fit within how gitlab works | 11:04 |
| tristan | Everyone that I made "Maintainer" so that they could get the commit bit for protected branches, will become "Developer" instead, and will be given explicit commit access to the protected branches | 11:05 |
| tlater | tristan: ooi, what does that buy us? | 11:05 |
| tlater | Does that mean gitlab keeps us from doing push-to-master manually? | 11:06 |
| tristan | This is because Maintainer also unlocks other sensitive settings which should not really be accessible to "Anyone we granted commit access" | 11:06 |
| tlater | Ah, things like changing CI I suppose | 11:06 |
| tristan | tlater, I don't believe it does that at all, no | 11:06 |
| tristan | exactly | 11:06 |
| qinusty | tristan, when working around the _yaml module, What is the provenance of a node? | 11:07 |
| tlater | Oh, that's a fun one :) | 11:07 |
| tristan | qinusty, it's the filename column and line info | 11:07 |
| tristan | qinusty, it can be formatted into a string for error messages/warnings, basically | 11:07 |
| tlater | tpollard: I feel there's something missing here https://gitlab.com/BuildStream/buildstream/merge_requests/564/diffs | 11:07 |
| qinusty | Okay cheers. | 11:08 |
| tlater | tpollard: You create that fancy assert_ref_in_track method but don't do anything with it | 11:08 |
| tpollard | tlater: yep there is, I just needed to update the branch for a remote machine. should I put WIP into the title whilst working on it? | 11:08 |
| tlater | Oh, yes please | 11:08 |
| gitlab-br-bot | buildstream: merge request (tpollard/483->master: WIP: plugins/git.py: Fail if ref is not in given track) #564 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/564 | 11:09 |
| tlater | Thanks :) | 11:09 |
| tpollard | np! | 11:09 |
| gitlab-br-bot | buildstream: merge request (phil/436-add-ubuntu-install-intructions->master: Add Ubuntu install intructions) #525 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/525 | 11:12 |
| tlater | Does the bst-external documentation live anywhere yet? | 11:12 |
| * tlater wonders who'd even know | 11:13 | |
| tlater | tristan? | 11:13 |
| tlater | Ah, it has a gitlab.io thing | 11:14 |
| tlater | But it's not consistent with the main repo theme | 11:14 |
| tlater | Hmm, I'll add an examples page for now. Do we want to link to this from the main doc? | 11:15 |
| tlater | Link for reference: https://buildstream.gitlab.io/buildstream/ | 11:15 |
| tristan | tlater, should be easy enough to port the theme changing commit | 11:15 |
| tlater | Yep, I'll give that a shot | 11:15 |
| tlater | Would you mind if I added a link to the external sources in the main doc, too? | 11:15 |
| tristan | tlater, we link to it already for the plugins section... if it's going to have an examples section we could follow that practice and link to it from the using page ? | 11:15 |
| tlater | Ah, alright | 11:16 |
| tlater | Yup, I'll do that :) | 11:16 |
| tlater | I'll also try sticking to the main repo's guidelines for examples | 11:16 |
| tlater | Going to be a bit harder to link to main docs, unfortunately. | 11:16 |
| tristan | unfortunately, there is a road to travel in order to share some of the things which the main repo does for CI and docs :-S | 11:17 |
| tristan | so for now, you might end up replicating some things from bst tests and docs | 11:17 |
| tristan | until a nicer surface can be defined for sharing | 11:17 |
| tlater | Yep, that's my aim for now. | 11:17 |
| tristan | cs_shadow, btw... I just wanted to point out, because it might not have been clear; I did reply to the proposal on the list about running tests | 11:29 |
| tristan | cs_shadow, i.e., because I left the most of the message body in tact, you might not have seen my inline comments; instead of sending another email, just wanted to ping you and let you know there was content in that reply :D | 11:30 |
| * paulsherwood wonders if bst is still following a model where odd releases are different from even ones | 11:44 | |
| gitlab-br-bot | buildstream: merge request (tpollard/386->master: widget.py: Limit failure summary to currently failing elements) #561 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/561 | 11:47 |
| Nexus | paulsherwood: Odd are unstable iirc | 11:54 |
| tristan | paulsherwood, Yes, even 1.0 & 1.2 is stable, 1.3 is the current dev cycle where we will make dev snapshot releases; which is work towards 1.4 | 11:56 |
| *** Caraway has joined #buildstream | 11:57 | |
| tristan | Alright, step one of permissions changes done: Maintainers can push, Only selected developers can merge | 11:57 |
| tristan | Next step, convert overzealously created "Maintainers" back to "Developers", but retaining the merge powers | 11:57 |
| tristan | tlater, so indeed; Developers are not allowed to push directly, but can merge (force through CI, not a bad thing I guess) | 11:58 |
| * tlater finds that better, personally | 11:58 | |
| tlater | But obviously keeping things like our docker deploy keys from everybody joining is probably the main incentive here. | 12:00 |
| tristan | Done | 12:01 |
| tristan | tlater, indeed | 12:01 |
| tristan | that's the reason for restructure | 12:01 |
| tristan | An option was to allow "developers" to push and lower the roles to "developer" | 12:01 |
| tristan | But, I want anyone who requests developer access to always receive it, cause it's a pain to setup your own CI and to do rebases of your fork with upstream | 12:02 |
| tristan | So we encourage any contributions to be through the main repo, just to reduce hassle | 12:02 |
| tlater | tristan: Do we have a note about this in the hacking file yet? | 12:02 |
| tlater | Something like "feel free to ask for dev access on #buildstream, setting up your own CI is a PITA"? | 12:02 |
| tristan | tlater, not as far as I can see, please feel free to add one ! | 12:03 |
| tristan | :) | 12:03 |
| tristan | I've also created a new "protect branch" thing which uses the "bst-*" wildcard, but we still need to maintain the "master" and "bst-*" protection lists separately | 12:04 |
| tristan | not too bad though all in all | 12:04 |
| tristan | and deleted the old explicit bst-1.0 and bst-1.2 protections | 12:04 |
| tristan | which should remain covered by bst-* | 12:05 |
| *** calcul0n has joined #buildstream | 12:07 | |
| mablanch | Oh great: "CI is a PITA, may I ask for developer access"? :) | 12:09 |
| mablanch | (hit Gitlab's "Request Access" like 5 minutes ago). | 12:09 |
| tlater | mablanch: Yes you may :) | 12:09 |
| cs_shadow | tristan: thanks! I saw your reply, need to write back | 12:09 |
| cs_shadow | Hopefully today | 12:09 |
| * tlater added mablanch, will now read up on the permission changes to make sure he did it right | 12:10 | |
| mablanch | tlater: Cheers! | 12:11 |
| tristan | cs_shadow, ah... no hurry ! hehehehe | 12:12 |
| tristan | cs_shadow, but good that you noticed, I noticed after sending that my inline replies were mostly out of view :) | 12:12 |
| tristan | mail sent regarding minor perm tweaking done today | 12:13 |
| tlater | mablanch: If you notice anything you don't have permissions to that you should, tell me - I don't seem to have access to the role permission settings, so I can't actually see what you're allowed to do now. | 12:14 |
| tristan | tlater, I don't think I do either | 12:14 |
| tristan | tlater, I think maybe you need to install the gitlab instance for control over the meaning of roles | 12:15 |
| tlater | Ahh, that would make sense | 12:15 |
| tlater | I'm used to the admin settings, so I was wondering where my menus went. | 12:15 |
| tristan | anyway, the developer role has not changed | 12:15 |
| tristan | it should allow you to push your own branches (please follow HACKING guidelines, and name them "username/branch-name" !) | 12:16 |
| tristan | and submit MRs directly upstream with those branches | 12:16 |
| gitlab-br-bot | buildstream: merge request (tlater/ask-for-dev-permissions->master: HACKING.rst: Add note about asking for dev permissions) #587 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/587 | 12:18 |
| gitlab-br-bot | buildstream: merge request (tlater/ask-for-dev-permissions->master: HACKING.rst: Add note about asking for dev permissions) #587 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/587 | 12:19 |
| tlater | Thanks tristan :) | 12:20 |
| gitlab-br-bot | buildstream: issue #527 ("local source plugin can introduce non-determinism") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/527 | 12:30 |
| tristan | jjardon, cs_shadow; the above https://gitlab.com/BuildStream/buildstream/issues/527 might be interesting to either of you :) | 12:31 |
| tristan | Interestingly I realized this because of discussion in https://gitlab.com/BuildStream/buildstream/merge_requests/581 | 12:31 |
| tristan | juergbi, do we have an issue to track the CAS regression of permission bits ? | 12:31 |
| tristan | I consider this to be quite high priority for the project | 12:31 |
| gitlab-br-bot | buildstream: merge request (willsalmon/trackWarning->master: git.py: Add warning to git track if track and ref are not present) #580 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/580 | 12:41 |
| WSalmon | I had tests-fedora-27 fail and then i just retried and it worked, is this a common thing? | 12:42 |
| Phil | WSalmon, yep it's a known issue | 12:43 |
| Phil | Off the top of my head it's #503 | 12:43 |
| WSalmon | thanks | 12:44 |
| tristan | tpollard, I see you landed the patch for !561, great ! | 12:49 |
| tristan | tpollard, now can you please post an MR with this patch to bst-1.2 please :D | 12:49 |
| tristan | Phil, I noticed you just landed the junctions things, which I meant to take a glance at; but anyway looks great | 12:53 |
| tristan | Phil, I'd like you to fix only one little thing... | 12:54 |
| gitlab-br-bot | buildstream: merge request (toscalix->master: removed space in task template so checkboxes work as expected) #588 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/588 | 12:54 |
| tristan | Phil, "literalinclude:: ../../examples/junctions/elements/callHello.bst" you are missing the annotation telling sphinx that this is YAML, and it's trying to render it as if it were python | 12:54 |
| tristan | see second yaml example here: http://buildstream.gitlab.io/buildstream/advanced-features/junction-elements.html#a-simple-example | 12:54 |
| tpollard | tristan: sure | 12:55 |
| tristan | tpollard, thanks, I'm still trying to work out how we can track the backporting of relevant bugfixes through gitlab | 12:55 |
| tristan | but essentially; if you have a bugfix for master, it also belongs on bst-1.2 (unless it fixes functionality that is only added in master) | 12:56 |
| Phil | thanks tristan. I'll do that this afternoon. | 12:58 |
| tristan | Phil, thanks ! | 12:58 |
| *** coldtom has joined #buildstream | 12:58 | |
| tristan | As for docs changes; new tutorials, etc; I don't feel like it's important to put a huge effort into backporting; because: (A) The docs list the since versions of every feature properly... (B) The docs are only ever published from master | 12:59 |
| tristan | But others might have different ideas about this | 13:00 |
| tristan | juergbi, ^^^ any thoughts on that ? | 13:00 |
| tristan | Its something that we aught to decide now for the cycle; we could "not backport every docs fix" for this cycle, and be more diligent the next cycle if it's more suitable | 13:01 |
| tristan | But for right now at least, backporting docs is not improving anyone's life; unless they happen to build the docs locally | 13:01 |
| *** tristan has quit IRC | 13:06 | |
| gitlab-br-bot | buildstream: merge request (tlater/ask-for-dev-permissions->master: HACKING.rst: Add note about asking for dev permissions) #587 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/587 | 13:11 |
| *** tristan has joined #buildstream | 13:17 | |
| jmac | Does anyone know why coverage reports 15% coverage for a class which cannot be instantiated? | 13:25 |
| tristan | jmac, because declaring the class itself, at import time is technically running code | 13:25 |
| tristan | i.e. the interpretor will cover parts of it simply by importing it | 13:26 |
| * tlater wonders if jmac means "why does it not give me 100%?) | 13:26 | |
| tlater | The answer to that would be: We're not using @abc | 13:26 |
| jmac | tlater: No, I don't, I expected 0% | 13:26 |
| tlater | Ah, right | 13:27 |
| jmac | So, for example, __init__ on my class is counted as 'covered' | 13:27 |
| tristan | jmac, do you instantiate a subclass and call super() ? | 13:27 |
| tlater | jmac: If you inherit from that class __init__ is considered covered, even if it is empty. | 13:27 |
| jmac | But that couldn't possibly have been actually run; how would the interpreter know the arguments? | 13:27 |
| tristan | that one seems like it shouldnt be covered by simply importing | 13:27 |
| jmac | No, there are no subclasses of this | 13:27 |
| tristan | But then, I don't know what it's doing; constructors could well be special for python | 13:28 |
| tristan | maybe the arguments are covered, but not the statements within the function body ? | 13:28 |
| tlater | Worth looking at what the project says. | 13:28 |
| tlater | pytest-cov, right? | 13:28 |
| tristan | tlater, pytest-cov is only the pytest plugin for it | 13:28 |
| tristan | tlater, the project is 'coverage.py' | 13:29 |
| jmac | Whatever runs at the end of our normal test suite | 13:29 |
| tlater | Ah, right. | 13:29 |
| tristan | tlater, jmac, the maintainer is usually active in #python on freenode too | 13:29 |
| * jmac takes a look at coverage.py | 13:29 | |
| * tlater should hang out on #python more | 13:29 | |
| tristan | tlater, it's a gamble, sift through the noise to find some signal; but I find it worthwhile at times | 13:30 |
| *** leopi has quit IRC | 13:30 | |
| *** dabukalam has joined #buildstream | 13:31 | |
| juergbi | tristan: as long as we only publish docs from master, I agree | 13:33 |
| juergbi | manpage improvements should still be backported, though | 13:34 |
| *** toscalix has quit IRC | 13:43 | |
| *** toscalix has joined #buildstream | 13:44 | |
| paulsherwood | regarding the odd vs even.. eventually the kernel maintainers dropped that, in favour of merge window + stabilisation => release | 13:55 |
| * paulsherwood wonders if that would be a better, less confusing model here | 13:56 | |
| Kinnison | Yeah, but I think GNOME continues with the approach | 13:56 |
| Kinnison | so it fits better with that | 13:56 |
| Kinnison | Also the kernel has a lot more people working on it | 13:56 |
| * paulsherwood doesn't like the odd/even approach... from a user pov it's unnecessary confusion | 13:56 | |
| * paulsherwood thinks it also leads to more 'backporting' but can't be sure | 13:57 | |
| Kinnison | Depends whether the goal is to have something stable people can rely on (1.2, 1.4, 1.6) or something which moves faster but is less easy to depend on | 13:58 |
| persia | The numbers have no impact on "backporting". | 13:58 |
| * Kinnison thinks that it's better to have reliable supportable releases which are few | 13:58 | |
| persia | Personally, I prefer odd/even to the use of .9 .99 .999, etc. to indicate prereleases. | 13:58 |
| Kinnison | Otherwise you end up dealing with a lot of users who refuse to move because they get confused | 13:58 |
| persia | Key is to have consistent branch naming and to have the model well described in docs. | 13:59 |
| tlater | Outside of gnome people just tag things beta- or dev-, that seems more clear to me personally. But it's not really an option to change this, or to go against gnome. | 14:00 |
| paulsherwood | sorry, but it is definitely an option to 'go against gnome' | 14:01 |
| paulsherwood | we need a model that works, not just 'the model that other gnome projects use' | 14:02 |
| Kinnison | Do we have anyone other than paulsherwood who was confused by the stable/unstable series thing? | 14:02 |
| Kinnison | If we hav a lot of confusion which appropriate docs don't resolve, then diverging from GNOME standard may be worthwhile | 14:03 |
| paulsherwood | as a *user* i need a release the works, it should be obvious what that is at all times. and i need to be assured that when i move to the next one, the project has me covered so i don't find things broken in the move | 14:03 |
| paulsherwood | s/release that works/ | 14:03 |
| Kinnison | AIUI that's the intent with the 1.2(.x?) series and then the jump to 1.4, 1.6, etc. | 14:03 |
| jmac | The "even == stable, odd == unstable" thing wasn't immediately obvious to me | 14:03 |
| tlater | Kinnison: I personally always assume that the latest version number is stable. | 14:03 |
| Kinnison | jmac: that's useful input, thanks | 14:04 |
| tlater | Or considered stable enough to be usable - I wouldn't think to look into the documentation to check this | 14:04 |
| Kinnison | tlater: I see. | 14:04 |
| Kinnison | I guess it's up to tristan and juergbi ultimately, but as persia says, so long as things are appropriately communicated I don't see an issue with the approach currently implemented | 14:04 |
| paulsherwood | flatmush: was it obvious to you which version to use when you started? | 14:05 |
| paulsherwood | noisecell: same question | 14:05 |
| paulsherwood | rdale: same question | 14:05 |
| *** toscalix has quit IRC | 14:05 | |
| Phil | I think the whole odd=unstable even=stable thing is only really intuitive if you're used to the Gnome ecosystem | 14:05 |
| * paulsherwood believes each of these people approcached bst separately | 14:05 | |
| *** toscalix has joined #buildstream | 14:06 | |
| * noisecell didn't know odd== unstable even==stable / I personally prefer that all releases are usable until the extend to now suffer regressions. | 14:06 | |
| Kinnison | Phil: It's possible that I've been around the F/LOSS community for long enough that it just seemed easy enough (then again I've dealt with almost every kind of stable/unstable mechanism used) | 14:06 |
| paulsherwood | Phil: sounds plausible... i wasn't aware of the convention at all | 14:06 |
| * Kinnison notes that *releases* will be stable | 14:06 | |
| * Kinnison wouldn't refer to 1.3.x as releases | 14:07 | |
| paulsherwood | that's just more confusion, then | 14:07 |
| Phil | Kinnison, why not? | 14:07 |
| paulsherwood | if you tag it, it's a release imo | 14:07 |
| jmac | Everything with a numbered version is a ... yep, that | 14:07 |
| Kinnison | If you tag it, it's a tag | 14:07 |
| Kinnison | As evidenced by a tag we had recently which blew up the test suite | 14:07 |
| noisecell | Kinnison, but we don't have a different naming convention for releases, though | 14:08 |
| Phil | How are you defining "a release"? | 14:08 |
| noisecell | as X.Y.Z are numbers, which can be releases and not releases? | 14:08 |
| tlater | Google & go name everything that has a version number a "release" - this breaks what us younglings are trained to consider versions | 14:08 |
| noisecell | if so, where is the document that tells me which is a release? | 14:08 |
| * Kinnison is, ultimately, not married to the current model. However I am of the opinion that not giving the current model a reasonable run before declaring it "confusing" might be a tad knee-jerk | 14:08 | |
| flatmush | paulsherwood: I've always been confused by projects that do the "odd == unstable" thing | 14:08 |
| rdale | paulsherwood: i just checked out the master branch of buildstream and used that when i started | 14:09 |
| flatmush | did not know buildstream also did that | 14:09 |
| * paulsherwood notes that Github expressly calls tags releases, so Kinnison is in the minority :) | 14:09 | |
| flatmush | releases should be stable | 14:09 |
| * Kinnison refuses to acknowledge "that place" as anything other than a mess | 14:09 | |
| Kinnison | noisecell: I'm completely on-board with the idea that documentation may be needed to be augmented | 14:10 |
| paulsherwood | Kinnison: let's not get off topic. the odd/even thing clearly confuses people, not just me | 14:10 |
| flatmush | the even odd thing is silly, even if someone reads the documentation it's easy to miss | 14:11 |
| paulsherwood | i'd really like the model to chang,e not just more doc for a bad model | 14:11 |
| Kinnison | paulsherwood: then you have a reasonable backing from which to argue for a change, I'd suggest you put something on the ML because the person who needs to make the decision is likely asleep by now. | 14:11 |
| jmac | It's the largest software development community; if you reject all their conventions then you're in the minority by default | 14:11 |
| flatmush | just do release candidates, or beta's or something that would be obvious without reading a document | 14:11 |
| paulsherwood | Kinnison: this is not a one person decision :) | 14:11 |
| Kinnison | jmac: I'm in a minority already for rejecting github/gitlab and writing my own Git server | 14:11 |
| paulsherwood | but yes, i'll raise on the ml | 14:11 |
| Kinnison | paulsherwood: True, you also need juergbi on board | 14:11 |
| juergbi | I can certainly see that people get confused if they are not used to it and/or it's not documented in the right places | 14:12 |
| juergbi | I think the model is common enough (especially in the GNOME community where it's ubiquitous) that it's not an issue with proper documentation | 14:14 |
| juergbi | I wouldn't be opposed to other version numbering but switching now could be confusing as well | 14:15 |
| juergbi | one thing worth mentioning is that the homepage/documentation currently recommends installing master (because 1.0 lacks features that projects need). I think the plan was/is to switch the documentation to recommend the latest stable branch | 14:16 |
| juergbi | which we actually could do now that 1.2 is branched off | 14:16 |
| juergbi | but that's definitely a question for tristan | 14:17 |
| noisecell | juergbi, are there any tag convention? as where buildstream has decided when to create a tag and what is the reason? | 14:19 |
| juergbi | noisecell: no hard rules for development snapshots/tags. for stable releases we have the target release date for x.0, aligned with GNOME, but for bug fix releases we release when we think it makes sense (after critical bug fix or users asking for it) | 14:25 |
| noisecell | juergbi, ok, thank you for the info | 14:28 |
| *** mohan43u has quit IRC | 14:28 | |
| *** mohan43u has joined #buildstream | 14:30 | |
| persia | As a historical note, the linux project decided to stop using even/odd a few years back because lots of folk found it too confusing. It used to be nearly everyone who did that, and now it is very rare. In the traffic that I notice, https://semver.org/ is exciting. | 14:30 |
| persia | That said, personally I like rcs and betas to be asciibetically sorted before releases, which requires a bit of gaming with semver. | 14:30 |
| * Kinnison notes that we can solve all of the confusion by simply not "releasing" until we're ready for what we'd call 1.4 under the current scheme | 14:33 | |
| Kinnison | i.e. the current release is 1.1.4 and the next will be 1.2 and then after that, we'll branch from master for a release when we're ready and call it 1.3 | 14:34 |
| Kinnison | The only thing we have to change is not tagging any point on master until the next release time | 14:34 |
| *** xjuan has joined #buildstream | 14:34 | |
| *** rdale has quit IRC | 14:38 | |
| juergbi | or appending -beta or something to all development snapshots | 14:40 |
| *** Phil has quit IRC | 14:41 | |
| *** Phil has joined #buildstream | 14:41 | |
| * noisecell nods | 14:42 | |
| *** rdale has joined #buildstream | 14:42 | |
| gitlab-br-bot | buildstream: issue #528 ("Which version of buildstream for new user?") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/528 | 14:42 |
| *** phildawson has joined #buildstream | 14:46 | |
| * paulsherwood sends email to the list | 14:52 | |
| gitlab-br-bot | buildstream: merge request (tpollard/483->master: WIP: plugins/git.py: Fail if ref is not in given track) #564 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/564 | 15:01 |
| * paulsherwood would prefer folks don't branch releases, at all | 15:03 | |
| paulsherwood | s/prefer/strongly prefer/ | 15:03 |
| juergbi | no stable branches? that's not really compatible with the recent change in commit policy, imo | 15:07 |
| paulsherwood | how come? | 15:09 |
| paulsherwood | last release = known good. at a pinch, a point release to fix crash/otherstopper on last release? | 15:10 |
| gitlab-br-bot | buildstream: merge request (tpollard/386-cherrypick->bst-1.2: widget.py: Limit failure summary to currently failing elements (#386)) #589 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/589 | 15:13 |
| tpollard | ^ tristan I hope that's what you requested | 15:13 |
| paulsherwood | /win 56 | 15:15 |
| paulsherwood | bah | 15:15 |
| juergbi | paulsherwood: if there is an important bug fix at a time when there is lots of flux in master, it's impossible to spin a bug fix release that is really safe to update without stable branches | 15:18 |
| gitlab-br-bot | buildstream: issue #529 ("Create a bazel build element") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/529 | 15:20 |
| juergbi | and this would also mean that you can't continuously accept feature merges as you most definitely want a stabilization period before a stable release, at least I'd want that | 15:20 |
| gitlab-br-bot | buildstream: merge request (mablanch/447-stack-trace-checkout->master: Handle checkout failure for unbuilt elements) #590 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/590 | 15:23 |
| *** edb has joined #buildstream | 15:24 | |
| *** dabukalam has quit IRC | 15:33 | |
| valentind | I have test tests/artifactcache/expiry.py::test_invalid_cache_quota[50%-True] that fails for me. Is that normal? | 15:35 |
| gitlab-br-bot | buildstream: issue #438 ("Migrate X86 image example from examples repo to main repo") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/438 | 15:35 |
| juergbi | valentind: tests shouldn't fail, no. it fails locally or in gitlab (buildstream mainline repo or other repo)? | 15:37 |
| juergbi | tlater: ^^ | 15:37 |
| valentind | It fails locally on master. | 15:37 |
| tlater | valentind: Do you have logs for that you could paste? | 15:38 |
| tlater | That one should certainly not fail | 15:38 |
| valentind | tlater, https://paste.gnome.org/p5jcm43tx | 15:39 |
| Nexus | tristan / juergbi: Is being able to run `bst build` without a target element, an intended feature? If not is there an existing issue for it? | 15:39 |
| valentind | tlater, I just have less than 50% available on my disk. | 15:40 |
| tlater | valentind: Yes, that looks pretty wrong | 15:41 |
| tlater | So... | 15:41 |
| tlater | Two things look wrong here | 15:41 |
| tlater | a) The test case should not consider actual system space | 15:42 |
| tlater | b) Damnit why does that fail | 15:42 |
| tlater | Oh, the failure is actually correct | 15:42 |
| tlater | valentind: You can safely ignore that exception for now, I'll create an issue about it | 15:42 |
| tlater | Mind if I link your log? | 15:42 |
| valentind | tlater, I only put it for 6 hours. So copy it. | 15:43 |
| gitlab-br-bot | buildstream: issue #438 ("Migrate X86 image example from examples repo to main repo") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/438 | 15:43 |
| tlater | Cool | 15:43 |
| gitlab-br-bot | buildstream: issue #438 ("Migrate X86 image example from examples repo to main repo") changed state ("closed") https://gitlab.com/BuildStream/buildstream/issues/438 | 15:43 |
| *** noisecell has quit IRC | 15:44 | |
| gitlab-br-bot | buildstream: merge request (valentindavid/331_include->master: Add support for include in project.conf) #471 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/471 | 15:45 |
| *** noisecell has joined #buildstream | 15:50 | |
| gitlab-br-bot | buildstream: issue #530 ("Cache quota size definition tests depend on the host system") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/530 | 15:56 |
| gitlab-br-bot | buildstream: merge request (valentindavid/331_include->master: Add support for include in project.conf) #471 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/471 | 15:56 |
| *** noisecell has quit IRC | 15:56 | |
| gitlab-br-bot | buildstream: merge request (tpollard/483->master: WIP: plugins/git.py: Fail if ref is not in given track) #564 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/564 | 15:56 |
| gitlab-br-bot | buildstream: merge request (valentindavid/331_include->master: WIP: Add support for include in project.conf) #471 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/471 | 15:59 |
| *** bochecha has quit IRC | 16:01 | |
| *** bochecha has joined #buildstream | 16:01 | |
| toscalix | paulsherwood: I haven't seen a rolling model with a stabilization phase done | 16:02 |
| toscalix | you need a stabilization phase when you do not control the deployment | 16:02 |
| toscalix | since deployments take time to stabilize as well | 16:03 |
| gitlab-br-bot | buildstream: merge request (jmac/cas_virtual_directory->jmac/googlecas_and_virtual_directories_2: WIP: CAS-backed virtual directory implementation) #481 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/481 | 16:03 |
| gitlab-br-bot | buildstream: merge request (jmac/cas_virtual_directory->jmac/virtual_directories: WIP: CAS-backed virtual directory implementation) #481 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/481 | 16:09 |
| qinusty | Can I disable linting with ./setup.py test ..... ? | 16:10 |
| jmac | Try: ./setup.py test --addopts "-k tests" | 16:10 |
| jmac | That should just run the actual tests and not pep8/pylint | 16:11 |
| qinusty | I though that, but it seems to still lint (I THINK). It takes quite a while to run a single test I just wrote which does barely anything | 16:11 |
| qinusty | and says "Using config file ..........buildstream/.pylintrc" | 16:12 |
| qinusty | Preceded by "Linting files" | 16:12 |
| gitlab-br-bot | buildstream: merge request (phil/fixup-junctions-tutorial->master: junction-elements.rst: Add missing language specifier to literalinclude) #591 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/591 | 16:12 |
| jmac | It's quite possible it does still run them but ignores the result. I know selective testing still has a long startup time for me. | 16:13 |
| *** finn has quit IRC | 16:13 | |
| *** edb has quit IRC | 16:14 | |
| *** finn has joined #buildstream | 16:14 | |
| qinusty | :/ | 16:14 |
| tlater | qinusty: Have you tried tests/**/*? | 16:16 |
| tlater | Alternatively `-m not pylint` is supposed to work | 16:17 |
| Kinnison | try "--no-pylint" in the addopts | 16:17 |
| gitlab-br-bot | buildstream: merge request (chandan/sourcetransform->master: WIP: Allow source plugins to access previous sources) #568 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/568 | 16:17 |
| Kinnison | since that worked for me when I had this pain | 16:17 |
| Kinnison | i.e ./setup.py test --addopts "--no-pylint" | 16:18 |
| tiagogomes | That looks something worth to add to the hacking guide | 16:18 |
| tlater | tiagogomes: +1 | 16:18 |
| qinusty | TIL: Individual tests can be ran by `./setup.py test --addopts "<path_to_module>::<test_function>` | 16:18 |
| qinusty | It runs INSTANTLY | 16:18 |
| tlater | qinusty: Yep :) | 16:19 |
| jmac | That's useful qinusty, thanks | 16:19 |
| qinusty | That'll save me so much time | 16:19 |
| qinusty | worth | 16:19 |
| * tlater thinks he explicitly documented this in the hacking, but perhaps not | 16:19 | |
| tlater | Worth reading closely :) | 16:19 |
| * phildawson didn't see it in hacking | 16:19 | |
| phildawson | but discovered it by accident | 16:20 |
| tlater | Yep, we'll have to add that then | 16:20 |
| * qinusty notices tlater did and sticks his head in the sand | 16:20 | |
| tlater | Ah, ok. phildawson fails the reading comprehension test ;) | 16:20 |
| * phildawson clearly isn't very good at reading :P | 16:20 | |
| phildawson | snap | 16:20 |
| * qinusty realises he was on pytest.org and decides to double check the hacking.rst | 16:21 | |
| tlater | qinusty: If these hints are not in there, mind adding them? | 16:21 |
| qinusty | Not on the hacking.rst, Head out of the sand. We should definitely add it then | 16:21 |
| qinusty | I'll put it on my TODO tlater :) | 16:21 |
| tlater | Thanks :) I put a lot of effort into trying to document testing quite closely, but iirc we started worrying about bloat. | 16:22 |
| qinusty | I agree, it is quite detailed on testing for CI etc. But while developing tests it is useful to quickly run a single test | 16:22 |
| qinusty | and since pytest doesn't work as a command due to the config file we have | 16:22 |
| qinusty | It's worth noting | 16:22 |
| gitlab-br-bot | buildstream: merge request (valentindavid/331_include->master: WIP: Add support for include in project.conf) #471 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/471 | 16:25 |
| * tlater would like to tweak the config so we can use pytest at some point | 16:28 | |
| *** noisecell has joined #buildstream | 16:35 | |
| *** leopi has joined #buildstream | 16:36 | |
| *** leopi has quit IRC | 16:39 | |
| *** noisecell has quit IRC | 16:39 | |
| gitlab-br-bot | buildstream: merge request (phil/fixup-junctions-tutorial->master: junction-elements.rst: Add missing language specifier to literalinclude) #591 changed state ("merged"): https://gitlab.com/BuildStream/buildstream/merge_requests/591 | 16:53 |
| *** finn has quit IRC | 17:02 | |
| *** finn has joined #buildstream | 17:02 | |
| *** finn has quit IRC | 17:02 | |
| *** jonathanmaw has joined #buildstream | 17:05 | |
| *** finn has joined #buildstream | 17:16 | |
| *** jonathanmaw_ has joined #buildstream | 17:19 | |
| *** jonathanmaw has quit IRC | 17:21 | |
| gitlab-br-bot | buildstream: merge request (tpollard/483->master: WIP: plugins/git.py: Fail if ref is not in given track) #564 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/564 | 17:26 |
| *** jonathanmaw_ has quit IRC | 17:31 | |
| gitlab-br-bot | buildstream: merge request (tpollard/483->master: WIP: plugins/git.py: Fail if ref is not in given track) #564 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/564 | 17:37 |
| *** edb has joined #buildstream | 17:56 | |
| *** toscalix has quit IRC | 18:44 | |
| *** ernestask has quit IRC | 18:50 | |
| *** xjuan has quit IRC | 19:07 | |
| *** toscalix has joined #buildstream | 19:14 | |
| *** toscalix has quit IRC | 19:15 | |
| *** xjuan has joined #buildstream | 19:20 | |
| *** tristan has quit IRC | 21:04 | |
| *** xjuan has quit IRC | 21:47 | |
| *** xjuan has joined #buildstream | 22:15 | |
| *** edb has quit IRC | 22:22 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!