14:00:34 <tpollard> #startmeeting buildstream monthly irc team meeting may 2019
14:00:34 <GNOMie> Meeting started Tue May 14 14:00:34 2019 UTC.  The chair is tpollard. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:34 <GNOMie> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:00:34 <GNOMie> The meeting name has been set to 'buildstream_monthly_irc_team_meeting_may_2019'
14:01:08 <valentind> Hello
14:01:09 <tpollard> I'm running this in place for laurence as he's away so hopefully it goes ok, who's attending?
14:01:17 <valentind> o/
14:01:19 <tristan> o/
14:01:30 <Kinnison> o/
14:02:23 <tpollard> Ok, meetbot will highlight any other attendees who contribute :)
14:02:34 <tpollard> We'll start with actions from last month
14:02:34 <cs-shadow> o/
14:02:43 <tpollard> #topic Actions from last meeting
14:03:33 <tpollard> Both of there were from laurence, first of all a FOSDEM devroom based on build tooling, with tristan & laurence to discuss with other projects
14:03:38 <tpollard> any movement there tristan?
14:03:51 <tristan> :(
14:04:01 <tristan> I've not done my homework this time around
14:04:06 <tristan> Still, there is time
14:04:12 <cs-shadow> i think it'll be a great idea
14:04:21 <tpollard> laurence may have started some of this, but I don't have notes from him sadly
14:04:31 <tristan> I will write up an email and send to meson's mailing list proposing they join us for a devroom
14:04:44 <tpollard> nice!
14:04:44 <abderrahim[m]> o/
14:04:44 <tristan> and share that with others so we can circulate similar emails
14:04:47 <cs-shadow> i think we should also include bazel, pants, buck etc
14:05:00 <tristan> cs-shadow, indeed
14:05:10 <cs-shadow> tristan: if you can post something on our ML about this, it'll be easier to share that way
14:05:25 <tristan> Yes, ok I'll take that as short term homework
14:05:34 <cs-shadow> thanks!
14:05:46 <tpollard> This overlaps with the second point about sending out formal invitations, so I think we should just carry this topic over as another action into the next meeting?
14:06:06 <tristan> Sure :)
14:06:45 <tpollard> #action act on proposing a 'build tooling' dev room at FOSDEM with various buildtooling upstreams
14:06:57 <tpollard> Ok onto topics added to the list
14:07:07 <tpollard> #topic Potential 1.4 feature release
14:07:13 <tpollard> do you want to lead this tristan?
14:07:17 <tristan> Sure
14:07:43 <tristan> Ok so basically abderrahim[m] and I have discussing a potential, *small* 1.4 feature release
14:08:02 <tristan> Sander asked why on the mailing list as he couldnt attend this email and I enumerated the main points there
14:08:18 <tristan> but basically the situation is that...
14:08:56 <tristan> We have a single pain point which could be solved with a very simple feature addition: User configurability of max-jobs, instead of hard coding it to be max(available threads, 8)
14:09:31 <tristan> People are writing makefiles which patch buildstream checkouts in CI, and hacking ninja in project.confs and such nonsense, to force unlimited CPUs
14:09:52 <tristan> So that webkit builds a bit faster in some specific CI servers, and crashes every other machine that doesnt have the ram
14:10:00 <persia> I still think that shouldn't be user-configurable on a per-project basis.  Different build hosts have vastly different models for how to calculate the right number of threads.
14:10:00 <tristan> So I would propose adding that feature to master and 1.4
14:10:22 <persia> That said, is it safe to assume that the 1.4 release process wouldn't involve a freeze of master?
14:10:25 <tristan> persia, How do you mean on a per-project basis ?
14:10:31 <tristan> I mean user configuration, not project configuration
14:10:58 <abderrahim[m]> I'd add that this is related to https://gitlab.com/BuildStream/buildstream/issues/185
14:11:00 <persia> tristan: I want to configure max-jobs on a per build target.  If that's "user configuration" with typical CI models, then all my concerns are addressed.
14:11:36 <persia> But especially in the remote-execution case, a single user might want to target different builds on different worker platforms, where max-jobs would need to differ.
14:11:39 <tristan> persia, And to answer the second question, it would *NOT* be a release of master at all of course - it would mean some limited backports, and a quick solution for the max-jobs emergency
14:12:13 <tristan> In remote execution the configuration would have to not be observed, I have not proposed the feature yet per se, but the pain point is my main motivation for pushing for this
14:12:19 <persia> That's the important question.  If the 1.4 release process doesn't impact master, then I believe it to be safe (as part of why we decided no releases was to avoid freezing master while we did the big changes necessary for 2.0)
14:12:34 <tristan> So I was one point into my 3 point summary
14:12:39 <tpollard> I think that the max-jobs issues may fall under the remit of 'critical patch releases'
14:12:54 <WSalmon> +1
14:13:05 <tristan> tpollard, strictly speaking it's a feature addition, so it should not land on 1.2
14:13:16 <tristan> It would not mean a *big effort* release though
14:13:27 <tristan> The other two points are:
14:13:54 <tristan> * Simple YAML features: build-depends, runtime-depends and ability to refer to cross junction elements using colon notation "junction.bst:element.bst"
14:14:34 <tristan> * Possibly (and I'm less convinced about the last point): Deprecation warnings on the CLI commands which are going to change in BST 2, with support for the new syntaxes
14:15:11 <tristan> As I mentioned in my reply to Sander on list, I would not strongly oppose it if abderrahim[m] is volunteering to do the work
14:15:18 <persia> I think the YAML stuff belongs in 1.4.  I'm less sure about deprcation: I feel like we want to be very certain about finalising the 2.0 CLI first (which may imply a later lightweight 1.6)
14:15:21 <tristan> Sorry, that's my three points :)
14:15:39 <tpollard> thanks for the explanation tristan
14:15:43 <tristan> persia, I have a tendency to agree with you on that
14:15:58 <tristan> abderrahim[m], it is fairly possibly that CLI additions are not finalized
14:16:15 <tristan> there can be churn up ahead, so it could be wise to postpone that kind of activity
14:16:33 <persia> abderrahim[m]: Feel free to argue your case, if you think there are cases where some deprecation messages are very important for current users :)
14:17:15 <abderrahim[m]> my main motivation is the ability to use bst2 on projects that are "stuck" with the stable release
14:17:28 <tristan> Maybe a good argument is that: It would really be nice to have `bst artifact log` and `bst artifact delete`, as they are fairly low hanging fruit and generally useful
14:17:33 <tristan> Ahh
14:17:42 <abderrahim[m]> So we can port them to work with bst master, and still have a stable 1.4 release they can use
14:17:59 <tristan> abderrahim[m], I'm not sure how realistic that is actually
14:18:19 <tristan> abderrahim[m], Well, at the very least, bst 2 projects need to rely on bst 2 plugins
14:18:29 <persia> abderrahim[m]: I think that's a brilliant idea.  I lack confidence that the thing that will become bst 2.0 is stable enough for that yet.
14:18:33 <tristan> That may for the time being be a one line patch, but it may not
14:18:34 <abderrahim[m]> I'd also like to have some plugin API so that we can have easier transition to bst 2
14:19:19 <abderrahim[m]> I don't necessarily want 1.4 to happen now
14:19:34 <tristan> I think it's too early in the game for this - as plugins are going to not necessarily churn much themselves: But they are going to churn locations
14:19:41 <abderrahim[m]> we can give it some time (say until August) and try to make sure the CLI is stable
14:20:07 <tristan> abderrahim[m], Ok... so maybe we can have some middle ground and maybe consider a 1.6 for some of the other things
14:20:08 <tristan> ?
14:20:20 <tristan> Because honestly, this max-jobs thing is rather urgent
14:20:45 <tpollard> it sounds like there's a vague consensus around max-jobs & a few yaml changes making it into a 1.4
14:20:46 <tristan> My webkit builds break locally without patching the upstream projects which have done naughty things for lack of a feature :-/
14:20:47 <cs-shadow> i doubt that bst 2.0 will be stable by mid august
14:21:17 <cs-shadow> i also think that we should not put a date on it as we specifically decided that in the last gathering
14:21:20 <abderrahim[m]> tristan: maybe changing max-jobs based on the number of builders and number of processors would be good for 1.2?
14:21:23 <persia> cs-shadow: +1
14:21:47 <abderrahim[m]> cs-shadow: I just want to have the new CLI stable, not everything
14:21:50 <tristan> cs-shadow, I don't think abderrahim[m] was suggesting that (only for the CLI) - but I would also agree that even the CLI changes are likely to not be stable by august
14:21:52 <persia> abderrahim[m]: Processor (core) count isn't a reliable guide for that.  I've seen processors with 80 cores and a single channel to main memory.
14:22:55 <abderrahim[m]> The discussion in https://gitlab.com/BuildStream/buildstream/merge_requests/620 is also relevant
14:23:07 <tristan> persia, I think that we need a simpler fix for max-jobs early on, and we could evolve something later - I would really be happy with a single user configuration for max-jobs (and the potential for making it more complex later on with more knowledge learned)
14:23:11 <tpollard> We're nearing 15 minutes on this topic, should we take it as an action to move it to a relevant mailing list post?
14:23:25 <abderrahim[m]> persia: and what would you suggest for those?
14:23:30 * persia goes to rant on 620, as apparently the last rant was in a different place
14:23:35 <tristan> Ok
14:23:55 <tristan> I can summarize this discussion on the mailing list, or abderrahim[m] can summarize if he likes
14:24:01 <tristan> Shall I take the action point ?
14:24:03 <tpollard> There's definitely some useful reasoning debate here which can be referenced
14:24:07 <abderrahim[m]> Ok, I can send a post to the ML with what I'd like 1.4 to be
14:24:17 <tpollard> great
14:24:22 <tristan> OK :)
14:24:22 <cs-shadow> tpollard: i agree, we should move the discucsion to the ML. i think it's big enough for ML
14:24:30 <abderrahim[m]> I'm okay with a summary as well
14:25:16 <tpollard> #action abderrahim to send a post to the ML with what he'd like 1.4 to be
14:25:47 <tpollard> Now there's another topic from the list but the poster is not here
14:26:21 <tpollard> #topic is there a need to have a monthly irc meeting over separate mailing list topics
14:26:32 * tristan thinks meetbot is not doing it's thing, but not a huge deal I guess :-/
14:26:33 <tpollard> for reference this was raid by Sander
14:26:43 <tpollard> *raised
14:27:10 <tpollard> Anyone with any input here?
14:27:41 <tristan> Honestly, I like that we have live meetings like this rather than only mailing list discussion and casual IRC
14:28:02 <tpollard> I agree with that, I find some topics much easier to follow in the format
14:28:03 <tristan> I think the meetings got stale for a while last year when we were just doing rounds of issues
14:28:31 <tristan> but I think they are getting better again, but it is sad that not everyone who would like to attend can always attend
14:28:49 <WSalmon> also, the talk about Dev rooms dosnt really fit on the mailing list as well so it seems good to talk that sort of thing in this forum.
14:30:02 <tpollard> Ok, I don't think there's much more to say here on it right now
14:30:06 <tristan> In a way, I should also point out that this format of meeting is better for the causal contributor
14:30:22 <SotK> +1
14:30:34 <tristan> And while right now, there is a large focus on full time developers who have the opportunity to meet often, I hope we can spread the love :)
14:30:44 <SotK> its way easier to hop into a meeting discussion than a ML thread
14:30:46 <tpollard> Hopefully when a topic matures from here into a ML post then we get the best of both worlds
14:31:26 <tpollard> I think we can move on
14:31:36 <cs-shadow> tristan: i think IRC is fine for _casual_ discussions but we should promote things like new versions/releases to the ML
14:32:14 <persia> I feel we should adopt practice from Apache: nothing that isn't on the mailing list has happened.
14:32:28 <tristan> cs-shadow, I'm a bit torn, I think it's rather the opposite in a way
14:32:41 <persia> That said, I think having a regular monthly meeting helps tease out thinking about things, and leads to action items like "write this to the mailing list" that might otherwise not happen.
14:32:47 <tristan> cs-shadow, I.e. some things can be discussed to death on the ML, and finally come monthly meeting we can come to something conclusive
14:32:54 <tristan> cs-shadow, both can be true
14:33:27 <WSalmon> +1 <persia> That said, I think having a regular monthly meeting helps tease out thinking about things, and leads to action items like "write this to the mailing list" that might otherwise not happen.
14:33:35 <tpollard> Does anyone have a specific action they'd like to take for this topic?
14:33:56 <SotK> WSalmon, persia: +1
14:34:13 <persia> Personally, I think it is key *not* to do a review of issues and/or MRs here.  Better to have a high-level loose agenda for some talking points.  If we don't have any, having a 5-minute meeting is OK.  (I see that happen fairly often for other communities that have a weekly meeting, and at least sometimes for other communities that have a monthly meeting).
14:34:15 <cs-shadow> ML is an asynchronous medium, which means that people can contribute even if they cannot make time for this specific meeting. My only point is that big decision items should end up on the ML
14:35:12 <tpollard> I'm going to move on
14:35:16 <persia> cs-shadow: I agree that decisions should happen on the ML.  I also agree with tristan that this meeting can be useful to cause consensus for threads that don't seem to be landing (and in such cases, I believe it appropriate to bring that consensus back to the mailing list)
14:35:36 <tristan> persia++
14:35:38 <persia> tpollard: Thanks for timeboxing the discussions.  We could probably go on forever on each of these :)
14:35:53 <tpollard> no problem
14:36:05 <tpollard> #topic AOB
14:36:12 <tpollard> would anyone like to raise anything else?
14:38:08 <tpollard> Ok, looks like we can end in 5....
14:38:14 <tpollard> 4
14:38:15 <tpollard> 3
14:38:17 <tpollard> 2
14:38:19 <tpollard> 1
14:38:22 <tpollard> #endmeeting