| *** phoenix has quit IRC | 01:15 | |
| *** dftxbs3e has quit IRC | 03:33 | |
| *** dftxbs3e has joined #buildstream | 03:48 | |
| *** dftxbs3e has quit IRC | 03:48 | |
| *** dftxbs3e has joined #buildstream | 03:48 | |
| *** benschubert has quit IRC | 05:11 | |
| *** toscalix has joined #buildstream | 07:01 | |
| gitlab-br-bot | marge-bot123 merged MR !1451 (becky/tar_compression->master: Allowing `bst artifact checkout --tar` to use compression) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1451 | 07:38 |
|---|---|---|
| *** benschubert has joined #buildstream | 08:09 | |
| *** alexandrufazakas has joined #buildstream | 08:15 | |
| alexandrufazakas | tristan: Hey, I played around https://gitlab.com/BuildStream/buildstream/issues/178 yesterday a bit and left my thought there. I'd appreciate it if you could take a look whenever you've a moment | 08:20 |
| alexandrufazakas | s/thought/thoughts | 08:20 |
| benschubert | tristan, juergbi: do you have concerncs about moving parts of 'Element' to cython (cf https://gitlab.com/BuildStream/buildstream/merge_requests/1483/diffs ) ? I'm not speaking about public facing, but part of the internal API when it makes sense (some parts take >1-2% of the runtime in bst show and can be easy optimisations) | 08:28 |
| *** tristan has quit IRC | 08:31 | |
| *** tiagogomes has joined #buildstream | 08:34 | |
| *** mohan43u has quit IRC | 08:42 | |
| *** tristan has joined #buildstream | 08:45 | |
| *** jonathanmaw has joined #buildstream | 08:46 | |
| gitlab-br-bot | BenjaminSchubert opened MR !1485 (bschubert/fix-missing-variable-provenance->master: _variables: Fix reporting of missing variable) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1485 | 08:51 |
| *** ChanServ sets mode: +o tristan | 08:57 | |
| tristan | valentind, in #910, when you say "Have element c.bst that build-depends on a.bst. It installs a and chmod +x it" you mean... c.bst will do "cp /a /install-root/a && chmod +x /install-root/a" ? | 08:57 |
| gitlab-br-bot | Issue #910: Execution rights on an object can corrupt local cache https://gitlab.com/BuildStream/buildstream/issues/910 | 08:57 |
| tristan | valentind, Also is this basically a part of #38 ? | 08:58 |
| gitlab-br-bot | Issue #38: Lost file metadata in artifacts and images https://gitlab.com/BuildStream/buildstream/issues/38 | 08:58 |
| tristan | if so can we please mark it as such ? | 08:58 |
| juergbi | benschubert: it depends on how hard it makes the code to read with regards to having to switch between the Python and Cython files to follow the code logic | 08:58 |
| benschubert | juergbi: seems fair. Do you think the changes in the PR are good enough? | 08:59 |
| juergbi | i.e., for small helper functions I wouldn't be concerned at all. for core logic it might make sense to port more at once just to keep things together, if necessary | 08:59 |
| benschubert | (I'm biased, having written most of the Cython in the codebase as of now) | 08:59 |
| gitlab-br-bot | marge-bot123 merged MR !1484 (bschubert/api-improvements->master: node: Add 'get_str_list' on 'MappingNode') on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1484 | 08:59 |
| benschubert | agreed! | 08:59 |
| juergbi | benschubert: the PR is not for about Element class, though, right? | 09:00 |
| juergbi | or am I looking at the wrong MR? | 09:00 |
| benschubert | oups, right, it was utils | 09:00 |
| benschubert | I confused myself | 09:00 |
| juergbi | looks reasonable to me | 09:01 |
| valentind | tristan, It is much worts. | 09:02 |
| valentind | worse | 09:02 |
| tristan | valentind, Worse but related | 09:02 |
| tristan | valentind, I.e. this is "The CAS doesnt handle file attributes properly" territory | 09:03 |
| tristan | We should make sure to keep all of those related together and highly visible | 09:03 |
| valentind | Yes. But it break reproducibility. | 09:03 |
| *** phildawson_ has joined #buildstream | 09:03 | |
| tristan | valentind, That is a side effect of this particular issue about the cas not handling file attributes properly, yes | 09:04 |
| valentind | For #38 is that we do not deal with file attributes. This one is that we deal with one, but incorrectly. | 09:04 |
| gitlab-br-bot | Issue #38: Lost file metadata in artifacts and images https://gitlab.com/BuildStream/buildstream/issues/38 | 09:04 |
| valentind | An alternative would be to always use fuse. | 09:04 |
| tristan | valentind, Yes, I want all of those issues about file attributes not being handles properly related together, exactly | 09:04 |
| tristan | I know... this issue is about buildstream not doing something it claims to do | 09:05 |
| tristan | the other issues are buildstream not even claiming to do some things which are important | 09:05 |
| tristan | but still they should be related, they are all the same topic | 09:05 |
| tristan | valentind, However, there was a direct question I asked you above which you didn't answer yet | 09:06 |
| tristan | valentind, in #910, when you say "Have element c.bst that build-depends on a.bst. It installs a and chmod +x it" you mean... c.bst will do "cp /a /install-root/a && chmod +x /install-root/a" ? | 09:06 |
| gitlab-br-bot | Issue #910: Execution rights on an object can corrupt local cache https://gitlab.com/BuildStream/buildstream/issues/910 | 09:06 |
| tristan | ??? | 09:06 |
| valentind | tristan, Yes it means that. | 09:07 |
| valentind | It has to be the same content. | 09:07 |
| tristan | I mean, if that is *really* the case, that means things are broken beyond my wildest expectations | 09:07 |
| tristan | I see | 09:07 |
| tristan | right, so I understood it correctly | 09:07 |
| valentind | tristan, I have written the test in the merge request. | 09:07 |
| tristan | Looks like it was already related to #324 | 09:08 |
| gitlab-br-bot | Issue #324: Preserve hardlinks in artifacts https://gitlab.com/BuildStream/buildstream/issues/324 | 09:08 |
| tristan | Ooops no I'm looking at wrong issue | 09:10 |
| tristan | valentind, Sounds like this should be one of the the highest priority issues anyway, I'll give the MR a lookover in a few minutes | 09:12 |
| tristan | valentind, We probably need to also backport that the bst-1 branch | 09:12 |
| benschubert | Do we have a place for sharing types across the codebase? I'm thinking about an enum for 'CacheBuildTrees' but can't figure where it should live | 09:14 |
| Kinnison | types.py ? | 09:15 |
| gitlab-br-bot | BenjaminSchubert approved MR !1480 (juerg/platform->master: Store Platform reference in Context instance variable) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1480 | 09:16 |
| benschubert | Kinnison: types.py is technically public. So expose it as a private there? | 09:16 |
| benschubert | mmh that seems good, thanks :) | 09:16 |
| * Kinnison is sad we don't have `pub(crate)` | 09:17 | |
| tristan | valentind, Well maybe it's not *that* severe, while the idea is itself alarming this probably actually happens almost never right ? | 09:20 |
| valentind | When it happens, it is really puzzling. | 09:21 |
| tristan | weird, /me still confused as to what's happening, looks at patch | 09:21 |
| valentind | I think it does happen. But it is rare. | 09:21 |
| tristan | yeah, did it actually happen to you ? | 09:21 |
| valentind | I do not remember. | 09:21 |
| valentind | It is also difficult to see. | 09:22 |
| valentind | I do not remember how I found it. | 09:22 |
| valentind | It was a long time ago. | 09:22 |
| tristan | Ok so the exec bit is stored in metadata but linking it is the only problem | 09:28 |
| tristan | I see | 09:28 |
| *** lachlan has joined #buildstream | 09:28 | |
| tristan | And your patch avoids hardlinking executable files iiuc | 09:28 |
| valentind | It hardlinks executables together, and non executables together. It does that on the local cache. Not on remote server. | 09:30 |
| valentind | So there is still some hardlinks. But not when they do not have the same "executability". | 09:31 |
| tristan | Sounds sensible | 09:33 |
| tristan | But | 09:33 |
| tristan | Hmmm | 09:33 |
| juergbi | with casd coming up, we'll have to resolve this there, though... | 09:33 |
| tristan | Ok so it will still work with existing artifact caches | 09:33 |
| tristan | Doesnt change the storage format, just how we check out from it | 09:34 |
| valentind | No, I think you will need to pull again. | 09:34 |
| valentind | But for the cas server, it is not modified. | 09:34 |
| juergbi | it does change the local storage format but not the protocol | 09:34 |
| valentind | We could add support for copying files with the .exec suffix to support backward compatibility. | 09:35 |
| tristan | So if the metadata about executableness is stored in the detached directory information, why would the artifact server have to change ? | 09:36 |
| *** phoenix has joined #buildstream | 09:36 | |
| valentind | No, the server would not need to change. | 09:36 |
| valentind | It is only local cache that changes. | 09:36 |
| tristan | So we would need to zap local caches basically ? | 09:36 |
| valentind | Yes, only local cache. | 09:37 |
| tristan | after upgrading to a version of BuildStream with this fix, the local cache is invalidated by this | 09:37 |
| tristan | So we should be able to automate that in some way I guess | 09:37 |
| gitlab-br-bot | marge-bot123 merged MR !1483 (bschubert/optimize-downloadable-sources->master: Optimize downloadable sources) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1483 | 09:37 |
| tristan | Otherwise an upgrade blows up in your face | 09:38 |
| valentind | We could detect cases where the .exec object does not exist, but the non executable one does, in this case we just copy the file. | 09:38 |
| tristan | juergbi, As you say, once we use buildbox/casd locally, we will probably be able to get rid of all of this, and handle it differently right ? | 09:39 |
| juergbi | casd has the same issue right now | 09:40 |
| tristan | Oh | 09:40 |
| juergbi | I'm not really fond of merging this now before casd support, though | 09:40 |
| *** phoenix has quit IRC | 09:40 | |
| tristan | That was going to be my question | 09:40 |
| tristan | juergbi, is that work currently in flight ? | 09:40 |
| Kinnison | is it worth merging it to the 1.4 branch? | 09:40 |
| juergbi | yes | 09:40 |
| tristan | Kinnison, bst-1 - yes *definitely* | 09:40 |
| tristan | haha | 09:40 |
| juergbi | we should not merge it before it's also solved in master, though, imo | 09:41 |
| tristan | That I disagree, we're not backporting casd to bst-1 I think | 09:41 |
| juergbi | correct (afaict) | 09:41 |
| juergbi | however, merging bug fixes first to stable branch is generally a bad idea, imo | 09:41 |
| tristan | The fact that master has a problem which is waiting for a different kind of fix should not block us from fixing the issue in bst-1 | 09:42 |
| juergbi | assuming they are not urgently needed | 09:42 |
| tristan | I think this is pretty severe, it almost never happens but in the off chance that it does, it causes a maddening experience | 09:43 |
| juergbi | it leads to potential storage format conflicts when switching between versions | 09:43 |
| * tristan can imagine being the downstream user who ends up duplicating all of this research on their own, to find that it's a known issue upstream that they held back from fixing | 09:43 | |
| juergbi | I agree that we should fix it, but I'd like to avoid such diverging branches | 09:43 |
| * tristan imagines being pretty peeved with said upstream | 09:44 | |
| tristan | Yeah we have to consider how local CAS's are going to be compatible with eachother, that is the other bit | 09:44 |
| tristan | I don't know that it is reasonable to imagine that a BuildStream 2 local CAS will be sharable with BuildStream 1, although it seems desirable | 09:45 |
| tristan | Rather, the question should be: Are we prepared to commit to that compatibility ? | 09:45 |
| Kinnison | The roots are already non-shareable | 09:45 |
| Kinnison | so cache cleanup from one would potentially upset the other | 09:45 |
| juergbi | yes but also not conflicting | 09:45 |
| juergbi | that's true | 09:45 |
| tpollard | buildstream2 can't talk buildstream1 artifacts | 09:46 |
| tpollard | locally anyway | 09:46 |
| tristan | tpollard, Right but that's rather orthogonal I think | 09:47 |
| tristan | I mean the artifact format itself changing doesnt prevent the same cache from storing artifacts in multiple formats | 09:47 |
| tristan | (i.e. BST_ARTIFACT_VERSION if that is what we're talking about) | 09:48 |
| tristan | juergbi, If cleanup of BuildStream 1 and BuildStream 2 cannot play fair together, it's unreasonable to think that we could possibly share the same local cache for the separate BuildStream 1 and BuildStream 2 projects which we work on locally | 09:49 |
| tpollard | I don't see how it would work | 09:49 |
| juergbi | I agree | 09:49 |
| juergbi | that's already not working right now | 09:49 |
| tpollard | even if the content of the cache is the same (blob wise) bst2 needs protos to understand what it needs from it | 09:49 |
| tristan | tpollard, We might be talking apples and oranges regarding your "talk buildstream1 artifacts" statement | 09:49 |
| juergbi | (I assume we don't want to rearchitect cleaning in bst 1 to make it compatible somehow) | 09:50 |
| tristan | tpollard, I was assuming you are talking about the format of an artifact (which is revisioned by the artifact version) | 09:50 |
| tristan | juergbi, I don't really feel like that is worthwhile | 09:50 |
| juergbi | agreed | 09:50 |
| tristan | By default anyway, we should just have a separate default config file when builstream 2 hits the pavement | 09:51 |
| tristan | Which uses a different directory by default | 09:51 |
| tristan | Which is in my (currently abandoned) set of patches to make BuildStream 2 safely parallel installable | 09:51 |
| tristan | Which I probably have to revive soon | 09:51 |
| tristan | juergbi, Policy wise about fixing issues in master first; I agree in general that we should do that in practice, but not in the case that we can fix a fairly severe issue for users and we are intentionally holding off in master | 09:53 |
| tristan | So I would much rather move forward with fixing this in bst 1 | 09:53 |
| tristan | When I find issues in the field, I usually fix both, but this is a special case where master wants a different fix that is blocking on something else | 09:54 |
| juergbi | up to you. I don't think this is actually hitting users as the worst case is an unneeded executable bit, which I wouldn't expect to be a real issue in many situations. we should definitely fix it for deterministic results | 09:56 |
| juergbi | however, I might be missing a use case where it has real impact, so maybe it's safer to merge it to bst-1 | 09:56 |
| tristan | juergbi, Right, I just don't think we should be holding back in the case where the fix in master is (A) Not going to be packportable/applicable to bst-1 anyway... (B) Being held back in master pending other work | 10:09 |
| tristan | The severity of the issue is not as relevant, but we have someone providing a patch now, it doesnt usually mean that after postponing something, we'll still have someone providing a patch later too | 10:10 |
| tristan | in most cases, we just fix both even if the fix differs | 10:11 |
| gitlab-br-bot | marge-bot123 merged MR !1485 (bschubert/fix-missing-variable-provenance->master: _variables: Fix reporting of missing variable) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1485 | 10:13 |
| *** lachlan has quit IRC | 10:18 | |
| alexandrufazakas | Can anyone have a look at #178 and help me out a bit to see how we should be moving forward | 10:31 |
| gitlab-br-bot | Issue #178: Publish documentation for each stable branch + current development (master) https://gitlab.com/BuildStream/buildstream/issues/178 | 10:31 |
| *** lachlan has joined #buildstream | 10:33 | |
| gitlab-br-bot | beckyella16 opened MR !1486 (becky/fix_comand_typos->master: Fixing typos: comand corrected to command) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1486 | 10:56 |
| gitlab-br-bot | marge-bot123 merged MR !1480 (juerg/platform->master: Store Platform reference in Context instance variable) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1480 | 11:10 |
| *** lachlan has quit IRC | 11:11 | |
| gitlab-br-bot | tpollard approved MR !1486 (becky/fix_comand_typos->master: Fixing typos: comand corrected to command) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1486 | 11:11 |
| *** lachlan has joined #buildstream | 11:15 | |
| gitlab-br-bot | BenjaminSchubert opened MR !1487 (bschubert/node-enum->master: Add a 'as_enum' on Scalar nodes to help with constraining inputs) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1487 | 11:21 |
| benschubert | ^ tristan about our enum converstation. Is that what you had in mind? | 11:21 |
| *** lachlan has quit IRC | 11:22 | |
| tristan | benschubert, I had envisioned it slightly differently but this does look quite perfect yes :) | 11:25 |
| benschubert | perfect, then let's wait for review and merge this :) thanks! | 11:26 |
| tristan | benschubert, Specifically, I thought maybe we'd define the enums as `class Foo(Enum)`... with values like: Foo.bar = 1, Foo.baz = 2, ... etc | 11:26 |
| benschubert | ah, we can also do that | 11:26 |
| tristan | benschubert, And I would have used the class attributes | 11:26 |
| tristan | to validate | 11:26 |
| tristan | I mean, either way works | 11:26 |
| benschubert | we do define the values with `class Foo(Enum)` though, I might not be understanding the first comment :) | 11:27 |
| benschubert | and for validation, the class attributes are used: https://gitlab.com/BuildStream/buildstream/merge_requests/1487/diffs#07d9c39a4dd185288aca40f51ca581d0fa109c69_326_336 | 11:28 |
| tristan | Right, well you define them as `class Foo(str, Enum)`, and insist that enum values must be strings | 11:28 |
| benschubert | (slightly hidden in that case, but we retrieve the enum value as a return so that's a win) | 11:28 |
| benschubert | tristan: ah, they don't need to | 11:28 |
| benschubert | an IntEnum or plain Enum would work | 11:28 |
| tristan | benschubert, Oh so my understanding is that the scalar string value right now needs to be the *value* of the enum member | 11:29 |
| tristan | benschubert, I would have just used the *name* of the enum member | 11:29 |
| benschubert | ah that's correct | 11:29 |
| tristan | I mean, what looks better when writing code ? | 11:30 |
| benschubert | we do use capitables for names, so we would either need to use lowercase or break all configs | 11:30 |
| tristan | Right, we would have to use lower case indeed | 11:30 |
| tristan | I mean, maybe this way is also nicer | 11:30 |
| tristan | The way you have it now | 11:30 |
| tristan | benschubert, I'm a bit ambivalent on this point but we should choose the easier to use, more intuitive to understand API, whichever that is | 11:31 |
| tristan | Maybe lets go with your approach but... lets add an example to the as_enum() API docs | 11:31 |
| tristan | Showing how the enum must be specified | 11:32 |
| tristan | err, declared I mean | 11:32 |
| benschubert | Good point, I'll add this in the docs after food :) | 11:32 |
| *** lachlan has joined #buildstream | 11:43 | |
| lachlan | Hi, I'm working on benchmarking buildstream and I'm currently getting a fall over in tests due to a Cython compilation error: https://gitlab.com/BuildStream/benchmarks/-/jobs/253016814 | 11:52 |
| juergbi | lachlan: this was a bug in that particular commit. was fixed in the meantime but you probably can't benchmark this commit without applying a patch | 11:56 |
| gitlab-br-bot | marge-bot123 merged MR !1486 (becky/fix_comand_typos->master: Fixing typos: comand corrected to command) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1486 | 11:57 |
| juergbi | fixed by f48d173461aa1bc729474a996f81f218728bb18b afaict | 11:57 |
| lachlan | juergbi: Yes, unfortunately we test every single patch individually and this one causes the whole process to fall-over. I'm looking at putting protective catches in to skip it. | 11:59 |
| juergbi | while we aim for every commit to pass the test suite, we don't currently check/enforce this in CI, so there will likely be such exceptions | 12:00 |
| gitlab-br-bot | AlexFazakas opened MR !1488 (alexfazakas/fix-frontend-typo->master: app: Fix "earily" typo) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1488 | 12:18 |
| *** phil has joined #buildstream | 12:25 | |
| *** phildawson_ has quit IRC | 12:26 | |
| *** tristan has quit IRC | 12:40 | |
| gitlab-br-bot | cs-shadow opened issue #1083 (source checkout fails when parent directory is not writable) on buildstream https://gitlab.com/BuildStream/buildstream/issues/1083 | 12:53 |
| *** tristan has joined #buildstream | 13:06 | |
| *** phil has quit IRC | 13:34 | |
| *** dftxbs3e has quit IRC | 14:08 | |
| *** phil has joined #buildstream | 14:19 | |
| *** ChanServ sets mode: +o tristan | 14:32 | |
| tristan | eek, we never fixed this https://gitlab.com/BuildStream/buildstream/issues/525 ? | 14:32 |
| tristan | Strange, I'll see if I can nail it this week then | 14:33 |
| benschubert | tristan: I've got trouble finding in the code where we do https://gitlab.com/BuildStream/buildstream/merge_requests/1487#note_192839865 actually, do you know? | 14:33 |
| gitlab-br-bot | tristanvb opened issue #1084 (stack trace with python 3.7 when exiting client with `^C`) on buildstream https://gitlab.com/BuildStream/buildstream/issues/1084 | 14:36 |
| tristan | benschubert, dependency types ? | 14:38 |
| tristan | benschubert, it appears you've cythonized that :) | 14:38 |
| tristan | benschubert, in _loader/types.pyx | 14:39 |
| * tristan notices that `all` is now allowed as a value (same as not specifying `type`), but https://buildstream.gitlab.io/buildstream/format_declaring.html#format-dependencies-types has not been updated to reflect that | 14:41 | |
| benschubert | ah right, I will not move this to an enum. Enum have a penalty cost that can be huge (1-2 orders of magnitudes) when accessing values. For everything that is performance critical I would not do that :) | 14:44 |
| Kinnison | benschubert: you're kidding? | 14:45 |
| benschubert | Kinnison: not at all | 14:45 |
| * Kinnison sobs | 14:46 | |
| benschubert | just made an experiment by moving 'Consistency' to an Enum, and I saw a 2s penalty, on something of the size of base-files | 14:46 |
| benschubert | JUST to access its content | 14:46 |
| Kinnison | All my design intuitions are utterly fubar when we get to microoptimising python :( | 14:47 |
| cs-shadow | so.. who wants to rewrite the enum module? ;) | 14:47 |
| benschubert | for me, python optimisation is half black magic, half sweat and tears :) | 14:47 |
| alexandrufazakas | hey tristan, do you have some time to discuss #178? | 14:47 |
| gitlab-br-bot | Issue #178: Publish documentation for each stable branch + current development (master) https://gitlab.com/BuildStream/buildstream/issues/178 | 14:47 |
| tristan | alexandrufazakas, Ah sorry I didnt get around to you today :-/ | 14:51 |
| tristan | I think not... do you have some questions ? | 14:51 |
| alexandrufazakas | tristan: It's alright | 14:52 |
| alexandrufazakas | Most of them I left as a comment on the issue itself | 14:52 |
| alexandrufazakas | So you can have a look when you've some spare time | 14:52 |
| tristan | alexandrufazakas, Looks like you have something decent already though ! | 14:56 |
| tristan | alexandrufazakas, fwiw, having to maintain a json file or something listing the releases could be alright, we already have to update another thing on the website after each release (we add a link to the release announcement, which can't really be automated) | 14:57 |
| alexandrufazakas | tristan: Hah thanks. It's gotten a bit better today | 14:57 |
| alexandrufazakas | tristan: Hmm, so keeping these "master: URL", "1.2.8: URL" etc mappings in a json file? | 14:58 |
| tristan | I'm trying to load it but, we have a release checklist at https://gitlab.com/BuildStream/buildstream/blob/master/CONTRIBUTING.rst, so we'd want to update that | 14:59 |
| tristan | alexandrufazakas, yeah well, that could be fine yeah, but I think we can manage to introspect this right ? | 15:00 |
| tristan | Having a 'master' link is also good of course | 15:00 |
| alexandrufazakas | tristan: oh, yeah, I see the "Making releases" section | 15:01 |
| tristan | alexandrufazakas, did you look at https://gitlab.com/BuildStream/buildstream/blob/master/doc/badges.py#L96 ? | 15:01 |
| tristan | It should really be easy to use that to automatically list all minor points and find the latest micro point for each minor point | 15:01 |
| alexandrufazakas | tristan: I only looked at it a bit, wasn't sure where to go from there | 15:02 |
| tristan | But, I don't know how that relates to looking up artifacts in gitlab | 15:02 |
| alexandrufazakas | Yeah, that's the thing | 15:02 |
| tristan | Like, with that script you can find out all the versions and choose the latest of each minor point | 15:02 |
| alexandrufazakas | We still need to fetch the documentatino somehow | 15:02 |
| tristan | I dont know about the other parts | 15:02 |
| tristan | I would think though, there should be a gitlab automatic url for a tag | 15:02 |
| tristan | (honestly don't know, though) | 15:03 |
| tristan | if it can be automated, that is of course much desirable | 15:03 |
| tristan | but if it needs to be on the checklist we can surely do that, it's not an onerous affair | 15:03 |
| alexandrufazakas | I see | 15:04 |
| alexandrufazakas | So that script should help me with getting the tags, basically, right? tristan | 15:04 |
| tristan | that script would let you get the list of "release tags" (as opposed to any other tags) yeah | 15:05 |
| tristan | it's certainly a good starting point to "find the latest micro point for each minor point" | 15:05 |
| alexandrufazakas | Right, that's what I meant. Sorry, not very used to the terminology | 15:05 |
| alexandrufazakas | Speaking of terminologi, not sure what micro points and minor points are. Micro's would be 1.2.8, 1.2.7, 1.2.6 etc and the latest (which is the one we're interested in) is 1.2.8? | 15:06 |
| tristan | Also, you could just ignore odd minor points | 15:06 |
| tristan | But | 15:06 |
| tristan | alexandrufazakas, I think we probably want to include odd minor points too - or at least the biggest ones | 15:06 |
| tristan | odd minor points reflect development snapshots / unstable | 15:07 |
| alexandrufazakas | So 1.3.* for instance | 15:07 |
| tristan | alexandrufazakas, {major}.{minor}.{micro} | 15:07 |
| *** bochecha_ has joined #buildstream | 15:08 | |
| tristan | alexandrufazakas, major point version bumps reflect incompatible API changes, minor point version bumps indicate API additions, micro point bumps (micro is also referred to as "patch" sometimes) indicate bug fixes which do not change the API at all | 15:09 |
| tristan | alexandrufazakas, https://semver.org/ | 15:09 |
| alexandrufazakas | Oh, alright, that makes sense | 15:10 |
| *** bochecha has quit IRC | 15:10 | |
| *** bochecha_ is now known as bochecha | 15:10 | |
| tristan | alexandrufazakas, in buildstream, we use semantic version and in addition, we indicate stable releases with even minor points... so 1.3.x will be allowed to change and not declared stable until this summer when it becomes 1.4.x stable (which will be completely backwards compatible with 1.2) | 15:10 |
| tristan | alexandrufazakas, When we start making dev snapshots of BuildStream 2, we'll use the 1.91.x range (using an odd minor point) | 15:11 |
| tristan | So badges in the docs and stuff should still work with that | 15:11 |
| alexandrufazakas | BuildStream 2? | 15:12 |
| alexandrufazakas | Being 1.2.*? | 15:13 |
| tristan | Uh ? | 15:13 |
| alexandrufazakas | tristan: I just wasn't sure what buildstream 2 means | 15:14 |
| alexandrufazakas | What does the version sound like | 15:14 |
| alexandrufazakas | I think I understand that python script btw | 15:14 |
| tristan | alexandrufazakas, Ok so... right now most folks are working on BuildStream 2 | 15:14 |
| tristan | It will be incompatible with BuildStream 1, so it will be a major point version bump | 15:15 |
| alexandrufazakas | Oh, okay | 15:16 |
| tristan | don't worry about that anyway | 15:16 |
| alexandrufazakas | So it's 2.something.something | 15:16 |
| tristan | right, but before 2.0.0 there will be snapshots of it released as 1.91.x | 15:16 |
| tristan | snapshots | 15:16 |
| alexandrufazakas | I understand | 15:16 |
| * tristan gotta run now... | 15:16 | |
| alexandrufazakas | tristan: So what I should try to do now is see fi I can automate this documentation fetching | 15:17 |
| alexandrufazakas | tristan: Okay, sorry, we can discuss this tomorrow if you have the time | 15:17 |
| *** tristan has quit IRC | 15:19 | |
| *** bochecha_ has joined #buildstream | 15:36 | |
| *** bochecha has quit IRC | 15:38 | |
| *** bochecha_ is now known as bochecha | 15:38 | |
| *** tristan has joined #buildstream | 15:45 | |
| *** lachlan has quit IRC | 15:51 | |
| *** lachlan has joined #buildstream | 15:55 | |
| gitlab-br-bot | tpollard opened MR !1489 (tpollard/loaderror->master: _exceptions.py: Align LoadError() parameter ordering) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1489 | 16:01 |
| *** alexandrufazakas has quit IRC | 16:28 | |
| *** toscalix has quit IRC | 16:32 | |
| *** bochecha has quit IRC | 16:37 | |
| *** jonathanmaw has quit IRC | 17:04 | |
| *** dftxbs3e has joined #buildstream | 17:07 | |
| *** dftxbs3e has joined #buildstream | 17:07 | |
| *** phil has quit IRC | 17:23 | |
| *** lachlan has quit IRC | 17:25 | |
| *** bochecha has joined #buildstream | 17:28 | |
| *** lachlan has joined #buildstream | 17:31 | |
| valentind | Will we rename buildstream module to buildstream2 so we can have both versions installed? | 18:05 |
| Kinnison | I think the intent is to recommend venvs | 18:38 |
| *** phoenix has joined #buildstream | 18:56 | |
| *** xjuan has joined #buildstream | 18:59 | |
| *** lachlan has quit IRC | 19:10 | |
| *** lachlan has joined #buildstream | 19:26 | |
| *** xjuan has quit IRC | 19:35 | |
| *** lachlan has quit IRC | 20:24 | |
| *** tiagogomes has quit IRC | 22:11 | |
| *** tiagogomes has joined #buildstream | 22:11 | |
| *** bochecha has quit IRC | 22:44 | |
| *** ironfoot has quit IRC | 22:56 | |
| *** ironfoot has joined #buildstream | 22:56 | |
| *** ChanServ sets mode: +o ironfoot | 22:56 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!