14:02:10 <laurence> #startmeeting BuildStream Monthly irc Team Meeting
14:02:10 <GNOMie> Meeting started Tue Feb 19 14:02:10 2019 UTC.  The chair is laurence. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:10 <GNOMie> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:02:10 <GNOMie> The meeting name has been set to 'buildstream_monthly_irc_team_meeting'
14:02:29 <laurence> ok, anyone else here and wants to join in?
14:02:51 <aevri> o/
14:02:56 <jjardon> o/
14:03:04 <laurence> ahoy, good to see you guys :)
14:03:31 <laurence> ok let's get started
14:03:36 <adds68> can we lurk? o/
14:03:42 <tristan> of course
14:03:45 <adds68> :)
14:03:49 <laurence> all are welcome to lurk :)
14:03:58 <laurence> #topic - Actions from last meeting
14:04:22 <laurence> laurence and tristan to ensure we discuss at the gathering how we can get more folks attending this meeting
14:04:33 <laurence> tristan, we completely forgot to discuss this...
14:04:36 <tristan> I think we failed on that !
14:04:42 <tristan> yes indeed :-S
14:04:52 <laurence> ok, let's move on then :)
14:04:57 <tristan> But aevri and gokcennurlu came, we have more balance :)
14:05:02 <aevri> :)
14:05:05 <laurence> hopefully a productive meeting today will also further encourage attendance
14:05:17 <laurence> ok that was the only action
14:05:24 <laurence> so moving on to the topic I proposed
14:05:37 <laurence> #topic Removal of 1.2 from Debian Buster - https://gitlab.com/BuildStream/buildstream/issues/901
14:06:05 <laurence> I raised the gitlab issue because I thought it might be something we wanted to action sooner rather than later
14:06:22 <laurence> but I'm not sure how others feel? so wanted to raise it here
14:06:25 <laurence> is it a big deal?
14:06:26 * Kinnison believes that the rough consensus now is that the project will make it clear we're not supporting 1.2 long-term and then leave it to the distro devs to decide for themselves
14:06:32 <tristan> As I commented on the issue, I don't see how it can be productive to discourage use of the only stable version, especially without any promise of reliability at any specific point in the future
14:06:38 <tristan> So I propose we just close that
14:06:48 <Kinnison> +1 to just closing it
14:07:00 <laurence> tristan, sorry I missed your comment there
14:07:09 <laurence> ok, I will close
14:07:14 <laurence> however
14:07:36 <jjardon> I'd say use that issue or open a new one to clearly announce the plans in the website
14:07:47 <jjardon> So distros can decide
14:07:48 <tristan> Stake holders of currently involved companies have clearly expressed they would not invest in development or support
14:07:55 <laurence> could we do a little more to announce our plans regarding what versions we will maintain and also the move to the new release cycle?
14:08:00 <aevri> I agree that we should make our position publicly clear.
14:08:04 <tristan> So it makes sense to communicate that
14:08:09 <tristan> aevri +1
14:08:26 <laurence> ok, website update and specific mailing list post are two ways to do that - any more?
14:08:45 <adds68> blog post from tristan ?
14:08:47 <jjardon> That should be enough I think
14:08:55 <laurence> (most of the interested parties were at the gathering, of course)
14:09:18 <laurence> OK, I don't mind taking the action for both of those things
14:09:26 <tristan> I am due for a blog as well yes, I can volunteer for that
14:09:53 <aevri> Maybe we should also put that in the readme, perhaps next to the handy new 'distros' widget.
14:10:15 <jjardon> +1
14:10:16 <laurence> #action laurence to update the website and post to the list clearly outlining our position re support for bst versions and the new appraoch to 2.0 as a stable release
14:10:32 <laurence> #action tristan van berkom to write a blog post to the same effect
14:10:45 <laurence> jjardon, want to add to the README?
14:10:49 <jjardon> Sure
14:10:49 <laurence> you love adding stuff to READMEs
14:10:52 <laurence> cheers :)
14:11:02 <laurence> #action jjardon to add to the README to the same effect
14:11:16 <laurence> ok, any more before we move on?
14:11:30 <aevri> I wonder if we all agree on what the position is
14:11:58 <aevri> Will there be a 'canonical' version published first for us to agree on? I have a rough impression from the gathering.
14:12:15 <laurence> here are the notes from the event - https://docs.google.com/document/d/1bENn0gIHDPyTXaRwqSoA2F11gn55vvWLB7qMIe3Pk1U/edit
14:12:18 <tristan> (A) We are focusing on a new version of BuildStream which will not be backwards compatible with 1.x, and we don't know when that will stablize
14:12:21 <laurence> I was planning to crib from there
14:12:42 <tristan> (B) We are not investing in support of the existing 1.2 branch, patches welcome ?
14:12:45 <aevri> ok good idea, as long as we don't end up with 3 differing versions :D
14:12:48 <tristan> aevri, Approximately ?
14:12:56 <aevri> yup that looks good to me
14:13:04 <aevri> thanks!
14:13:24 <laurence> i'll get you guys to review it before i post it publicly
14:13:31 <jjardon> aevri: I will probably simply link to the website ;)
14:13:43 <aevri> sounds good
14:13:51 <laurence> ok, moving on...
14:14:08 <laurence> #topic Can we retire buildstream-notifications-list@ ?
14:14:23 <laurence> +1 from me, never found it useful
14:14:41 <tristan> It doesnt send anything, except for bounces to my inbox
14:14:47 <aevri> +1 from me, never looked at it
14:14:52 <juergbi> +1
14:14:54 <sstriker> +1 - the intent was to just have a -commits@ list, but this thing is not that
14:14:54 <jjardon> I do not use it
14:14:56 <Kinnison> +0 from me, never even knew it existed
14:15:41 <laurence> ok who has the permissions to shut it down? possibly toscalix ?
14:16:05 <laurence> I can take the action to find out anyway and shut it down outsdie of this meeting
14:16:10 <sstriker> I would hope anyone with admin in the buildstream org can stop the traffic
14:16:32 <laurence> #action laurence to make sure we shut down the buildstream-notifications-list@
14:16:47 <laurence> moving onto the next point:
14:16:48 <tristan> I can probably shut it down, since I have the bounces, and the gitlab has to stop sending the notifications, I think a few of us can do that in settings
14:17:13 <laurence> alright great, let's do so after this :)
14:17:36 <laurence> #topic developers having the 'watch' notification set on gitlab
14:17:37 <tristan> This one does not summarize well, I sort of expected the topic to be about notifications and developer feedback loop in general
14:17:49 <tristan> But for a summary: https://mail.gnome.org/archives/buildstream-list/2019-February/msg00045.html
14:18:37 <laurence> both of the points are about the feedback loop, yes, perhaps that should have been the topic. Anyway i have to confess i'm not 100% on the meanigng of your second point
14:18:41 <laurence> tristan, ^
14:18:54 <tristan> I realize that many people in the project might find this immaterial and pointless if you have not worked on community driven projects before, maybe people are comfortable working the way we do
14:19:04 <tristan> But I see this as our biggest problem right now
14:19:30 <tristan> We have a workflow where developers are not included in the feedback loop, we don't all get email notifications when issues come in
14:20:01 <tristan> And this is preventing people from becoming proactive, which in turn prevents people from stepping up into leadership positions in the project
14:20:06 <tristan> Which is unhealthy
14:20:38 <juergbi> Custom GitLab notifications help to some extent
14:20:58 <tristan> I did look at that and found nothing useful
14:21:03 <sstriker> I'm not sure that is the case.  I do think that we've seen more people stepping up
14:21:10 <tristan> Honestly, it just lets you filter by type of notification
14:21:12 <juergbi> at least I could disable 'Reassign' notifications
14:22:05 <tristan> sstriker, I agree to some extent, but this could be improved a lot if developers *could* reasonably listen to all project events
14:22:21 <tristan> but the bar is too high with the amount of notifications, not all of them being relevant
14:22:35 <sstriker> tristan, what is the measure that you are looking to improve?  Responsiveness to issues?  Or something else?  Because I don't think that measure translates directly to stepping up to leadership roles or not.
14:23:38 <tristan> sstriker, For one thing, I am hoping to break the workflow where a small hand full of people care about the issues, curate what is important and dispatch work items
14:24:01 <tristan> I think this is not a great thing for morale in a project stand point (but can be okay from a private team perspective)
14:24:30 <tristan> If developers feel empowered to be a part of that process, it means receiving the notifications
14:24:41 <tristan> I think, or maybe there is another way to do it.
14:25:36 * tristan feels that this all worked way better with bugzilla, where all the issue and patch review details were in the same record, and you only receive meaningful updates
14:25:47 <aevri> I'm personally tempted to experiment with a 'polling' workflow on the 'issue events' tab here: https://gitlab.com/BuildStream/buildstream/activity
14:25:47 <aevri> I have my GitLab alerts set to 'participate'.
14:25:47 <aevri> The page shows you issues and MRs opening and closing, this lets me participate in new things of interest, and then get notifications by email on them after that.
14:25:47 <aevri> I'll let you know how I get on :)
14:27:16 <Kinnison> aevri: sounds good to me
14:27:22 <sstriker> I think that the workflow you describe is parallel to other workflows.  I think the thing to address in what you outlined as "care about the issues, curate what is important and dispatch work items" is the final part.
14:28:02 <sstriker> Triaging _can_ be a separate thing.
14:28:17 <tristan> sstriker, I'll add one thing to that; in my (personal) experience with Glade or GTK+, I have seen occasional contributors start to care and speak up in the project more after the moment they subscribed to the issues
14:28:31 <tristan> It makes you feel equal and part of the team, that is what I am aiming for
14:29:04 <sstriker> I've seen this in other projects as well; not everyone is looking at the issues, while some are more focussed on it.
14:30:52 <sstriker> @tristan: ok, I see what you are trying to aim for.  I'm not sure that having everyone look at the issues is going to achieve that.  However, when plans for changes come out, or issues with a plan of attack, then everyone should feel free to speak up and contribute without feeling "unequal"
14:31:46 <tristan> sstriker, If the opportunity to watch all of the issues comes at a low enough barrier of entry, it helps us spot the people who *are* being extra proactive
14:32:08 <tristan> It is not about forcing everyone, but making it more friendly and easy to be a part of the process
14:33:54 <sstriker> +1 on making it less expensive to follow issues
14:34:46 <tristan> On a practical side, I always want to know if someone is making changes which potentially overlap with mine, I can achieve this easily if I can always keep track of the issues
14:35:54 <laurence> i don't know how we achieve this. Outlaw WIP MRs? That'll help to reduce email notifications. But people find that useful for feedback.
14:36:05 <tristan> Anyway I think we may have exhausted this point, I would *like* to have a situation where it is easy to follow all the issues and relevant real MRs, and at least ask that people *try* being subscribed to it
14:36:30 <tristan> But we cannot do that unless the notification stream is relatively low enough volume, without distortion
14:36:41 <aevri> aside: if you want an RSS version of the activity page, I have a test app publishing this feed and more:
14:36:41 <aevri> https://sheltered-hollows-24460.herokuapp.com/issue
14:36:42 <aevri> I made it because the GitLab feed oddly uses cookies to determine which feed comes from the feed URL - I couldn't make my reader work with that.
14:36:42 <aevri> If there's interest, I can make an ML post.
14:37:07 <sstriker> @tristan: so potentially more streams, but topical
14:37:36 <laurence> #summary gitlab sends a lot of email notifications, should reduce this but improve quality of updates to encourage more developer engagement throughout the project
14:38:13 <tristan> sstriker, I want to have a summary of everything that is really going on, topical is like "participate", only what you subscribed to
14:39:09 <tristan> I would personally trade away long standing WIP MRs for this but think there should be a better way, or a different way to achieve what we do with long standing WIP MRs
14:40:21 <sstriker> Sounds like more discussion on this topic - maybe park?
14:40:23 <aevri> When you say summary, it makes me think of a weekly digest of things going on. Perhaps there's something in that.
14:40:43 <Kinnison> A "this week in BuildStream" type affair?
14:40:50 <aevri> Could be!
14:40:56 <tristan> aevri, erm, I want it all to be honest, and I want to know right away when an issue has been filed
14:41:44 <tristan> Anyway, I agree we have to park this because I don't have a solution which does not involve trading away precious WIP MRs
14:41:49 <laurence> I'll have a look at gitlab and see if we can disable notifications on the project side rather than per user, that would help
14:41:54 <laurence> but yeah, let's park it and move on
14:42:12 <laurence> #action laurence to have a look at gitlab and see if we can disable notifications on the project side rather than per user, to remove WIP MR notifications
14:42:34 <laurence> ok, next topic is the last topic - Any Other Business
14:42:40 <laurence> does anyone have any points to raise?
14:44:08 <aevri> I was wondering about a rule of thumb for cleaning up MRs
14:44:12 <laurence> I do have a point actually
14:44:14 <laurence> about MRs
14:44:19 <laurence> aevri, ah, snap :)
14:44:23 <laurence> you go first
14:44:34 <aevri> I wonder if we could agree to WIP things which have no updates for a month or more
14:44:36 <aevri> Thanks!
14:44:58 <Kinnison> s/WIP/close/ and I'm with you
14:45:20 <aevri> Yup - I'm thinking some boilerplate to update the MR with
14:45:33 * tristan agrees close is better
14:45:38 <laurence> yes I have focused on closing / updating the non WIP ones for now
14:45:47 <laurence> you can filter via WIP or not WIP
14:45:50 <aevri> I think wip might be better in some cases, but I'm ok with either :)
14:46:13 <laurence> would like to get to have as few open MRs as possible
14:46:14 <juergbi> maybe we could use a special label for those
14:46:16 <tristan> The text should of course welcome the contributor to reopen with a new revision if they still want to work on it
14:46:18 <Kinnison> I think WIP non-WIP after a month, and then close WIP after a month
14:46:24 <juergbi> such that we can find MRs that have been closed due to inactivity
14:46:24 <Kinnison> tristan: absolutely
14:46:41 <tristan> And maybe we should also discriminate against closing MRs which have had no action because of lack of reviewers
14:46:42 <tristan> ?
14:46:46 <laurence> that's what I was doing, yeah
14:47:14 * tristan thinks what laurence has been doing last couple of days is really correct yes
14:47:17 <Kinnison> tristan: yeah, If an MR is ready, but the lack of activity is a lack of reviewing, that shouldn't be a candidate for closing
14:47:38 <laurence> I think the label and the policy of WIPing/closing after a month is also good
14:47:47 <laurence> i don't mind taking that action
14:48:01 <laurence> i think we all agree here how to approach this
14:48:17 <tristan> laurence, in that case, I think that action possibly comes with an update to CONTRIBUTING.rst ?
14:48:29 <laurence> #topic Policy for closing MRs or making them WIP
14:48:30 <laurence> tristan, agree
14:49:00 <aevri> I found this a difficult one to ask to close, as per juergbi: https://gitlab.com/BuildStream/buildstream/merge_requests/671
14:49:41 <aevri> In the ML, Tiago also complained about lack of reviews and multiple rebases. Hopefully this isn't something that happens to reviews often though :)
14:49:44 <laurence> #summary we want as few MRs are possible, so for MRs that go stale, the rule of thumb policy should be to WIP a non-WIP after a month, and then close WIP after a month
14:49:52 <aevri> Sounds good
14:50:13 <laurence> #action laurence to communicate this, update CONTRIBUTING and create a label for MRs that were closed due to lack of activity
14:50:19 <laurence> maybe call it 'stale'
14:50:20 <tristan> aevri, That was an unfortunate scenario in the midst of a release yes :-S
14:51:55 <laurence> I do think we are much much better at timely responses / reviews since then, I really do
14:51:57 <aevri> :-S I think the rule of thumb will help us not drag those out anyways
14:52:14 <laurence> there are no MRs stale due to lack of review
14:52:21 <aevri> nice
14:53:03 <laurence> as it happens that specific MR is in the performance backlog for us to analyse at some point with Ben :)
14:53:11 <laurence> OK, I think that's nearly everything....
14:53:21 <adds68> can i mention a few small things?
14:53:21 <laurence> are there any final points before we close off this meeting?
14:53:26 <laurence> adds68, yes, pls do
14:53:49 <adds68> can we make the website point to BuildStream/buildstream instead of BuildStream as it's confusing
14:54:10 <laurence> can you give more context?
14:54:25 <adds68> https://buildstream.build/
14:54:29 <adds68> If you click "source"
14:54:30 <tristan> The "source" link I think he is referring to
14:54:33 <tristan> adds68, +1
14:54:48 <tristan> adds68, I think that kind of change is very easy to push though :)
14:54:55 <tristan> uncontroversial
14:55:01 <adds68> ack, i'll do that later then
14:55:15 <adds68> Is there also any need for a nosoftware repo, when we have a wiki?
14:55:28 <laurence> oh, point to the buildstream repo and now the group, i see.
14:55:32 <laurence> not*
14:55:33 <adds68> laurence, yea
14:56:46 <adds68> Finally can we upload the new logo emblem to gitlab: https://gitlab.com/BuildStream/buildstream/wikis/logo :D
14:56:52 <laurence> i have no strong feelings on #nossoftware
14:57:08 <laurence> yes I'll do the logo later today (if no-one objects)
14:57:17 <sstriker> +1 on retiring nosoftware - don't think the majority ever looks there
14:57:28 <tristan> adds68, regarding nosoftware, I think we probably need to consolidate where things go there and some effort needs to be made to look through it, see what is important to migrate to places like, say; the CONTRIBUTING.rst
14:57:32 <adds68> \o/ anything useful should be in the wiki IMO
14:57:40 <tristan> or the wiki
14:57:41 <adds68> tristan, +1
14:57:52 <adds68> thats all from me :)
14:58:14 <laurence> i think the wiki is a bit of a 'last resort' for a lot of stuff, actually
14:58:14 <sstriker> in the wiki or the main repo, or the website, but not another repo
14:58:20 * tristan thinks that the coding guidelines should move into a separate file from CONTRIBUTING as it is now growing a lot, but I don't think we need to discuss it in the meeting :)
14:58:53 <adds68> sstriker, maybe in the wiki, and link to the wiki from the website
14:59:01 <adds68> gitlab should be central trusted source IMO
14:59:37 <sstriker> @adds68, can just be in the website in that case.  why have a wiki as another place to look?
14:59:50 <sstriker> anyway, straying OT
15:00:13 <adds68> sstriker, no strong opinion, just find gitlab wiki easier to use
15:00:15 <adds68> _o_
15:00:19 <laurence> alright, last orders is over, closing time....
15:00:28 <laurence> thanks for attending, see you next time
15:00:30 <laurence> #endmeeting