| *** rdale has quit IRC | 00:46 | |
| *** tristan has quit IRC | 06:30 | |
| *** tristan has joined #buildstream | 06:54 | |
| *** ChanServ sets mode: +o tristan | 06:55 | |
| tristan | Looks like interactive tests which use pexpect are fairly consistently acting all wonky | 06:58 |
|---|---|---|
| tristan | https://gitlab.com/BuildStream/buildstream/-/jobs/523965539, https://gitlab.com/BuildStream/buildstream/-/jobs/523965536... | 06:58 |
| * tristan rebases and hopes last nights patches fixed this | 06:58 | |
| juergbi | tristan: we haven't increased the pexpect timeouts yet but should be trivial | 07:03 |
| juergbi | it's often the case that almost all the interactive tests fail or none, I guess depending on the runner VM load | 07:04 |
| juergbi | let me push this | 07:04 |
| gitlab-br-bot | juergbi opened MR !1884 (juerg/test-timeouts->master: Increase test timeouts) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/1884 | 07:12 |
| juergbi | tristan: ^^ | 07:12 |
| tristan | Ah I see | 07:16 |
| tristan | juergbi, are those milliseconds ? | 07:18 |
| tristan | 900 seconds timeout would seem like there is another underlying problem :-/ | 07:18 |
| gitlab-br-bot | tristanvb approved MR !1884 (juerg/test-timeouts->master: Increase test timeouts) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/1884 | 07:18 |
| juergbi | seconds but the 900 second limit is hit very rarely. the interactive tests mostly fail due to the 60 (in MR 300) second limit, or maybe the shorter 5 (in MR 30) second limit | 07:19 |
| juergbi | the 900 (or 1800 in MR) second limit is just to avoid having CI jobs hang indefinitely if there is an infinite loop or similar | 07:20 |
| juergbi | (well, until the CI job is killed but then you don't get the error details) | 07:20 |
| tristan | juergbi, yeah I don't have a problem with high value timeouts for CI, just I think that something is wrong with the CI if it legitimately takes that long :-S | 07:22 |
| juergbi | it would definitely be better if we could ensure fairer resource handling/scheduling to get less variance | 07:23 |
| juergbi | however, we'd need someone to really look into that. also not sure whether we keep the current runner infrastructure with the move to Apache | 07:24 |
| tristan | yeah, I hope whatever happens we stay with gitlab (wherever the instance is) | 07:25 |
| * juergbi too | 07:26 | |
| tristan | anyway yeah I guess it's plausible if we're throwing a lot of CI at the machines at the same time, that it can take 900 seconds (!) to respond to a simple prompt | 07:26 |
| juergbi | 900 was for a whole test, not for a single prompt | 07:26 |
| tristan | maybe some of the interactive tests simulate a failed build which takes a long time, but some of this is `bst init` | 07:26 |
| juergbi | single prompt was 60 seconds, in the MR now 300 | 07:26 |
| tristan | Ah | 07:27 |
| juergbi | for short actions such as bst init the timeout was 5 seconds, in the MR now 30 | 07:27 |
| tristan | is it that necessary to have such fine grained control ? | 07:27 |
| juergbi | if there is an I/O bottleneck, things can suddenly take a _lot_ longer on Linux | 07:27 |
| tristan | yeah, my text editor sometimes chokes on my obsessive compulsive saving while building a distro in the background | 07:28 |
| juergbi | well, you want to detect hangs at some point | 07:28 |
| WSalmon | i got lost in scroll back did tristan and cs-shadow come to a consensus on how to mange dependencies for bst-pluigns-* ? | 07:28 |
| tristan | WSalmon, in general cs-shadow seems to favor smaller, case specific images, and recommends installing things "on the fly", I'm not so comfortable with the second part, and for the first part I think the question is just about maintenance burden | 07:30 |
| tristan | if it's not a burden to have many small images then I don't really care... I wouldn't say consensus is reached but as he has been mostly maintaining that stuff, I would defer to him | 07:31 |
| tristan | I guess nothing prevents third party plugins from deriving our images and adding some tooling deterministically for the purposes of their CI | 07:32 |
| tristan | I don't think it makes sense for us to be maintaining things which fall out of scope of the plugins we do maintain | 07:32 |
| tristan | (just seems like a fair place to draw a line) | 07:33 |
| WSalmon | im asking cos i want to add git lfs to git_tag in bst-plugins-experimental and i need to add git-lfs | 07:33 |
| WSalmon | ok, all wait for cs-shaddow to be up and then ask him | 07:35 |
| tristan | I think this is a bit intertwined with the question of whether git_tag is an upstream plugin, which makes it a bit more sticky | 07:38 |
| tristan | experimental has been a dumping ground for plugins migrating out of buildstream and a fuzzy area for people to add stuff to possibly graduate at a later time | 07:39 |
| tristan | git_tag afaiu is an fdsdk thing | 07:39 |
| WSalmon | and gnome and crash | 07:44 |
| *** benschubert has joined #buildstream | 07:45 | |
| *** tpollard has joined #buildstream | 07:46 | |
| *** narispo has quit IRC | 07:47 | |
| *** narispo has joined #buildstream | 07:47 | |
| *** seanborg has joined #buildstream | 07:48 | |
| gitlab-br-bot | BenjaminSchubert approved MR !1884 (juerg/test-timeouts->master: Increase test timeouts) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/1884 | 07:51 |
| *** rdale has joined #buildstream | 08:01 | |
| *** phildawson has joined #buildstream | 08:15 | |
| * tristan was just looking at BST_PLUGIN_DEPRECATED and wondering what role it might have in the future | 08:23 | |
| tristan | I guess it's still relevant in a bst-2 world, but then I ran across this | 08:23 |
| tristan | "This deprecation warning may | 08:24 |
| tristan | be suppressed on a plugin by plugin basis by setting | 08:24 |
| tristan | ``suppress-deprecation-warnings: true`` in the relevent section of | 08:24 |
| tristan | the project's :ref:`plugin configuration overrides <project_overrides>`" | 08:24 |
| tristan | This appears weird, do we really have a sneaky special case in element declaration overrides which recognizes some special extra key ? | 08:24 |
| tristan | Or is this valid element/source declaration YAML too ? | 08:25 |
| tristan | eek, we do :-S | 08:27 |
| *** santi has joined #buildstream | 08:27 | |
| tristan | plugin.py reaches directly into the overrides for this, is there a reason we don't want to have it consistently as element/source declaration yaml ? (causing it to effectively be overridable in exactly the same way) | 08:29 |
| gitlab-br-bot | marge-bot123 merged MR !1884 (juerg/test-timeouts->master: Increase test timeouts) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/1884 | 08:35 |
| gitlab-br-bot | tristanvb opened issue #1291 (Suppressing deprecation warnings abuses element/source overrides) on buildstream https://gitlab.com/BuildStream/buildstream/-/issues/1291 | 08:45 |
| valentind | juergbi, OCI image on podman works. I did not get yet the docker image to work on docker. I have to find out why. | 09:01 |
| juergbi | valentind: thanks for testing, I think I see a bug in a docker-specific part | 09:05 |
| juergbi | let me quickly push a fix | 09:05 |
| juergbi | ah no, I misread the diff, nm | 09:05 |
| valentind | I think it was a bug on my distribution. I purged. A now I am upgrading my installation. | 09:06 |
| valentind | If that does not work, I will compare with the image produced by bst 1.4. | 09:06 |
| juergbi | ok | 09:07 |
| valentind | But I do not think the error was about the image. It loaded it correctly. It just cannot start the container. | 09:07 |
| juergbi | good news for me :) | 09:08 |
| tristan | juergbi, any thoughts on min-version so far ? I'm moving on to the plugin versioning stuff discussed with cs-shadow the other day | 09:09 |
| * tristan thinks it's time to prepare some groundwork in plugin origins too | 09:09 | |
| juergbi | tristan: overall I think it looks fine to me. I added one comment | 09:10 |
| tristan | there is a lot of data structure wrangling in there, I think I'd like to have LocalPluginOrigin and PipPluginOrigin | 09:11 |
| tristan | and then later introduce JunctionPluginOrigin | 09:11 |
| tristan | Ah thanks for the comment, I've been polling it ;-) | 09:12 |
| benschubert | tristan: around the 'junction' plugin origin, I hope to be able to send an email to the list today, still need some polishing before that though :) | 09:13 |
| tristan | benschubert, I'm not that close to jumping into that yet, so there is time :) | 09:16 |
| tristan | benschubert, does classing the origins and doing some delegation around the origins sound sensible to you ? | 09:16 |
| benschubert | not sure what you want to delegate ? But it seems generally sensible yes | 09:17 |
| tristan | benschubert, that might depend, but at least the parsing of the origin blocks and having proper objects there | 09:17 |
| benschubert | that sounds good to me | 09:18 |
| tristan | juergbi, def _adjust_version_for_release(major: int, minor: int) -> Tuple[int, int]: ? | 09:18 |
| tristan | I guess it's a bit wordy but explanatory enough | 09:18 |
| *** lachlan has joined #buildstream | 09:19 | |
| juergbi | tristan: I'd probably make it a wrapper around get_bst_version | 09:19 |
| juergbi | so no input required | 09:19 |
| juergbi | something like _get_api_version() | 09:19 |
| juergbi | _get_bst_format_version() | 09:20 |
| tristan | Ummm | 09:21 |
| tristan | Lemme see if that works everywhere | 09:21 |
| tristan | yeah that works everywhere | 09:23 |
| tristan | _get_bst_api_version() I think | 09:24 |
| juergbi | sounds fine to me | 09:24 |
| tristan | format_version is a thing of the past, and the release version pretty much works for both python and YAML APIs | 09:24 |
| tristan | There is another thing I will want but I'm not in a hurry | 09:25 |
| tristan | For instance, I would like to allow loading projects which say "min-version: 2.2", when utils.get_bst_version() reports (2, 1) | 09:25 |
| tristan | i.e. allow using the bleeding edge dev releases but specifying the next stable version | 09:26 |
| juergbi | yes, so it's good to have it in a separate function | 09:28 |
| juergbi | related to that, we may want to clarify whether we keep the odd=unstable convention for 2.x | 09:29 |
| juergbi | I think there has been some discussion about it a while ago | 09:29 |
| tristan | What is suggested as a replacement strategy for being able to make unstable development releases ? | 09:32 |
| tristan | Anyway, I don't really care as long as we have something that works | 09:33 |
| juergbi | tristan: I don't know whether there have been any concrete proposals. it could be .90+ as micro version. or -preX or -rcX suffices | 09:33 |
| *** narispo has quit IRC | 09:33 | |
| *** narispo has joined #buildstream | 09:33 | |
| juergbi | I'm also not saying we have to change, but it may make sense to revisit, also given the context of no longer being a GNOME project (where the current versioning is very common) | 09:34 |
| tristan | Sure, I'm certain that we will have people who want to use something in advance of release, and will want tags/releases for it | 09:34 |
| tristan | Changing it is tedious and requires updating both documentation and mechanics (e.g. how the badges work etc) | 09:35 |
| juergbi | I generally like the even/odd versioning, however, the issue is that it's not always obvious which projects follow it | 09:35 |
| juergbi | within the GNOME umbrella it's usually clear | 09:35 |
| tristan | So I would *prefer* not to change it, because it works well | 09:35 |
| tristan | it would seem silly to churn that stuff all over a matter of taste, but if people want to do the work... | 09:35 |
| tristan | I wouldnt complain ;-) | 09:36 |
| juergbi | yes, I personally don't have an issue with the current approach | 09:36 |
| juergbi | don't know whether Apache has a versioning policy | 09:36 |
| tristan | If I had to decide between .90+ ranges in micro points, and -preX, I would go for -preX | 09:37 |
| tristan | because that automatically addresses the feature I want: Ability to treat a development release as if it were the next minor point release | 09:37 |
| valentind | juergbi, It works. | 09:38 |
| valentind | Thank you. | 09:38 |
| tristan | if you install BuildStream 2.1.0-pre0 (first unstable dev release leading up towards 2.1.x), then you decided to opt-in, but your min-version can immediately be "2.1", so you need not churn once 2.1.0 proper is released. | 09:38 |
| juergbi | valentind: great, thanks for testing | 09:38 |
| * tristan hands min-version to marge after _get_bst_api_version() | 09:41 | |
| juergbi | apache httpd also follows the odd/even approach | 09:41 |
| benschubert | tristan: one thing is around python versioning, the usual scheme is "-devX", then "-aX", then "-bX" and then final release, which is embedded in pip (pip install --pre will get hte latest dev version). Not saying we should change for this but that's also a point to consider | 09:43 |
| valentind | I have noticed when switching to bst master, it complains about the version in .bst/workspaces.yml. But maybe it should recognize old empty version and upgrade them automatically. | 09:52 |
| tristan | valentind, I think we need to rename .bst/ -> .bst2/ ... rationale: https://gitlab.com/BuildStream/buildstream/-/issues/1266#note_328807147 | 09:53 |
| * tristan runs out for dinner | 09:53 | |
| benschubert | tristan: a clean checkout would also do the trick there no? Not sure what would be gained in adding that, except having people have to update their gitignores? Since workspace from bst1 and bst2 are not compatible anyways | 09:55 |
| *** tristan has quit IRC | 09:56 | |
| WSalmon | benschubert, ` bst1 and bst2 are not compatible anyways` is the issue tristan is trying to deal with | 09:58 |
| *** lachlan has quit IRC | 09:58 | |
| WSalmon | there was a lot of chatter on the issue to see how tristan came to this conclusion | 09:58 |
| benschubert | WSalmon: I know, and I read the issue, and my take is that people migrating will just clone the repo somewhere else, as it's probably simpler than having to switch back and forth :) | 09:59 |
| *** lachlan has joined #buildstream | 10:12 | |
| *** lachlan has quit IRC | 10:17 | |
| WSalmon | benschubert, im not sure that is the most user friendly approch | 10:31 |
| WSalmon | juergbi, do we have something that says what you can and can not imclude? https://paste.gnome.org/pqwdhurwm | 10:33 |
| *** lachlan has joined #buildstream | 10:34 | |
| juergbi | WSalmon: that paste doesn't exist | 10:37 |
| WSalmon | ah | 10:37 |
| WSalmon | i may have acidently done a 1hr one and then got distracted | 10:38 |
| WSalmon | 2 secs | 10:38 |
| WSalmon | juergbi, https://paste.gnome.org/po0aduv5e | 10:39 |
| WSalmon | dose that work? | 10:39 |
| WSalmon | the problem is that for the image the kind could be bsp spesific | 10:40 |
| abderrahim[m] | WSalmon: there are restrictions on files loaded from junctions | 10:41 |
| abderrahim[m] | (like the file should be valid before the junction is loaded) | 10:41 |
| abderrahim[m] | and it could be that you did something wrong, and it failed to produce an informative error message | 10:42 |
| WSalmon | juergbi, for our overlay examples we have diffrent plugins for different bsp's Im not sure how to do this with the includes? | 10:43 |
| WSalmon | abderrahim[m], indeed | 10:46 |
| juergbi | WSalmon: there is some early processing required for junction elements. which means that the loader has to know early on whether an element is a junction or not and thus, the `kind` needs to be known | 10:47 |
| juergbi | before include processing | 10:47 |
| juergbi | however, it may be possible to improve that | 10:47 |
| juergbi | e.g., maybe we could still allow 'kind' to be defined in includes for non-junction elements | 10:47 |
| juergbi | i.e., if kind is not defined, assume it's not junction | 10:47 |
| juergbi | (and if it turns out later it is one, error out) | 10:48 |
| abderrahim[m] | I think it's worth finding out exactly what's happening in this exact instance | 10:48 |
| juergbi | probably right before the junction check in _load_file_no_deps() | 10:49 |
| juergbi | valentind implemented the include handling, so he might have an opinion on my suggestion above | 10:50 |
| WSalmon | ill try and get this slightly tidier and push it and then juergbi and abderrahim[m] etc can poke them selves | 10:50 |
| juergbi | (I haven't thought about it in detail) | 10:50 |
| juergbi | WSalmon: btw: benschubert is planning to send a mail today to the list about loading plugins from junctions | 10:51 |
| juergbi | that could provide an alternative for your use case as well | 10:52 |
| juergbi | something like: kind: bsp.bst:image | 10:52 |
| *** tpollard has quit IRC | 10:58 | |
| valentind | So what if you have a dependency that goes through an element like a junction, but this element is not a junction. It should be the same error as if the element includes a junction. | 11:12 |
| valentind | I think if you have a test for that case, then it is fine. | 11:13 |
| valentind | So, have "foo.bst" depends on "bar.bst:baz.bst". Have "bar.bst" include "bar.yml". And "bar.yml" has kind "junction". You should get an error message that "bar.bst" is not a junction. | 11:15 |
| *** lachlan has quit IRC | 11:20 | |
| WSalmon | valentind, is it posible to do things like https://paste.gnome.org/p4vgsfyt0 | 11:36 |
| WSalmon | this seems to not want to work | 11:36 |
| WSalmon | oh hang on | 11:37 |
| WSalmon | i see it | 11:37 |
| valentind | Not in a list. | 11:37 |
| valentind | We do not support that. | 11:37 |
| valentind | You can however use (>) | 11:37 |
| valentind | In combination. | 11:37 |
| valentind | So make image-deps.yml have depends: ["your", "list"] | 11:38 |
| valentind | Then (@): image-deps.yml | 11:38 |
| valentind | And then depends: (>): ["other-element.bst"] | 11:38 |
| *** lachlan has joined #buildstream | 11:38 | |
| WSalmon | valentind, | 11:39 |
| WSalmon | [ {filename: bsp/raspi/boot.bst, | 11:40 |
| WSalmon | type: build} | 11:40 |
| WSalmon | { junction: freedesktop-sdk.bst, | 11:40 |
| WSalmon | filename: components/e2fsprogs.bst, | 11:40 |
| WSalmon | type: build} | 11:40 |
| WSalmon | ] | 11:40 |
| WSalmon | like that? | 11:40 |
| *** lachlan has quit IRC | 11:50 | |
| valentind | WSalmon, I am not sure what you meant. | 11:51 |
| valentind | WSalmon, https://paste.gnome.org/pbdcs3djs | 11:52 |
| WSalmon | ohhh | 11:53 |
| valentind | So we fixed our issue of UNAVAILABLE grpc error in freedesktop SDK. But now we have another issue. | 11:53 |
| WSalmon | that was not at all what i though tyou ment | 11:53 |
| WSalmon | ok | 11:53 |
| WSalmon | ill have a go | 11:53 |
| valentind | Pulls hang for ever. Or at least for longer than 24 hours. | 11:53 |
| *** CTtpollard has joined #buildstream | 12:36 | |
| *** tpollard has joined #buildstream | 13:01 | |
| *** CTtpollard has quit IRC | 13:01 | |
| *** lachlan has joined #buildstream | 13:22 | |
| benschubert | valentind: can you run with --debug and give the ~/.cache/buildstream/logs/_casd/* ? That should give us debug info from casd | 14:04 |
| benschubert | (Probably no need to run for 24 hours :) ) | 14:04 |
| *** phoenix has joined #buildstream | 14:06 | |
| valentind | benschubert, I think it might be the network being very slow. | 14:10 |
| valentind | I fixed something. And I will see if that helps. We have local cache server on the builders to fix the issue of slow network. That has worked. But I did not see recently that the disk space ran out, so the local cache pruned itself to leave room. | 14:11 |
| *** lachlan has quit IRC | 14:12 | |
| *** phoenix has quit IRC | 14:38 | |
| benschubert | ok! | 14:41 |
| *** hasebastian has joined #buildstream | 14:43 | |
| WSalmon | valentind, do you know why https://paste.gnome.org/piph1pcak the final line of this causes https://paste.gnome.org/ps3ud9t0h | 14:46 |
| WSalmon | which out the type: build then there is a issue cos the plugin dosnet like runtime deps, but buildstream is happy with the yaml | 14:46 |
| WSalmon | with out the `type: build` then there is a issue cos the plugin dosnet like runtime deps, but buildstream is happy with the yaml | 14:47 |
| traveltissues | benschubert: btw the deb source uses an import from tar | 14:50 |
| *** lachlan has joined #buildstream | 14:50 | |
| traveltissues | which was an issue i discovered when i tried to remove tar | 14:51 |
| benschubert | traveltissues: I know, that's also doing it in a way that we "technically do not support" | 14:51 |
| benschubert | I'd suggest rewriting the deb plugin | 14:51 |
| traveltissues | i agree | 14:51 |
| benschubert | it's saving too much locally and is not efficient | 14:51 |
| benschubert | and the mail around plugin elements has finally been sent | 14:52 |
| *** narispo has quit IRC | 14:55 | |
| *** narispo has joined #buildstream | 14:55 | |
| *** phildawson has quit IRC | 15:10 | |
| *** phildawson has joined #buildstream | 15:11 | |
| traveltissues | if anyone has some time i'd appreciate reviews on: https://gitlab.com/BuildStream/bst-plugins-experimental/-/merge_requests/91 | 15:12 |
| valentind | WSalmon, what is the content of bsp.bst:elements/deploy/image-deps.yml? | 15:15 |
| valentind | Does it contain "depends:"? If not, it should. | 15:15 |
| valentind | It should not be a list. | 15:15 |
| *** tristan has joined #buildstream | 15:16 | |
| *** mohan43u has quit IRC | 15:17 | |
| *** mohan43u has joined #buildstream | 15:17 | |
| *** hasebastian has quit IRC | 15:20 | |
| *** ChanServ sets mode: +o tristan | 15:20 | |
| tristan | benschubert, then I will have the 20.08 branch where I have to work with bst-1 for hotfixes/security patches, and the master branch with bst-2 | 15:21 |
| tristan | I think people will naturally want to work with the same checkout in general (but maybe only renaming the workspace file would achieve the same without updating any .gitignore files) | 15:22 |
| benschubert | tristan: I see, but in that case, correct me if I am wrong (I don't have this use case): would you be having workspaces opened on both? in the same project while changing branches? | 15:22 |
| tristan | There may be a good chance that I would, i.e. if I'm working on both, and workspaces is a feature, I very well might | 15:23 |
| tristan | Realistically, I might expect to use a workspace on a software module more in master | 15:23 |
| tristan | But in stable, I may very well use a workspace on the fdsdk junction from gnome-build-meta | 15:23 |
| * tristan actually mostly uses workspaces for junctions | 15:24 | |
| benschubert | however you would be closing and reopening your workspaces no? How would you keep them in sync if you were working in bst-1 only (taking a step back for a moment) | 15:24 |
| WSalmon | valentind, for now it lives https://gitlab.com/celduin/crash/bsp-playground/pi-3b-plus-bsp/-/blob/master/elements/deploy/image-deps.yml but will be moving | 15:24 |
| tristan | benschubert, thats a good point, if I were working with bst-1 only then I would indeed do that | 15:25 |
| WSalmon | valentind, https://gitlab.com/celduin/crash/bsp-playground/example-app/-/blob/master/elements/deploy/image.bst this worked | 15:25 |
| *** narispo has quit IRC | 15:25 | |
| valentind | WSalmon, Well that should have worked. | 15:25 |
| WSalmon | but dosent sort it out | 15:25 |
| *** narispo has joined #buildstream | 15:26 | |
| WSalmon | i couldnt work it out, dose that look like a bug? | 15:26 |
| benschubert | tristan: then if we had support to "reset" the workspace when moving from 1 to 2 (back we would not need to care). Or if we allowd the closing of the workspace without erroring, we would have the same kind of behavior right? | 15:26 |
| valentind | WSalmon, I think this is just a parse error before even treating (@) and (>) | 15:26 |
| valentind | But I do not see the issue here. | 15:26 |
| benschubert | I think the question is, "are they cases when you would change bst version while wanting to keep a workspace open" | 15:26 |
| *** mohan43u has quit IRC | 15:26 | |
| tristan | benschubert, I don't think we can have the "close a workspace without erroring" behavior easily | 15:27 |
| *** mohan43u has joined #buildstream | 15:27 | |
| benschubert | if there is none, we can just force the closing | 15:27 |
| valentind | WSalmon, Oh I see. | 15:27 |
| valentind | Look! | 15:27 |
| valentind | - deploy/filesystem.bst | 15:27 |
| valentind | type: build | 15:27 |
| tristan | For instance, closing a workspace means that BuildStream still needs to rewrite the workspaces.yml, so that all the other workspaces are preserved, in the format which BuildStream <version> understands | 15:28 |
| valentind | It should have "filename: " | 15:28 |
| benschubert | > all the other workspaces are preserved | 15:29 |
| benschubert | You would remove them too no? If would be an "all or nothing" | 15:29 |
| benschubert | Which means we could basically just remove the file? | 15:29 |
| benschubert | Or am I missing something? | 15:29 |
| tristan | benschubert, on the other hand, leaving the old file behind untouched (namespaced) is a nice way to say "Lets ignore this not very big issue, and if people keep their workspaces when they switch back and forth, good for them" | 15:29 |
| WSalmon | thanks valentind i have fallen for that a few times today | 15:29 |
| benschubert | which might lead to UX problems where "why is my workspace not used?" :) | 15:29 |
| tristan | Well, then you still have the command `bst workspace close` which now has a special case to recognize an old workspace file, and inform the user that you must use the --all option and close all workspaces ? | 15:30 |
| tristan | it seems like much ado about nothing to keep around in the codebase | 15:30 |
| benschubert | fair | 15:30 |
| tristan | over time, stale workspaces from bst-1 will just disappear | 15:30 |
| benschubert | and we could remove this in let's say 2.2/2.4? and error out brutally at that moment | 15:31 |
| benschubert | I agree with the "not having too much code to maintain" | 15:31 |
| tristan | if we just renamed it, we could just do nothing at all pretty much | 15:31 |
| tristan | if we removed it in 2.2/2.4, we still risk annoying any user we don't know about who might have a bst-1 project lying around | 15:32 |
| tristan | i.e. where "it" is a bunch of special case error messages | 15:32 |
| benschubert | I believe we'd still need to have some error message | 15:32 |
| tristan | Which ? | 15:32 |
| benschubert | because a user moving from 1 to 2 might not understand why his workspace is not used anymore | 15:32 |
| tristan | We could have a sentence in the porting guide which needs to be written | 15:33 |
| benschubert | That would be fine for the people that actively work on the switch for the project, but less involved users? | 15:33 |
| benschubert | if you think that's fine, then fine let's go with .bst/workspaces2.yml and nuke code :) | 15:33 |
| tristan | "Old workspaces will not be cleaned up", or we could have a warning message in permanence at startup "Detected old bst-1 workspaces which will be ignored" | 15:33 |
| benschubert | > if we removed it in 2.2/2.4, we still risk annoying any user we don't know about who might have a bst-1 project lying around | 15:34 |
| benschubert | 4:32 PM i.e. where "it" is a bunch of special case error messages | 15:34 |
| benschubert | Similar to that then? :) | 15:34 |
| benschubert | But again I am not working with bst 1 so I don't know everything and how this is handled so if you believe It's the easiest, let's go for that | 15:35 |
| tristan | Heh, I would be fine to just not have it honestly, but I think there is more special casing that is needed otherwise | 15:35 |
| benschubert | however let's not make it .bst2 :) | 15:35 |
| tristan | a single if [ -f .bst/workspaces.yml ]; then echo "Warn about it: Use bst-1 to clean it up if you want"; fi | 15:35 |
| tristan | yeah I agree .bst2/ is a bit more pervasive | 15:36 |
| *** cs-shadow has joined #buildstream | 15:37 | |
| *** lachlan has quit IRC | 15:39 | |
| *** phildawson has quit IRC | 15:44 | |
| *** phildawson has joined #buildstream | 15:44 | |
| *** tpollard has quit IRC | 16:08 | |
| *** lachlan has joined #buildstream | 16:17 | |
| *** lachlan has quit IRC | 16:30 | |
| gitlab-br-bot | tristanvb merged MR !1881 (tristan/min-version->master: Replace format-version with min-version) on buildstream https://gitlab.com/BuildStream/buildstream/-/merge_requests/1881 | 16:31 |
| *** jude has joined #buildstream | 16:44 | |
| *** santi has quit IRC | 16:50 | |
| *** lachlan has joined #buildstream | 17:01 | |
| *** santi has joined #buildstream | 17:02 | |
| *** jude has quit IRC | 17:05 | |
| *** santi has quit IRC | 17:05 | |
| *** lachlan has quit IRC | 17:14 | |
| *** rdale has quit IRC | 17:16 | |
| *** narispo has quit IRC | 17:29 | |
| *** narispo has joined #buildstream | 17:30 | |
| *** phildawson has quit IRC | 17:43 | |
| *** lachlan has joined #buildstream | 17:44 | |
| *** lachlan has quit IRC | 17:50 | |
| *** lachlan has joined #buildstream | 18:06 | |
| *** seanborg has quit IRC | 18:06 | |
| *** lachlan has quit IRC | 18:17 | |
| *** phoenix has joined #buildstream | 18:32 | |
| *** toscalix has joined #buildstream | 18:33 | |
| *** cs-shadow has quit IRC | 18:37 | |
| *** narispo has quit IRC | 18:56 | |
| *** narispo has joined #buildstream | 18:57 | |
| *** benschubert has quit IRC | 19:03 | |
| *** tpollard has joined #buildstream | 19:17 | |
| *** tpollard has quit IRC | 19:24 | |
| *** santi has joined #buildstream | 20:19 | |
| *** santi has quit IRC | 20:22 | |
| *** toscalix has quit IRC | 21:23 | |
| *** seanborg has joined #buildstream | 21:44 | |
| *** seanborg has quit IRC | 22:41 | |
| *** seanborg has joined #buildstream | 23:04 | |
| *** narispo has quit IRC | 23:04 | |
| *** narispo has joined #buildstream | 23:05 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!