13:57:58 <laurence> #startmeeting BuildStream Monthly irc team meeting
13:57:58 <GNOMie> Meeting started Tue Jul  9 13:57:58 2019 UTC.  The chair is laurence. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:57:58 <GNOMie> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:57:58 <GNOMie> The meeting name has been set to 'buildstream_monthly_irc_team_meeting'
13:58:23 <laurence> please announce your presence
13:59:00 <valentind> o/
13:59:04 <tristan> o/
13:59:41 <laurence> alright, let's get into the actions from the last meeting
13:59:45 <laurence> a) continue to discuss/try to oragnise a proposal for a 'build tooling' dev room at FOSDEM with various buildtooling upstreams
14:00:23 <laurence> we've had some offline discussion about this....upshot is that we don't think we can do a 'build tooling' dev room for FOSDEM this year
14:00:50 <tristan> So maybe submit talks to other rooms
14:00:53 <laurence> But there could be some interesting events with some of the relevant people attending over the rest of the year / early next
14:01:14 <laurence> tristan, to the distro room again?
14:01:21 * laurence wonders if we'd be welcome there, hehe
14:01:28 <tristan> I think we aught to try more than one room this time
14:01:36 <tristan> be a bit more aggressive in submissions
14:01:50 <tristan> I can't imagine us going another year without *any* FOSDEM presence
14:02:14 <tristan> Also try for a lightning talk there
14:02:19 <laurence> more aggressive, let's do it, yeah
14:02:35 <laurence> let's have a look at the submission schedule
14:02:43 <tristan> We wont get a devroom this year with other actors we thought we would, but everyone will be at FOSDEM anyway so we should try
14:02:59 <tristan> Devrooms will get approved in september iirc
14:03:03 <laurence> try to get some talks in one, rather than try to run our own room
14:03:12 <laurence> or try to run our own room?
14:03:18 <tristan> So we don't have a definitive list, but I think there was a formats and general tooling room last year
14:03:49 <tristan> Well honestly, we could try to run our own room anyway but I don't know how that will come across
14:04:10 <laurence> yeah i'm not sure we should, not for this time
14:04:15 <tristan> if we wanted to try that, we would *probably* get a meson talk, and *maybe* a ninja one
14:04:27 <tristan> but we should have someone give a bazel talk too
14:04:35 <tristan> maybe even a yocto talk
14:04:40 <tristan> for the hell of it
14:05:21 <persia> One of the bits of feedback I got when trying to get people to join in the idea of having a devroom was that folk didn't want to be trapped in that room all day, and wanted to go to other rooms at FOSDEM.
14:05:28 <laurence> also i had another thought tristan - when we initially discussed the dev room, you mentioned meson and ninja
14:05:32 <tristan> laurence, I don't know if we should sway to a definitive no... but a probably not I guess
14:05:41 <persia> Although if we get everyone (yes, Yocto too), maybe it becomes interesting.
14:05:49 <laurence> we should 'reach out' to them for any other meet ups in this space
14:05:50 <laurence> i think?
14:07:39 <tristan> laurence, sorry got distracted for a sec
14:07:44 <persia> Let's take silence as uncertainty :)
14:07:46 <laurence> There's another, not insignificant point, about organising a devroom - it needs volunteers to run it, and it's a lot of work.
14:07:58 <tristan> If we're going to "reach out", we need to do it decisively, or it wont happen
14:08:39 <tristan> If we just dip our toes in the water, it wont work out well, we need to rally interest if we're going to pull it off
14:08:49 <laurence> yeah, agree, agree
14:09:06 <laurence> And I think now is the time to make a call on this
14:09:18 <laurence> Shouldn't really delay any longer I think
14:09:40 <laurence> If it was up to me, I'd say no for this year
14:09:43 <laurence> this year being 2020
14:10:01 <tristan> persia, raises a good point... volunteers... well, the recording stuff at FOSDEM is all taken care of by the organization
14:10:26 <persia> Well, by the video team.  they always need hands as well.
14:10:32 <tristan> That is a team of really cool people who go to conferences and sometimes film for free, conference video enthusiasts
14:10:41 <tristan> I met them at FOSSASIA
14:11:22 <tristan> Mostly we need a papers review team, manage the mailing list, someone colorful to introduce the speakers with some pizzaz
14:11:42 <persia> I also vote for "no" this year, unless someone screams "I'm going to go do it", in which case I wish them luck.
14:12:00 <laurence> That was my point on the volunteering...maybe I am morphing into persia
14:12:09 <laurence> if we sound the same ;p
14:12:17 <persia> tristan: also need wranglers to cause there to be enough presentations, and some folk to advertise the room and encourage folk to attend.
14:12:32 <laurence> Back to the serious point - yeah, I've seen Luc Verhagen do it, he's there early until late
14:12:42 <laurence> Friday to Sunday
14:12:45 <laurence> It's intense
14:12:53 <tristan> Ok
14:13:01 <persia> First-year devrooms usually only get one day, but still, it's an intense day.
14:13:27 <tristan> +1... unless 2 people who are not jjardon volunteer to do a lot of work, we don't have the resources
14:13:43 <laurence> so....do we agree this year to try to get talks instead?
14:13:46 <laurence> multiple talks?
14:13:54 <laurence> or at least, multiple submissions?
14:14:06 <persia> multiple submissions is the thing to target.
14:14:11 <tristan> Gorilla submissions
14:14:24 <persia> My suggestion is for folk who think they have something to submit to notify the mailing list as they do so.
14:14:33 <persia> We can review what submissions have been sent at the next meeting
14:14:44 <tristan> And I would say tailor the submissions to fit the room, whether the talks get accepted decides what actual talks we end up giving
14:14:49 <laurence> #agreed for FOSDEM 2020, we will not push ahead with trying to organise a 'Build Tooling' dev room
14:14:54 <persia> (because asking people to volunteer to give a talk at short notice in a meeting is not going to get a lot of volunteers)
14:15:17 <tristan> We have a huge amount of time until talk submissions (well, months)
14:15:35 <persia> Right.
14:17:23 <laurence> OK...this all sounds good...so perhaps the action is to walk through the rooms / tracks and come up with a plan of what talk submissions would be good fits....and also who might be a good fit as speakers....
14:17:54 <laurence> and also see if we can utilise any relationships with any FOSDEM people we might know (no idea if this is genuinely feasible for FOSDEM or not)
14:18:17 <laurence> we can organise a specific slot for that maybe, now might not be the time...
14:18:25 <laurence> does that sound roughly okay?
14:18:35 <persia> Yes.
14:19:03 <laurence> #agreed we should target multiple FOSDEM talk submissions
14:19:23 <tristan> While FOSDEM is probably one of the most important events, we have other conferences too
14:19:26 <laurence> #action laurence to organise a slot to come up with a strategy on this
14:19:54 <laurence> #action laurence to organise a slot to come up with a strategy on FOSDEM (and other conference) talk submissions
14:20:26 * persia hopes the strategy ends up being someone informal and involving sending things to the mailing list
14:20:36 <persia> s/someone/somewhat/
14:21:17 <laurence> Yeah I think the important bit is that we're all joined up and we're transparant about what we're submitting to where and when
14:21:37 <laurence> that's all, no need to be overly formal, just need a record of it and transparency
14:21:41 <laurence> it needs an owner, basically
14:21:44 <laurence> and i'm happy to do that
14:22:09 <laurence> alright....moving on then....
14:22:26 <laurence> b) lachlan to announce to the ML, and also announce marge-bot being moved into the project's own management, once we've done that
14:22:41 <laurence> no movement on this, marge-bot is still managed by Codethink Ops.
14:23:00 <laurence> I'll chase this
14:23:17 <persia> Thanks.  Good to have project control on that.
14:23:34 <laurence> #action laurence to chase down progress with marge-bot being moved and discuss with Lachlan about infra responsibilities
14:23:44 <laurence> moving on
14:23:47 <laurence> c) laurence to ensure the committer policy reflects the reality of the situation
14:23:51 <laurence> I submitted a patch
14:24:09 <laurence> #link https://gitlab.com/BuildStream/buildstream/merge_requests/1415
14:24:25 <laurence> and, importantly, then discussed and said it's be better to have this automated and linked to gitlab permissions
14:24:27 <laurence> so i raised an issue
14:24:38 <laurence> #link https://gitlab.com/BuildStream/buildstream/issues/1071
14:24:49 <laurence> so this is in progress
14:25:14 <laurence> if no comments, then moving on...
14:25:22 <laurence> next up:
14:25:25 <laurence> d) laurence to also have a look at tidying up old gitlab labels and anything else that is out of date
14:25:40 <laurence> jjardon was gracious enough to give me permissions so that I can go ahead and start on this.
14:25:46 <tristan> That's what I was going to ask about :)
14:25:58 <laurence> Obviously I will inform people before I start archiving everything
14:26:04 <laurence> but the action should be carried forward
14:26:38 <laurence> #action laurence to tidy up gitlab labels and boards (in discussion with tristan)
14:26:46 <tristan> Ok so... can we please start by sorting out, and clarifying; that labels in gitlab are used to reflect severity
14:26:49 <tristan> Not priority
14:26:55 <laurence> oh also I was going to remove the old unused repos, as Chandan pointed out on the list
14:27:06 <laurence> #action laurence to look at archiving old unusused repos
14:27:31 <laurence> tristan, yes, let's remove all notion of 'project management' from gitlab
14:27:36 <tristan> Foremostly, that gitlab is a venue for any contributors to participate, and as an upstream, we don't require any contributor to share the priorities of other participants
14:27:37 <laurence> status boards, all that jazz, gone
14:28:05 <tristan> Thanks - let's minimize maintenance here
14:28:24 <tristan> I also suggest that we do not duplicate documentation of what the labels mean
14:28:58 <tristan> laurence, I think this is the place to document what the labels mean: https://gitlab.com/BuildStream/buildstream/-/labels
14:29:13 <tristan> Maybe we can link to that page somewhere in the contributing guide
14:29:23 <tristan> in any existing section about labels
14:29:27 <laurence> tristan, indeed, that's the only place i'm aware of - where's the other place?
14:29:35 <laurence> oh, actually, there's the no-software repo
14:29:48 <laurence> which possibly is linked to from contributing??? not sure
14:29:50 <tristan> perhaps, yeah I'm not aware of exactly what there is :)
14:29:54 <persia> Can that just be archived entire?
14:29:57 <tristan> Yeah that is all a mess
14:30:15 <laurence> anyway i actually want to archive that repo
14:30:23 <tristan> I would like that, but we should salvage valuable materials and sort out a clearer concise picture (if someone has time to devote to that)
14:30:29 <persia> +1
14:30:33 <laurence> after a proper review of it
14:31:02 * persia believes this counts as someone volunteering for said devotation
14:31:20 <laurence> yes, I'll do it, I (sadly) enjoy this sort of thing
14:31:27 <persia> heh
14:31:34 <laurence> I actually started back in October when I submitted a patch to no-software
14:31:40 <laurence> so I just need to re-ignite that
14:31:43 <tristan> Now there is one more part of this - which is milestones
14:32:00 <laurence> ah, yeah...
14:32:01 <tristan> Maybe we shouldn't get into that now, and I'm not sure if it's worth even using them at this point
14:32:10 <laurence> I am not convinced by them
14:33:15 <laurence> And I think, generally, things are going fine right now....gitlab is a bit messy and needs tidying up....but really we are generally using it just fine IMO
14:33:24 <tristan> I think that (A) We want to use them as an indication of where something should land... (B) Unfortunately a single issue cannot have more than one milestone... (C) Until BuildStream 2 is close to being release worthy, we wont have anything other than "1.2" and "master"
14:33:27 <laurence> and milestones are one thing we are not using at all
14:33:30 <laurence> so i suggest we yank them out
14:33:36 <tristan> Or 1.4, etc
14:33:40 <tristan> +1
14:33:52 <tristan> laurence, I think we don't have a complex enough case to be using them at the moment
14:33:59 <persia> I'm not a fan of milestones in general.
14:34:30 <tristan> But that they will be useful when falling back into a regular stable software lifecycle with a defined release cadance
14:34:35 <persia> The only case I've seen them used well was for a large project (1000+ contributors) for which the release management team wanted to communicate about what would and would not land.
14:34:45 <tristan> (possibly in the form of the milestones feature, or in some other form)
14:35:02 <persia> So if people were *really* sure they could get somethinng in for a milestone, the release team would tag their issue and review their release notes content.
14:35:27 <tristan> persia, What I like... especially about these monthly meetings, is they are usually a venue where we decide on blockers for the upcoming release, and decide what is safe and unsafe to land
14:35:40 <persia> (to be fair, they are handy for projects where a single person manages everyone's priorities, but that's not the common case)
14:35:56 <tristan> Whether those decisions in a regular stable setting end up being reflected as "milestones" or not, is rather immaterial to me
14:36:11 <persia> tristan: Sure, but I think the right way to discuss that is a mailing list thread, not milestone label swapping in gitlab.
14:36:32 <persia> (because it's not easy to reply to someone's change when it's a milestone adjustment)
14:36:49 <tristan> Disagree, a mailing list is not a place where you can get a concise list of issues targetting the upcoming release
14:37:21 <tristan> I mean... just some notation to reflect what we agreed on "what gets in" and "what must be in"
14:37:36 <tristan> It's not an exercise we are doing now in master, but it's pretty critical once we become stable
14:37:41 <persia> Hrm.  There's some middle ground.  We won't solve it today :)
14:37:44 <tristan> That can also use labels or other means
14:37:59 <tristan> Anyway, I think it's irrelevant enough for our purposes right now
14:38:15 <tristan> 1.x development is not much, and 2.x dev is not ready for release mode
14:38:21 <tristan> So lets just not do anything for now :)
14:39:08 * tristan used to use a flagship bug in bugzilla which depended on all the release blockers... bugzilla was nice :)
14:40:05 <laurence> yeah that seems a nice feature
14:40:20 <laurence> ok....I won't touch milestones....for now...
14:40:27 <tristan> Anyway, I think we're side tracking here :)
14:40:37 <laurence> with that said, I'll gladly go through and remove / update the old ones
14:40:59 <laurence> like, all the issues tagged with 1.4 / 1.2 ... we can probabaly remove that
14:41:00 <tristan> laurence, We can nuke them where they exist if possible I think is the general sentiment
14:41:06 <laurence> tristan, ok
14:41:11 <tristan> It might however break gitlab so... maybe careful
14:41:32 <tristan> Like, cause references to exist pointing to a non-existing milestone record
14:41:37 <tristan> but probably not an issue
14:41:38 <laurence> #agreed gitlab milestones can be removed, where safe - we will consider reintroducing them when approaching 2.0 release
14:41:49 <laurence> #action laurence to remove gitlab milestones, where safe
14:41:56 <persia> For clarity, do we not care about them if there is a 1.6?
14:42:19 <tristan> persia, My thoughts are that development of 1.x is small enough that we just dont need it
14:43:06 <persia> tristan: So you're thinking that any further 1.x releases contain whatever was merged at the time, without need to try to forecast?  I'm a big fan of that model where one isn't trying to generate e.g. conference content in advance of release.
14:43:07 <tristan> I'll try to wrangle up a 1.4 before guadec with at least the critically needed features
14:43:18 <persia> That would be good.
14:43:54 <laurence> OK
14:44:05 <laurence> do you want to take an action, tristan ?
14:44:20 <tristan> I could... for the 1.4 release ?
14:44:23 <laurence> yeah
14:44:41 <tristan> What should it be... "wrangle up a 1.4 before guadec with at least the critically needed features" ?
14:44:45 <tristan> I can take that yes :)
14:45:08 <laurence> alright :)
14:45:19 <tristan> I'll make a bst-1 branch off of bst-1.2, and that will become "bst 1 mainline"
14:45:30 <tristan> so we have a simple model for minor points in the future
14:46:07 <tristan> (not that I want that future to be very long lived... just so that there is a simple model in place :))
14:46:08 <laurence> #action tristan to ensure stable 1.4 branch is in place, with all critically needed features, before GUADEC
14:46:19 <laurence> I didn't want to use the word 'release'...
14:47:01 <tristan> "Real clingon software is never released... it escapes ! leaving a bloody trail of quality assurance agents in it's wake !"
14:47:20 <laurence> :)
14:47:24 <laurence> ok, that was all the actions....
14:47:32 * persia thinks that word is usually spelled with a K in transliteration
14:47:35 <laurence> I have an AOB to raise
14:47:46 <persia> Heh.  50 minutes in and we've just barely covered minutes of the last meeting :)
14:47:51 <tristan> persia, sorry, I knew it was off while typing it :)
14:48:03 <laurence> interesting fact: a clingon in local Manchester dialect is something very different entirely
14:48:11 <persia> laurence: Is there anything in the core agenda between review of minutes and AOB?
14:48:12 <laurence> anyway
14:48:17 <laurence> persia, no
14:48:29 <persia> Excellent.  We probably have time for the AOB item then.
14:49:09 <laurence> I think the CONTRIBUTING guide is too large
14:49:18 <laurence> And somewhat off putting for new users
14:49:32 <laurence> And I am guilty as well because I have used it as a dumping ground
14:49:35 <laurence> which isn't right
14:49:40 <laurence> So I suggest we split it up
14:49:50 <laurence> And I'll have a think about how, and post to the list on it
14:50:15 <laurence> probably won't get around to that for a few weeks, to be honest, but I will do it
14:50:18 <tristan> laurence, First move... pull the coding standards into a separate file, maybe CODINGSTYLE.rst
14:50:26 <laurence> yeah, definitely
14:50:31 <tristan> That part is good for standing alone
14:50:57 <laurence> and, not sure if we have a 'design principles' part yet, but I know we want to add one, re the UI / UX choices made
14:51:04 <laurence> so that could be seperate
14:51:51 <persia> Indeed.  Conntributing should be the bare minimum to get started, with lots of pointers to lots of other things explaining all the details.
14:52:12 <tristan> One tricky part of this
14:52:24 <tristan> CONTRIBUTING.rst is viewable on gitlab
14:52:24 <persia> That also makes it easier to reference things int he future, because one can reference a relatively small file in response to a question, instead of expecting folk to dig through all of Contributing to find the one sentence they care about that day.
14:52:36 <tristan> But it is also a part of the generated documentation
14:52:55 <tristan> This raises questions about how linkage works if it were to be split up
14:53:12 <laurence> ah yeah, of course
14:53:18 <persia> Probably requires some investigation of how gitlab renders it and how we generate the docs, and whether there is a compromise syntax.
14:53:21 <laurence> there must be a way around it
14:53:27 <tristan> I would be in favor of removing it from the docs
14:53:34 <tristan> And only link to it in the repo
14:54:09 <tristan> persia, it's a pain, we have it also for the readme "about" section and it's really annoying
14:54:26 <persia> And maybe have a small (entrely separate) section in the docs saying somethin glike "if you want to contribute, go read Contributing on the repo"?
14:54:47 <persia> If it's really annoying, we should find ways not to do it.
14:55:12 <laurence> there is an open issue
14:55:18 <tristan> For the About, it's short enough that we can reuse the README (although the badges dont work correctly on gitlab, they only work well in the docs)
14:55:37 <laurence> just not quite high enough in the priority list for anyone to look at it, yet
14:55:40 <laurence> maybe I can find someone
14:55:53 <tristan> persia, other than that, I don't see much different in the "Contributing" section of the toplevel docs being a link to CONTRIBUTING.rst on gitlab, or being an actual subsection
14:56:02 <laurence> alright, thanks for all the comments / feedback, I 'll take the action
14:56:17 <laurence> #action laurence to look at how we could split up CONTRIBUTING
14:56:20 <persia> tristan: I think it's better to be a link, because people contributing presumably have to use gitlab to do so anyway...
14:56:35 <persia> laurence: Thanks for volunteering to clean this up.  I suspect it will make a significant difference.
14:56:54 <laurence> very welcome
14:56:55 <laurence> ok folks, going to wrap up the meeting soon..
14:56:59 <persia> (and for running the meeting, and volunteering for most of the rest of the actions as well)
14:57:00 <laurence> are there any final points?
14:57:38 <laurence> alright, then that's a wrap !
14:57:49 <laurence> thanks all!
14:57:51 <laurence> #endmeeting