| *** mohan43u has quit IRC | 05:22 | |
| *** mohan43u has joined #buildstream | 05:31 | |
| laurence | where's the best place to get a 'mission statement' about BuildStream? Or something that outlines it's stand-out features, explaining why someone should use it? | 06:46 |
|---|---|---|
| laurence | If we don't have one, I can write one over the next week | 06:47 |
| gitlab-br-bot | marge-bot123 merged MR !1429 (willsalmon/platformRefactor->master: Refactor Platform and Sandboxes) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1429 | 07:29 |
| Kinnison | I thought that the elevator pitch was on buildstream.build | 07:41 |
| gitlab-br-bot | marge-bot123 merged MR !1389 (tristan/exit-on-nonblock-terminal-1.2->bst-1.2: _frontend/cli.py: Exit with error if output streams are set to nonblocking) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1389 | 08:01 |
| *** alexandrufazakas has joined #buildstream | 08:13 | |
| *** traveltissues has joined #buildstream | 08:27 | |
| *** bochecha has joined #buildstream | 08:41 | |
| tristan | laurence, I think this is the best we have in terms of what you're looking for: https://docs.buildstream.build/main_about.html | 09:03 |
| tristan | still | 09:03 |
| *** jonathanmaw has joined #buildstream | 09:04 | |
| *** tristan has quit IRC | 09:11 | |
| *** traveltissues has quit IRC | 09:13 | |
| *** traveltissues has joined #buildstream | 09:13 | |
| *** tristan has joined #buildstream | 09:25 | |
| *** lachlan has joined #buildstream | 09:25 | |
| gitlab-br-bot | beckyella16 opened issue #1079 (bst artifact checkout should default to directory if neither --tar nor --directory given) on buildstream https://gitlab.com/BuildStream/buildstream/issues/1079 | 09:58 |
| * jjardon wonders if we could have that info in a single place, instead duplicate it on both | 10:04 | |
| jjardon | laurence: ^ | 10:04 |
| *** traveltissues has quit IRC | 10:21 | |
| *** traveltissues has joined #buildstream | 10:21 | |
| laurence | thanks tristan, I thought so | 10:31 |
| laurence | jjardon, what do you by 'both'? | 10:31 |
| laurence | https://buildstream.build/ and https://docs.buildstream.build/main_about.html ???? | 10:32 |
| *** ChanServ sets mode: +o tristan | 10:40 | |
| tristan | There is an "About" page on the website which is different | 10:40 |
| tristan | Don't ask me to justify that :) | 10:40 |
| tristan | Although tech wise, it makes sense... we can't realistically use the same source for the about page on the website | 10:40 |
| tristan | Fact is, we definitely want an about section in "The documentation distributed with the source code" | 10:41 |
| tristan | And we *do* reuse the README text in https://docs.buildstream.build/main_about.html | 10:41 |
| jjardon | laurence: yes | 10:41 |
| tristan | We might be able to have the "About" link on the main website be a link to https://docs.buildstream.build/main_about.html instead of a duplicate page | 10:42 |
| tristan | My understanding was that toscalix wanted to have an about page for a different audience on the website | 10:42 |
| tristan | But unless we really have resources to really focus on that website more (the website's "about" is a but confusing and not well written, e.g. it says "toolsets" and then "tools set" in the same paragraph) | 10:43 |
| tristan | ... unless we have people wanting to work on making that separate About page better, my vote would be to make the About in the website just be a link to https://docs.buildstream.build/main_about.html | 10:43 |
| tristan | I don't really disagree with Agustin that the main website has a different target audience than the documentation distributed with source code (but having both takes more effort) | 10:44 |
| tristan | My comment above "Although tech wise, it makes sense... we can't realistically use the same source for the about page on the website" <-- scratch that, I blurted that out before thinking of making it be a link :) | 10:45 |
| *** lachlan has quit IRC | 10:46 | |
| tristan | Oh, and laurence ... maybe jjardon means that, but *I* mean: https://buildstream.build/about.html and https://docs.buildstream.build/main_about.html | 10:47 |
| tristan | The face page of the website is not the about page, I would vote to remove https://buildstream.build/about.html and link to https://docs.buildstream.build/main_about.html (unless we want to put a lot more effort in the website) | 10:47 |
| tristan | A little off topic but... I still really like the idea of making https://buildstream.build/news.html a "planet", i.e. an aggregation of the buildstream related blog posts of buildstream developers | 10:56 |
| persia | Tricky balance there. Planets work best with 10+ people promising to publish with the right tags. | 10:59 |
| persia | If there are only a couple people posting, maybe better to manage directly. | 10:59 |
| tristan | persia, Do you think ? | 11:03 |
| tristan | I don't know | 11:03 |
| tristan | persia, I would say that there should be an upstream blog where releases are announced in the release process which is also aggregated there | 11:04 |
| persia | Technnically, it doesn't matter: one way involves automatically scanning sources and aggregating them, the other involves manually scanning sources and either aggregating them or publishing new ones. | 11:04 |
| tristan | But it doesnt hurt to intersperse that with *any* related blogging activity which might happen in between, however sparse | 11:04 |
| tristan | I.e. it would be nice to have the blog about how valentind built a flatpak and snap of firefox using buildstream up there | 11:05 |
| persia | Socially, I find people are more likely to publish to a planet when the set of publishers is not a "small special group", and I believe humans think about groups such that one needs at least 8 (and preferably 10) people to overcome the idea of "small special group". | 11:05 |
| tristan | Or have any exciting blog posts about conferences like "Build Meetup" there | 11:05 |
| tristan | A trap I think we *definitely* dont want to fall into, is copy/pasting verbatim from peoples blogs | 11:06 |
| persia | And it can hurt to intersperse with other content from the same authors, depending on the nature of the content. Best to only include things for a given tag. I remember a situation years ago with another planet where someone published everything, and everyone else got mad because of what they wrote about *entirely other things* on their blog. | 11:06 |
| tristan | But planets do have that feature right ? | 11:07 |
| persia | I don't consider copy/paste verbatim to be a "trap". It's doing something manually that could be automated. | 11:07 |
| tristan | People would have to tag their posts "buildstream" | 11:07 |
| tristan | persia, that is a sort of trap, as in it prevents content from showing up until someone eventually gets around to doing it :) | 11:08 |
| persia | Planets don't have that feature, but the underlying syndication protocols do allow one to specify a tag (so the planet can be configured to pull a tag using the syndication protocol feature), and most publishing engines that support the syndication protocols support tags in a compatible way. | 11:08 |
| tristan | Of course that is the kind of tedium you can expect to never end up really happening :) | 11:08 |
| persia | tristan: You and I are violently agreeing. I'm saying "doing it manyally is OK as long as the person doing it is willing to do it manually promptly" and you're saying "doing it manually is risky because some people don't want to do it manually promptly". Two sides of the same blade. | 11:09 |
| tristan | :) | 11:09 |
| tristan | Anyway I think it would be a great thing for publicity, we only seem to disagree because you think a "planet" as a wide open group kind of thing, I understand that perception | 11:10 |
| tristan | I am thinking of using planet like software to facilitate the generation of interesting project new feed :) | 11:10 |
| tristan | Which I would expect to have different perception | 11:10 |
| persia | But my point is that if news is published though aggregation, and there are only two or three syndicate feeds listed, the social barrier to volunteering one's content to be syndicated is high: getting over that benefits from an active editor/curator who is seeking to republish content and can help guide people on what sorts of excellent posts they are already publishing should be syndicated to the buildstream news page. | 11:11 |
| tristan | I see what you mean yes | 11:11 |
| persia | Once the number of publishers is high enough, then there's less need for active editing/curation, because a sense of appropriate content develops as a result of past contnt. | 11:11 |
| persia | And telling the editor to use planet means the editor is begging publishers to add the tag to the publication engine, have the right syndication protocols, etc. At low volume, it's easier to just ask permission to copy the content. | 11:12 |
| tristan | persia, if I were to reach back to say https://glade.gnome.org/, we actually do all that news section manually in python and it has an rss feed, but even if way back when it was only mine and xjuan's blogs being sindicated on our page, it would have been great | 11:13 |
| tristan | then when we had some contributor come up and do like... a whole couple month project (happened occasionally), we'd probably naturally invite them to have their related posts syndicated | 11:13 |
| tristan | Of course it takes someone to reach out to an idividual and say "Hey, why not syndicate these posts on our site !" :) | 11:14 |
| persia | tristan: Yep. I think starting from the viewpoint of syndication is best, but I think it is up to the editor how they wish to handle that until the volume is high enough that automation is a net benefit. You and xjuan are a special group who happen to use the same classes of blog engine and syndication protocol. | 11:14 |
| tristan | Here I was thinking that RSS was like, already something stable and reliable | 11:15 |
| persia | So, maybe start with planet (if the editor is comfortable and has a planned workaround to deal with incompatible publishing engines) or start with manual, while educating the author community, and then switching to planet later. | 11:15 |
| tristan | I guess we can't ask for things to come in standard formats :) | 11:15 |
| persia | RSS and ATOM are fairly common, but there are others as well. | 11:15 |
| persia | Last time I looked at a planet config, I think there were something like 6 syndication protocols supported. I haven't looked at what protocols are supported by engines ever, but I imagine it to be a larger number than are supported by the readers and planets, etc. | 11:16 |
| persia | (and as each syndication protocol has new useful features of various sorts, there's all sorts of compatibility issues to get around: I remember one planet ending up publishing an RSS update every time someone commented on a post by a specific author (who was using a richer syndication protocol that the planet software didn'T support properly). | 11:17 |
| gitlab-br-bot | BenjaminSchubert opened (was WIP) MR !1467 (bschubert/node-api-split->bschubert/new-node-api: Split the yaml API, document and final fixes) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1467 | 11:22 |
| benschubert | ^ tristan I'd appreciate a thorough review if you have time! That's the final part before making the MR to master | 11:22 |
| *** lachlan has joined #buildstream | 11:22 | |
| tristan | Right ! | 11:24 |
| benschubert | and this is in what I expect to be the final state :) | 11:25 |
| *** lachlan has quit IRC | 11:30 | |
| *** laurence has left #buildstream | 11:33 | |
| *** laurence has joined #buildstream | 11:33 | |
| *** lachlan has joined #buildstream | 11:52 | |
| *** lachlan has quit IRC | 11:59 | |
| *** bochecha has quit IRC | 12:19 | |
| *** bochecha has joined #buildstream | 12:20 | |
| benschubert | tristan: just to make sure I understood https://gitlab.com/BuildStream/buildstream/merge_requests/1467#note_191227172 correctly, wherever we access Nodes that is not under src/buildstream/!plugins we should be importing from buildstream, correct? That means also for tests | 13:00 |
| tristan | benschubert, Yeah that should mean also for tests | 13:12 |
| benschubert | tristan: for tests that do 'from buildstream.node import Node', should we have them do 'from buildstream import Node' ? | 13:13 |
| tristan | benschubert, we have always exported public symbols in the toplevel __init__.py, so that we always have the freedom to move things around at will without affecting the public interface generally | 13:13 |
| tristan | benschubert, Yes I think so | 13:13 |
| benschubert | ok! I'll modify all of this then, thanks! | 13:14 |
| tristan | I mean, for tests it's less sensitive because we can control them, but of course when refactors happen which move internal modules around; having the tests behave the same reduces churn | 13:14 |
| benschubert | agreed | 13:14 |
| tristan | Not that I think it's likely that we'll move Node, but just as a general rule :) | 13:14 |
| benschubert | I'll amend the commit that does the split with this | 13:14 |
| tristan | consistency and all | 13:15 |
| benschubert | yep, I'll expose ' from .node import MappingNode, Node, ProvenanceInformation, ScalarNode, SequenceNode', is that fine with you? | 13:15 |
| tristan | Yeah that looks right :) | 13:15 |
| benschubert | oh and thanks, I didn't realize the doc would be generated correctly for implementation of abstract methods :D I'll split implementations in their own part | 13:30 |
| benschubert | Do you prefer it usually before or after the new buildstream-private methods? | 13:30 |
| tristan | benschubert, lets follow what element/source do... that appears to be abstract method implementations first | 13:32 |
| tristan | oh wait | 13:32 |
| tristan | No | 13:32 |
| tristan | benschubert, sorry... That is "Abstract method *definitions* come first" in element | 13:33 |
| benschubert | which is the same in Node :) | 13:33 |
| tristan | Appears that it does not implement anything abstract from Plugin base class so we don't really have precedent in Element/Source | 13:33 |
| benschubert | yep, so which precedent do we want to set? I'd be to have them after, since we don't really need them to be super discoverable and mix match public + private | 13:34 |
| tristan | benschubert, I'm rather ambivalent if there is no precedent... public always comes before private though, and this is confusing in this case because we have both public AND private abstract methods to implement | 13:34 |
| benschubert | or do we want public, public implem, private, private implem, local ? | 13:35 |
| tristan | benschubert, I think I like that last thing yeah, that looks good | 13:35 |
| benschubert | perfect, thanks! | 13:35 |
| *** lachlan has joined #buildstream | 13:40 | |
| *** lachlan has quit IRC | 13:51 | |
| benschubert | tristan: I think I addressed all your comments, would you have time to validate them and do a second round? | 13:56 |
| * tristan reloads page... | 13:59 | |
| tristan | it takes time :) | 13:59 |
| benschubert | Yeah :/ I'm not happy about the size of this change but think it was the only way x) | 14:00 |
| *** traveltissues has quit IRC | 14:01 | |
| *** lachlan has joined #buildstream | 14:01 | |
| *** traveltissues has joined #buildstream | 14:01 | |
| tristan | benschubert, I can't see easily from the patch, but are Element.get/set_public_data() signatures / docs updated ? | 14:08 |
| tristan | Do they now work with MappingNode ? | 14:08 |
| tristan | maybe it's in a different patch | 14:09 |
| benschubert | let me double check | 14:09 |
| benschubert | it fell through the cracks, thanks :D | 14:09 |
| tristan | benschubert, also did my _composite_under() nitpick comment get through gitlab ? it seems to have disappeared | 14:15 |
| tristan | benschubert, Was just suggesting that instead of documenting this as "composites the source under the target instead" like that, could we just rename the 'target' parameter to be 'source' instead ? that seems a bit more clear | 14:16 |
| tristan | actually I don't care a great deal about it, but it seems gitlab didnt pick it up | 14:17 |
| benschubert | tristan: it did and I answered it | 14:17 |
| benschubert | https://gitlab.com/BuildStream/buildstream/merge_requests/1467?commit_id=396898ad15bc41bc2e00cd5b7251278223bf0d07#note_191262925 here! | 14:17 |
| tristan | Strange I'm not seeing it in the full diff :-/ | 14:18 |
| tristan | benschubert, Sure, no worries :) | 14:18 |
| tristan | benschubert, Ok I don't think I will get through all the comments and resolve them by hand, but I think we're definitely good enough to go with this | 14:21 |
| tristan | probably wanna catch that get/set_public_data() thing | 14:21 |
| tristan | benschubert, Of course get/set_public_data() is of special interest because I'm interested to see what the port of the debian plugins which use it extensively will look like :) | 14:21 |
| tristan | I suppose it may involve some Node.from_dict() going on in there | 14:22 |
| benschubert | tristan: fix pushed for this one :D | 14:22 |
| tristan | That's kind of one of the things which triggered this big refactor | 14:22 |
| benschubert | So if you're happy with this change and can approve it, I'll just wait until Kinnison gave me his last feedback, merge it and make the final PR | 14:23 |
| benschubert | https://gitlab.com/BuildStream/buildstream/merge_requests/1467/diffs?commit_id=77d65eeb9bc8ad256e52e937bb866ce81caee6bf for the public_data doc change | 14:24 |
| tristan | benschubert, I have to say I am a *bit* concerned still, there are parts of those porting patches which I pointed to (the patches in bst-plugins-experimental) which: (A) Gets public data from dependencies recursively... (B) Does some python dict manipulations, essentially creating a report of those... (C) Sets the result of that as a dictionary as it's own public data | 14:25 |
| tristan | I wonder what those will look like as a result of this | 14:25 |
| benschubert | tristan: do you have a link? | 14:25 |
| tristan | https://gitlab.com/BuildStream/bst-plugins-experimental/merge_requests/4/diffs?commit_id=9789013079fa11d1b144cb516c55ffc709bbcfd3 | 14:26 |
| benschubert | we always have the option of making 'strip_node-info' public in the worst case | 14:26 |
| tristan | It's linked to from the original issue which this branch should probably be made to close: https://gitlab.com/BuildStream/buildstream/issues/1006 | 14:26 |
| tristan | there are two links to patches from that issue, which are samples of things we do with public data | 14:27 |
| gitlab-br-bot | tristanvb approved MR !1467 (bschubert/node-api-split->bschubert/new-node-api: Split the yaml API, document and final fixes) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1467 | 14:28 |
| * tristan uses the approve button | 14:28 | |
| benschubert | tristan: is the 'collect_manifest' well tested? If so, I can have a go at porting it to the new API and if we need something more in the API, I'll add it | 14:28 |
| tristan | Unfortunately not I don't think so | 14:29 |
| tristan | I think it fell through the cracks on my first attempt, and I needed to do a full build to catch it | 14:29 |
| benschubert | a full build of freedesktop? | 14:29 |
| tristan | benschubert, however the nightly BuildStream CI should probably exercise it (the one which I think is again failing by jjardon's latest account) | 14:29 |
| tristan | yeah | 14:29 |
| benschubert | ok! | 14:30 |
| benschubert | I don't think I'll have time this week, but I can have a look next week at building it entirely and fix the experimental plugins | 14:30 |
| tristan | the debian plugins on the other hand are well tested (but not *used* to my knowledge) | 14:31 |
| tristan | ironically we have tests for the plugins we don't use and not the other way around haha | 14:31 |
| tristan | But my suspicion is that *you* do use the debian plugins :) | 14:31 |
| benschubert | also from experimental, correct? Then I'll look at this ;) | 14:31 |
| tristan | (we did make them for your team originally after all) | 14:31 |
| tristan | yeah they are from bst-plugins-experimental, ported over from bst-external | 14:32 |
| benschubert | ok, once the yaml changes are in, I'll have a look | 14:34 |
| gitlab-br-bot | traveltissues approved MR !1451 (becky/tar_compression->master: Allowing `bst artifact checkout --tar` to use compression) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1451 | 14:42 |
| gitlab-br-bot | traveltissues unapproved MR !1451 (becky/tar_compression->master: Allowing `bst artifact checkout --tar` to use compression) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1451 | 14:49 |
| *** tristan has quit IRC | 14:54 | |
| *** tristan has joined #buildstream | 15:07 | |
| *** lachlan has quit IRC | 15:08 | |
| *** traveltissues has quit IRC | 15:09 | |
| *** traveltissues has joined #buildstream | 15:09 | |
| *** lachlan has joined #buildstream | 15:40 | |
| *** lachlan has quit IRC | 15:45 | |
| gitlab-br-bot | BenjaminSchubert merged MR !1467 (bschubert/node-api-split->bschubert/new-node-api: Split the yaml API, document and final fixes) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1467 | 15:47 |
| gitlab-br-bot | BenjaminSchubert opened MR !1472 (bschubert/new-node-api->master: Rewrite of the Node API) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1472 | 15:56 |
| *** tpollard has quit IRC | 15:56 | |
| benschubert | tristan: ^ here is the final MR! | 15:57 |
| *** xjuan has joined #buildstream | 16:10 | |
| *** lachlan has joined #buildstream | 16:10 | |
| *** lachlan has quit IRC | 16:14 | |
| *** alexandrufazakas has quit IRC | 16:16 | |
| *** bochecha has quit IRC | 16:18 | |
| *** lachlan has joined #buildstream | 16:24 | |
| *** traveltissues has quit IRC | 16:26 | |
| gitlab-br-bot | jennis approved MR !1451 (becky/tar_compression->master: Allowing `bst artifact checkout --tar` to use compression) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1451 | 16:34 |
| *** lachlan has quit IRC | 16:35 | |
| *** lachlan has joined #buildstream | 16:39 | |
| *** traveltissues has joined #buildstream | 16:54 | |
| *** jonathanmaw has quit IRC | 17:01 | |
| traveltissues | juergbi, benschubert , do you have further comments on https://gitlab.com/BuildStream/buildstream/merge_requests/1466 | 17:01 |
| gitlab-br-bot | BenjaminSchubert approved MR !1466 (traveltissues/cache-key-changes->master: element.py: changes to __cache_key_dict) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1466 | 17:02 |
| benschubert | traveltissues: I don't, thanks! | 17:02 |
| traveltissues | thanks | 17:04 |
| gitlab-br-bot | marge-bot123 merged MR !1466 (traveltissues/cache-key-changes->master: element.py: changes to __cache_key_dict) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1466 | 17:06 |
| *** rdale has quit IRC | 17:14 | |
| gitlab-br-bot | traveltissues approved MR !1452 (raoul/994-further-re-testing->master: Further RE testing) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1452 | 17:38 |
| *** tiagogomes has quit IRC | 17:55 | |
| *** lachlan has quit IRC | 17:57 | |
| *** traveltissues has quit IRC | 18:00 | |
| gitlab-br-bot | marge-bot123 closed issue #994 (Further remote execution testing) on buildstream https://gitlab.com/BuildStream/buildstream/issues/994 | 18:06 |
| gitlab-br-bot | marge-bot123 merged MR !1452 (raoul/994-further-re-testing->master: Further RE testing) on buildstream https://gitlab.com/BuildStream/buildstream/merge_requests/1452 | 18:06 |
| *** xjuan has quit IRC | 18:09 | |
| *** xjuan has joined #buildstream | 18:40 | |
| *** xjuan has quit IRC | 19:06 | |
| *** bochecha has joined #buildstream | 19:16 | |
| *** cs-shadow has quit IRC | 20:08 | |
| *** slaf has quit IRC | 21:25 | |
| *** slaf has joined #buildstream | 21:27 | |
| *** slaf has joined #buildstream | 21:27 | |
| *** bochecha has quit IRC | 22:35 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!