14:04:11 <juergbi> #startmeeting Monthly Team Meeting
14:04:11 <GNOMie> Meeting started Tue Nov 14 14:04:11 2017 UTC.  The chair is juergbi. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:04:11 <GNOMie> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:04:25 <persia> o/
14:04:34 <tristan> yes persia ?
14:05:04 <persia> Most of the meetings I attend start with folk announcing presence after #startmeeting: is protocol here different?
14:05:32 <tristan> Aha, was not aware of this protocol sorry :)
14:05:32 <juergbi> fine with me
14:05:35 <juergbi> o/
14:05:39 <tristan> fine with me too o/
14:05:40 <tlater> o/
14:05:44 <ssam2> here
14:06:06 <jonathanmaw> I'm here, but I might be disappearing before the end
14:06:19 <juergbi> let's get to the first topic unless there is anything to discuss before
14:06:31 <tristan> Ok, not such a big crowd as last month...
14:06:31 <nexus> :p
14:06:38 <tristan> juergbi, I was thinking...
14:06:38 <persia> Unless GNOMie is very different than MeetBot/Mootbot, the presence announcement causes there to have been posted text, which lists the nick as an attendee in the summary, hence the protocol.
14:07:04 <juergbi> it is MeetBot, so yes, this applies
14:07:06 <tristan> lets start with a run down of the action points from last meeting no ?
14:07:17 <juergbi> sounds sensible
14:07:19 <tristan> should be quick, I'll try to summarize
14:07:37 <tristan> me to arrange meetbot -> juergbi instead did that
14:07:49 <tristan> I updated the buglist with blockers
14:07:58 <tristan> And we're down to a very slim count now
14:08:13 <tristan> raised issue for bst track, one of the last blockers
14:08:14 * persia encounrages use of #topic
14:08:35 <tristan> that's all I see in https://wiki.gnome.org/Projects/BuildStream/Monthly-Meeting/20171017
14:09:13 <tristan> Looks like we'd need laurence for that, so lets not dilly dally about the topic line I think for this time
14:09:29 <persia> tristan: #topic as a GNOMie command, not /topic
14:09:44 <persia> Makes the autogenerated minutes easier to read, etc.
14:10:16 <juergbi> #topic Features to land early in the next cycle
14:10:21 <juergbi> Suggested by: Tristan Van Berkom and Sander Striker (in the previous meeting)
14:11:24 <tristan> So, main huge order of business to land early in the cycle is subprojects / junctions (previously "Recursive Pipelines")
14:11:53 <juergbi> yes, this should be ready soon
14:12:06 <tristan> Sander is not present, I think he originally suggested this topic point
14:12:43 <juergbi> #info subprojects / junctions feature to land early in the next cycle
14:12:53 <tristan> So, that will be ready soon and I expect just in time, with the blockers which tlater has been working on - the recursive pipelines branch will not stagnate
14:13:39 <tristan> Which is good, it will add severe complexity to BuildStream, more so than any other feature I expect to land in 1.0 really
14:13:57 <tristan> but I hope it's the last very intrusive thing :)
14:14:12 <tristan> Anything to discuss specifically on that sub point ?
14:14:31 <juergbi> not from me
14:14:53 * tristan thinks this would be a good time for others who might have work which may conflict with it, to raise that, but probably not relevant this time around
14:15:15 * tlater isn't sure how much it will conflict much with my work
14:15:18 <tristan> So the next big thing which is close to landing, is incremental builds by Chandon
14:16:18 * tristan didnt think to invite explicitly cs_shadow, but looks like he was not expecting the meeting
14:16:47 <tristan> These are the first things *I* want to land
14:17:22 <juergbi> #info incremental build support is the next big thing close to landing
14:17:23 <tristan> Now would be the time for people to mention things they want to land in the next cycle, especially early in the next cycle
14:17:39 <tristan> Any takers ?
14:17:43 <ssam2> multiple cache support
14:17:49 <ssam2> which i am just beginning to work on now
14:17:49 <tlater> Event hooks
14:18:34 <ssam2> jonathanmaw is also looking at optional hard-errors on overlaps
14:18:40 <tristan> Ok ssam2, I dont recall specifically but, this particular feature does not expand the API surface correct ?
14:18:45 <tristan> except for config
14:18:51 <jonathanmaw> ssam2: yep
14:18:51 <ssam2> and perhaps CLI
14:19:09 <tristan> It does not specifically necessitate opening up the artifact format
14:19:12 <ssam2> but yes, I think we can fit it into a stable release
14:19:57 <tristan> ssam2, I dont think it's 1.0 material if that's what you mean, lets keep it post 1.0, just mostly curious about how close we are to really needing open artifact format
14:20:20 <ssam2> I mean post-1.0
14:20:25 <ssam2> pre-2.0 :-)
14:20:26 <tristan> welcome cs_shadow :)
14:20:30 <tristan> ssam2, yes :)
14:20:43 <ssam2> GPG signing of artifacts is still on my list as well
14:20:52 <tristan> cs_shadow, fwiw this is the monthly meeting, I pinged you here because you were online, some context here: https://wiki.gnome.org/Projects/BuildStream/Monthly-Meeting/20171114
14:21:17 <tristan> We're currently discussing features to land early in 1.1 dev cycle
14:21:24 <cs_shadow> Thanks! :)
14:21:51 <tristan> And, incremental builds as well as recursive pipelines I think are the first things to look at btw :)
14:22:11 <tristan> so, ssam2 says multiple artifact caches...
14:22:37 <tristan> tlater, event hooks, I'm not hugely concerned about; that will not add serious complexity really, so good stuff to have :)
14:23:08 <tristan> optional hard-errors on overlaps, is there a proposal out for that yet ?
14:23:26 <tristan> I know we discussed that before, just wondering if we have a reference point or design in progress
14:23:42 <ssam2> no, i have linked jonathanmaw to the IRC discussion but that's as far as it's gone I think
14:24:08 <tristan> Still, I doubt its severely complex
14:24:12 <jonathanmaw> tristan: I've added some comments in https://gitlab.com/BuildStream/buildstream/issues/114
14:24:25 <jonathanmaw> mostly a query about how it should work
14:24:41 <persia> Do we think overlap handling is something that needs to land early in the cycle?
14:24:47 <tristan> jonathanmaw, great
14:24:50 <persia> Or is it safe to land late?
14:25:01 <tristan> persia, I feel it's safe to land late
14:25:16 <jonathanmaw> that takes the pressure off :)
14:25:17 <tristan> it doesnt strike me as something immensely intrusive
14:25:33 <jonathanmaw> it might involve adding an option to project.conf
14:25:43 <jonathanmaw> and an addition to element metadata
14:25:49 <persia> That makes sense to me.  I also feel like event hooks could land later (although I'd like both soonest, because they seem fun to play with)
14:26:16 <tristan> jonathanmaw, that said, we *will* be following the freezes we've committed to in our last meeting
14:26:27 <persia> Whereas multiple cache support, incremental builds, subprojects/junctions, and artifact certification all seem like things that need to land early.
14:26:30 <tristan> But, remember that our 1.2 is not in February
14:26:45 <tristan> We also agreed that we are standing out for the first GNOME release
14:26:49 <tristan> giving us time to get in sync
14:27:10 <tristan> persia, agreed
14:27:28 <persia> Did I miss any big 1.2 features people want in that list?
14:28:05 <tristan> So the thing I want to think about least (the one which is a thorn in my side), is the GPG signing thing, mostly because I have strong feelings about how that should be done and havent liked the original proposals
14:28:12 <tristan> But I will try to swallow it :D
14:28:30 <ssam2> i have a feeling that we can do something closer to what you wanted, based on later discussions
14:28:30 <tristan> Was there a new proposal yet ? I think one is in the works ?
14:28:33 <persia> tristan: If you agree it needs to land early, yes, you can't delay thinking about it :p
14:28:56 <ssam2> i haven't done a new proposal, but i could do one which allowed for multiple keys, but a single signature per artifact
14:29:13 <ssam2> and the artifact is valid if any one of the trusted keys has signed an artifact
14:29:23 * persia is uncomfortable with single-signature-per-artifact, although it's better than no certification.
14:29:32 <ssam2> with that simplification, we should be able to integrate it in the UI as a first-class citizen
14:29:44 <ssam2> persia, you are the only person I've discussed this with who is uncomfortable with that
14:30:06 <persia> ssam2: From curiosity, is there a technical limitation that makes one signature easier?
14:30:19 <ssam2> no, it's about integrating it into the UI cleanly
14:30:25 <tristan> Into the UX
14:30:31 <tristan> in general yes
14:30:40 <persia> I can get more folk to make statements about certification to justify use cases, but I don't believe it makes sense to make technical choices based on popularity :)
14:31:12 <tristan> So, if signing is a buildstream thing, I want buildstream to do it, and enforce it, such that if a project is configured to do it, it cannot be circumvented implicitly
14:31:14 <ssam2> the internals of the feature are not really of interest, i'll implement it however people want
14:31:16 * jonathanmaw has to go now. I'll track down the notes later to see what I missed.
14:31:27 <persia> ssam2: I don't want to consume the meeting with this, but I'd like to understand the UI issue later.
14:31:31 <ssam2> ok
14:31:42 <tristan> I.e. circumvention of signing and verifying has to be an explicit activity (i.e. "Right now I dont care about verifying, explicitly")
14:32:20 <tristan> That is one thing; second, I am not averse to multiple signatures or keys
14:32:45 <tristan> But, I would much prefer that an initial implementation do things very well, automated and end to end
14:32:51 <ssam2> yes, the complexity with multiple signatures, is how does `bst build` know which combination of signatures should be considered enough to say "this artifact is trusted"
14:32:53 <tristan> not with a dependency of the server doing something
14:33:25 <ssam2> if we limit things to multiple keys, any one of which must sign the artifact, then the rules are obvious
14:33:30 <tristan> And, it should allow us to use http for artifact downloads, too, due to the added signing, https is unnecessary
14:34:07 <tristan> So, I would much prefer that an initial feature land, with least extensions possible, but do it very, very well
14:34:27 <juergbi> makes sense but probably best to discuss this further outside this meeting
14:34:31 <ssam2> yes
14:34:33 <tristan> and in the future, we can extend with features, such as; I want to sign something to say that "I've tested it" or whatever
14:34:33 <persia> juergbi: +1
14:34:34 <tristan> Agree
14:34:44 <ssam2> i will make a note to stop procrastinating on this feature though :-)
14:34:46 <tristan> I wanted to have a short run through because to me, it's the hottest topic
14:34:47 <juergbi> #info multiple cache support and GPG signing are further feature candidates to land early in the 1.1 dev cycle
14:34:53 <persia> I believe the current #topic is features to land early in the cycle.
14:34:56 <tristan> but indeed, we're not here to discuss the specifics of it
14:35:52 <juergbi> ssam2: shall i add an action point for a new signing proposal?
14:36:01 <persia> Do we want to #info event hooks and overlap handling as being later, or do the people working on those think they will land early anyway?
14:36:05 <tristan> Alright, I've also looked through my emails, Angelos has a thing about benchmarking which will also be very interesting
14:36:12 <ssam2> juergbi, yes please
14:36:25 <persia> tristan: Does it need to be early, or is late fine?
14:36:28 <tristan> But that will certainly not impact buildstream core in aggressive ways, so there is no critical hurry
14:36:45 <juergbi> #action ssam2 Work out new proposal for GPG signing
14:37:39 <juergbi> let's just note that these features may land later. they can still land early if ready
14:37:50 <tristan> Yes
14:38:19 <tristan> I suspect that there wont be issues, because next stable is... around just after GUADEC 2018
14:38:38 <juergbi> #info event hooks and error on overlap features may also land later in the cycle
14:38:41 <tristan> As per our last month meeting consensus, that we skip our first GNOME release
14:38:47 <juergbi> yes, will be a long cycle
14:39:16 <tristan> probably other unmentioned things have time to land too... so...
14:39:23 <tristan> awkward silence:
14:39:43 <tristan> <meaning, anyone want to add more to this point or shall we continue ?/>
14:39:55 <ssam2> nothing from me
14:40:02 <juergbi> let's move on then
14:40:08 <tristan> yes lets
14:40:12 <juergbi> #topic Feature acceptance policy
14:40:18 <juergbi> Suggested by: Tristan Van Berkom
14:40:23 <juergbi> Earlier on in BuildStream's development stages it was necessary and appropriate to land branches which incurred some side effects with other plans to fix things along the way, but at this stage this no longer makes sense - we need a stronger policy for ensuring that new features handle their edge cases and fail gracefully, have regression tests in place for this, and dont incur technical debt when initially landing in the master branch.
14:41:01 <tristan> so I was supposed to write up a tentative policy or such by now, but I have not, because I'm so lazy
14:41:16 <tristan> or, because I have to make our first GNOME dev release with BuildStream :)
14:41:32 <tristan> But there is a point, and while we're all here, I'd like to discuss
14:41:50 <tristan> I *need* to raise the bar of entry for landing feature branches in BuildStream
14:42:06 <juergbi> do you have tangible criteria in mind?
14:42:49 <tristan> One of them is, new features should come with regression tests which cover it at least pretty well
14:43:00 <tristan> that's pretty much a no brainer, and we're doing mostly this already
14:43:15 <juergbi> yes, makes sense
14:43:41 <tristan> Another is... that we should not be landing things which cause the user confusion, things which users will complain about
14:44:03 <tristan> Things which land, should have immediate value to the user base, and not depend on anything that *might* land later
14:44:26 <juergbi> #info new features should come with regression tests which cover it at least pretty well
14:44:29 <tristan> Sort of the point behind the GPG stuff too, first iteration should not be something complex that is only useful to a small vector of power users
14:45:01 <tristan> This is because, things like this *will* be perceived as bugs, and cause confusion
14:45:02 <juergbi> yes, sound sensible. interpretation of this may be subjective, of course
14:45:29 <tristan> And while too much stuff is landing at once, the unfinished stuff falls through the cracks and leaves me with technical debt
14:45:57 <tristan> or the "unpolished" stuff lets say, we've already set the bar fairly high
14:46:04 <tristan> and we already have a lot of bugs
14:46:16 <tristan> but I see people rushing on to do features; I need help with the bugs
14:46:22 <tristan> or it will get out of control fast
14:46:57 <juergbi> #info things which land should have immediate value to the user base, and not depend on anything that *might* land later
14:47:02 <tristan> To add to this policy, one thing that I've seen during the "golden days" of GTK+, back when we were really good at doing stable APIs...
14:47:09 <ssam2> i think that aiming for branches to be bug-free when merged isn't really practical
14:47:18 <ssam2> more that people should take responsibility for fixing bugs in features they landed
14:47:25 <tristan> Is basic policy that; I need to depend on people who land branches, to be around and dedicate time to fix fallout
14:47:35 <tristan> ssam2, exactly ++
14:48:00 <tristan> how this policy works in practice however, is difficult to exercise
14:48:32 <ssam2> yes, it's hard to legislate. all we can really do is make sure people are aware of the bugs
14:48:33 <juergbi> yes but stating this clearly as policy may already help
14:48:37 <tristan> in general it means that it's hit and miss; we should not be accepting feature branches coming from individuals who have yet to clean up something that is broken
14:49:04 <tristan> juergbi, indeed
14:49:23 <tristan> So, maybe what we need here is a place to coherently communicate this policy, first of all
14:49:37 <juergbi> #info need to be able to depend on people who land branches, to be around and dedicate time to fix fallout
14:49:41 <tristan> Maybe I need to do a complete rewrite of HACKING.rst, that may be a good step
14:51:58 <tristan> At the same time, you can all take this as a defensive, paranoid move on my part; to get the point across that I'm going to try harder to not let stuff fall through the cracks in the first place :)
14:51:58 <tristan> but, nobody's perfect
14:51:58 <tristan> Anyway, I recognize this as a growing problem, we're accumulating more critical bugs, stack traces, and user inconveniences that will throw people off
14:51:58 <tristan> it's a problem we have to solve
14:51:58 <juergbi> ok :) do you want an action item for HACKING.rst?
14:51:58 <tristan> any other ideas ?
14:51:58 <tristan> juergbi, Sure :)
14:51:58 <tlater> tristan: We could make use of gitlab's features for this
14:51:58 <tlater> Assign people to bugs they caused
14:51:59 <tlater> Or probably caused
14:52:01 <tlater> Makes communication easier
14:52:21 * tlater thinks this is largely ignored atm
14:52:36 <ssam2> yes, people should get an email when assigned to a bug
14:52:40 <tristan> Yes, that might be alright - I dont personally like "assignment" attributes on bugs
14:52:44 <juergbi> #action tristan Update HACKING.rst with feature acceptance policy
14:52:48 <tristan> but if they can help communicate this, it can help
14:53:19 <juergbi> assigning bugs to the feature owner sounds useful to me
14:53:34 <hashpling> Hmm
14:53:37 <tristan> nor do I like to see "eta" or such, this is to me a database of everything that is wrong or could be better, until they are rejected of fixed
14:53:50 <tristan> So, its a matter of perception, not a management tool
14:53:51 <hashpling> On the other hand assigning bugs can discourage others from tackling them.
14:53:59 <tristan> indeed
14:54:09 <hashpling> And how long to you wait on a lapsed feature submitter before you re-assign?
14:54:51 <tristan> Right, that is also a good point; for fly by or first time contributors, seeing somebody assigned on gitlab communicates to them, that somebody is working on it right now
14:54:55 <tristan> at least I expect that perception
14:55:16 <ssam2> we could perhaps use mentions rather than assignment
14:55:26 <tristan> So, maybe we should not do this, and instead add a comment which @pings the contributor by their handle and asks them if this might be fallout from their branch or such
14:55:35 <ssam2> yeah
14:55:42 <ssam2> gitlab should also automatically email when we do that
14:55:55 <tristan> yes, I prefer this approach
14:56:14 <hashpling> If they can be encouraged to assign themselves, that would probably be good, too.
14:56:35 <juergbi> yes, i agree
14:56:42 <tristan> Yes, self assignment is good
14:56:56 <tristan> I will look back on these notes to draw inspiration for a new HACKING.rst
14:57:31 * hashpling returns to lurking
14:58:06 <tristan> It may turn out that the bug list needs triage, in cases where someone self assigns and disappears, but not a huge deal
14:58:16 <tristan> if something is really important, people will notice and want to fix it
14:58:58 <juergbi> #info mention feature author in relevant bug report and encourage them to assign the bug to themselves, if they start working on it
14:59:42 <tristan> So, A.) decently well regression tested, B.) Smaller atomic branches which do the smallest part of the feature but very well and conveniently (later iterations can expand on features) and C.) Take ownership of features, be responsible for technical debt
15:00:07 <tristan> basically, plus some ideas about triage and a new HACKING.rst
15:00:16 <tristan> Does that sum it up ?
15:00:37 <juergbi> yes, i think so
15:00:41 <juergbi> #info smaller atomic branches which do the smallest part of the feature but very well and conveniently (later iterations can expand on features)
15:01:17 <juergbi> anything else to add to this topic?
15:01:29 <tristan> I think I feel better now :)
15:01:33 <juergbi> :)
15:01:53 <persia> For clarity, by "take ownership", we mean self-assignment and assignments for work being actively done (rather than to be potentially done in the future)?
15:02:15 <juergbi> also in general to stay around for fallout
15:02:19 <juergbi> don't land a feature and disappear
15:02:40 <tristan> persia, we mean, those responsible for landing a non trivial feature branch, should be sticking around and present, and fixing fallout from those
15:02:42 <persia> Right.  That all makes sense.  Since (A) and (B) got #info, I think (C) deserves one.  Other than that, I'm happy with this topic.
15:02:47 <tristan> indeed, not disappear
15:03:01 <juergbi> i already did an info for that point earlier
15:03:22 <tristan> yes, there is one
15:03:38 <persia> Ah, for the not disappear part.  I somehow lost track that self-assingment was related when trying to match backscroll to minutes.  Apologies for the noise.
15:03:51 <juergbi> nw
15:04:02 <juergbi> anything else?
15:04:40 <juergbi> #topic Any other business
15:04:49 <tristan> juergbi, are you sure we got the meeting time right ?
15:04:54 <tristan> heh
15:05:03 <juergbi> it was always announced as 14:00 UTC
15:05:07 <sstriker> Yes, you did
15:05:22 <tristan> sstriker, as in, it's already been an hour, and we're finishing up now
15:05:46 <tristan> Ok, good; I didnt want to leave you out sstriker :)
15:06:15 <sstriker> :)
15:06:24 <juergbi> does anyone have any points that weren't in the agenda?
15:07:28 <juergbi> next meeting is planned for December 12, 14:00 UTC. any objections?
15:07:37 <tristan> I think that's it; policy on how to close the meetings might be decided
15:08:08 <tristan> I.e., we might decide to let the last "Any other points" point open, and close the logger at an arbitrary time well after the meeting
15:08:10 <persia> tristan: GNOMie has a magic phrase the chair uses to close, but anything after close misses the minutes.
15:08:29 <tristan> Or we might close it right away and let any remaining discussion in this channel be "off record"
15:08:30 <persia> juergbi: That matches my records for the next meeting time, if you're looking for confirmation.
15:08:42 <juergbi> ta
15:08:57 * tristan doesnt mind, either way :)
15:09:04 <persia> tristan: I think it makes sense to end the meeting when nobody adds more topics for a while.
15:09:05 <juergbi> #info Next meeting planned for Tuesday, December 12, 14:00 UTC
15:09:15 <juergbi> ok, let's do that, then
15:09:15 * persia only had "confirm the next meeting time" as an additional agenda item
15:09:38 <juergbi> thanks everyone for attending
15:09:40 <juergbi> #endmeeting