14:02:40 <laurence> #startmeeting buildstream monthly irc team meeting
14:02:40 <GNOMie> Meeting started Tue Mar 19 14:02:40 2019 UTC.  The chair is laurence. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:40 <GNOMie> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:02:40 <GNOMie> The meeting name has been set to 'buildstream_monthly_irc_team_meeting'
14:03:02 <laurence> #topic actions from previous meeting
14:03:13 <laurence> 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:03:13 <laurence> tristan van berkom to write a blog post to the same effect
14:03:27 <laurence> all done, Tristan wrote a blog post, I wrote to the list and added a news entry to the website (where I just cribbed from Tristan's blog post) - https://buildstream.build/news.html
14:03:53 <laurence> there was then another action for jjardon to add to the README to the same effect
14:04:00 <laurence> but honestly i don't think we need this
14:04:19 <laurence> with the above in mind - any objections, let me know and me or jjardon can update it
14:04:33 <tristan> I think the readme can stay clear of too much policy
14:04:46 <laurence> great, thanks. next action was...
14:04:49 <laurence> laurence to get the buildstream-notifications-list shut down
14:04:58 <laurence> this is now inactive and not operating, I've also raised a ticket with GNOME sysadmins for them to close it off at their end - https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/108
14:05:17 <laurence> and Andrea Veri has done so
14:05:23 <laurence> so all good there
14:05:36 <laurence> next 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:05:41 * tristan is happy to not receive 20/30 emails for bounces every day :)
14:05:47 <laurence> i looked into this and commented on an already open ticket with gitlab upstream - https://gitlab.com/gitlab-org/gitlab-ce/issues/50020
14:06:05 <laurence> but honestly I think we have little chance, even if we wrote the patch ourselves
14:06:55 <laurence> toscalix raised a good point to me in a private chat: gitlab has a lot more feature requests in their backlog than they can possibly handle, I think
14:07:23 <tristan> I suppose we'll have to brew our own approaches - the main thing I am after is getting core developers more involved in the entire chain of custody of issue reports
14:07:34 <tristan> maybe in 2019 email is not the preferred way of doing this anymore
14:08:16 <laurence> yeah, i don't know the answer right now
14:08:18 <persia> I usually hear "dashboards" when people are talking about that sort of thing these days.
14:08:34 <persia> Dunno quite what that might mean in a buildstream/gitlab context
14:08:35 <laurence> the next action is in a way linked to the previous one:
14:08:38 <laurence> laurence to communicate stale MR policy, update CONTRIBUTING and create a label for MRs that were closed due to lack of activity maybe call it 'stale'
14:08:55 <laurence> I did this and have been making stale MRs into WIP
14:09:12 <laurence> hopefully helps reduce cognitive overhead for anyone looking through the backlog of MRs
14:09:32 <laurence> we still have a load of stale WIP MRs, I'll get around to closing them down as well
14:09:57 <laurence> It's a double edged sword in a way....i worry about creating noise in doing it...but i think it's justified, to be honest
14:10:37 <tristan> Mass bug closing every 6 months or so has been a regular occurrence with GTK+ for example
14:10:47 <aevri> Yeah I think the improved appearance of the list makes it worth it.
14:10:48 <tristan> People who care about things will reopen stale things
14:11:02 <laurence> all true
14:11:07 <laurence> ok, that's the end of the actions
14:11:15 <laurence> thanks for bearing with me there :)
14:11:37 <laurence> #agreed all actions from previous meeting are closed off
14:11:44 <laurence> moving onto the next topic
14:12:16 <laurence> #topic hackfests: next one and improved communication about it
14:12:44 <tristan> So, I realize that it can be tough, seeing as we have *a lot* of meetings per year
14:12:49 <persia> Are we talking about just a hackfest or another gathering or both?
14:13:01 <tristan> But I think it would be reasonable to make one of them more accessible
14:13:13 <tristan> persia, Either, I think they are the same loosely speaking
14:13:40 <tristan> The problem is that we organize them so last minute that external contributors dont get the chance to plan to attend
14:13:42 <laurence> in Manchester in October we agreed to meet before releases, making 2 or 3 gatherings per year, irrc - but there's no release on the horizon for a year or so now (not stable anyway)
14:13:55 <laurence> +1 to organising it 2 or 3 months in advance
14:14:07 <laurence> not sure much longer makes any sense
14:14:10 <tristan> I think that's not really enough...
14:14:25 <tristan> Well, I think we have to be sure of the date & location at least 3 months in advance
14:14:44 <tristan> But if the effort is much, I think we can do it for only one of the hackfests per year
14:14:56 <tristan> At least that would be great
14:15:12 <tristan> And best if it were one that was collocated with either GUADEC or FOSDEM
14:16:06 <tristan> Theres not much we can do in this meeting, I just wanted to make it clear I'm not asking for the moon :)
14:16:16 <persia> Or at least nearby.  FOSDEM fringe events sometimes happen on the other side of town and/or in the next town over.  Basically anywhere close enough that one doesn't need to change lodgings.
14:16:26 <aevri> Aha, "GUADEC 2019 to be in Thessaloniki, Greece", 23rd to 28th of August. https://www.gnome.org/news/2018/09/guadec-2019-announcement/
14:16:41 <tristan> We meet a lot, if at least one time a year we could organize it well in advance, then people have a chance to attend
14:16:42 <laurence> What we could do is agree the next one. We don't have anything in the calendar right now and we should start to get the ball rolling
14:16:53 <tristan> Right
14:17:10 <laurence> And I'm happy to organise the next gathering
14:17:26 <tristan> I can speak with travel committee and do the wiki parts of making it accessible to GNOME folks
14:17:39 <laurence> But I cannot attend GUADEC this year (it keeps clashing with summer weddings)
14:18:48 <aevri> Me neither - also a Summer Wedding.
14:19:27 <tristan> Ok well, let's keep it in mind and try to think of the best venue for attendance our usual suspects
14:19:49 <tristan> I think there are some pretty cool conferences in germany around september I would like to go to
14:22:07 <valentind> All Systems Go
14:22:29 <aevri> I expect we at Bloomberg would be happy to host in London again this year too.
14:22:47 <laurence> I wonder if we want one before August (GUADEC) / September?
14:23:00 <laurence> GUADEC is 5 months away
14:24:35 <laurence> anyway, I think that I can discuss the best dates for the next gathering outside of this meeting with all the relevant people
14:24:50 <laurence> #action laurence to start to firm up the gathering schedule for the project
14:25:00 <tristan> Yeah I think we cannot really have a conclusion on that in the context of a meeting :)
14:25:25 <laurence> #agreed need to have at least one event a year that is in the diary 3 (or even more ) months in advance, to try to increase hackers from GNOME /FDO
14:25:41 <laurence> and anywhere else, for that matter
14:25:50 <tristan> :D
14:25:52 <laurence> ok, moving onto AOB
14:26:26 <laurence> I have one point - about this meeting bot, do we know set it up? I had some issues with it last time
14:26:32 <laurence> juergbi, yourself, iirc?
14:26:33 <jjardon> o/
14:26:51 <juergbi> I asked for it to be setup
14:27:00 <laurence> jjardon, great, ok if i get your help to de-bug it after this meeting?
14:27:03 <laurence> juergbi, ok, thanks
14:27:45 <tristan> did jjardon have something to raise ?
14:27:54 <jjardon> Yup
14:27:56 * tristan wasnt sure if it was an answer to laurence
14:28:14 <laurence> I think it was to me, yeah :)
14:28:16 <jjardon> laurence: I had a point, I know nothing about the bot sorry
14:28:23 <tristan> heh
14:28:24 <laurence> Oh, I was wrong, ha
14:28:40 <jjardon> About https://gitlab.gnome.org/GNOME/gnome-build-meta/issues/136#note_462461 ; do we still discourage packing of bst-external in fedora?
14:28:59 <tristan> I think we do discourage packaging of bst-external
14:29:15 <tristan> jjardon, bst-external has never had any guarantees of stability
14:29:42 <jjardon> It's still packaged by other distros
14:29:55 <tristan> jjardon, I think that even if we want something in distributions to work with bst-1.2, we probably want it to be something else
14:29:59 <tristan> Oh really ?
14:30:06 <tristan> Ouch, bad messaging I guess :-S
14:30:44 <jjardon> https://buildstream.build/install.html
14:31:10 <tristan> What is AUR ?
14:31:12 <jjardon> Ok, we need improve docs in the gnome side then
14:31:19 <tristan> Also, why do we have that in our website ?
14:31:24 <jjardon> Also in the buildstream side
14:31:43 <tristan> I mean... showing that it is available on certain distros looks like an encouragement to package bst-external
14:33:17 <tristan> jjardon, By the looks of that table, it is only packaged in AUR (don't know what that is), so maybe we can ensure it doesnt happen elsewhere
14:33:41 <jjardon> It's packeged in all the distros listed there
14:33:43 <tristan> We can remove the table and improve our messaging around bst-external
14:34:00 <jjardon> Some of them doesn't have the latest that's why is red
14:34:01 <tristan> really ?! Oh I thought red meant "its not there but should be"
14:34:05 <tristan> Ouch okay
14:34:25 <valentind> The red color is for older version I think
14:34:31 <tristan> Well, that changes things, I guess that might mean we implicitly slipped into blessing bst-external as "stable"
14:34:37 <aevri> It seems the horse has already left the stable.
14:34:52 <laurence> i did not even know bst-external had numbered releases
14:35:01 <laurence> or, versions, anyway
14:35:33 <tristan> In that case - what I think we need to do is freeze bst-external development, avoiding headaches
14:35:51 <tristan> For master, there is already a plan in place for migrating plugins, which I have to write back to the list about
14:35:53 <persia> That isn't sufficient to block packaging: lots of unversioned software is packaged (with false versions like 0.0.date).  Need to be clear about messaging.
14:36:20 <jjardon> You can not do that, really; we need patches for flatpak and git_tag plugings
14:36:36 <jjardon> Both in fdsk and GNOME
14:36:43 <tristan> jjardon, Right, and for bst-1.2, we can migrate what we need into something else
14:36:51 <laurence> #topic bst-external packaging
14:37:20 <tristan> jjardon, that way if people accidentally start using bst-external, they will have something that doesnt improve, but at least doesnt break their projects
14:37:32 <jjardon> Ok , what is the plan for that?
14:37:44 <tristan> Well, we are making it right now :)
14:38:00 <tristan> We only just found out that people are packaging it, or at least I only now found out
14:38:39 <jjardon> Can we make bst-external stable instead? Not sure is worth moving things around for bst-1.2
14:38:49 <tristan> Another approach, for the projects we maintain, we can use bst-external as a git submodule
14:38:50 <jjardon> If everything will change again for master
14:39:10 * SotK sticks his likely-missing-context nose in
14:39:27 <tristan> And make sure that anything that distro packagers get, don't receive any breaking changes from bst-external
14:39:50 <SotK> when I had a play with buildstream and fdsdk a few months ago, the lack of any packaged version of bst-external was a bit of a frustration
14:40:01 <tristan> jjardon, Well that's what I sort of mean by "freezing development of bst-external"
14:40:14 <SotK> it wasn't nice to have to clone a random git repo and install from source in order to actually build anything in fdsdk
14:40:41 <tristan> The unfortunate thing is that *one of* the reasons for bst-external to exist, is to be a place to put stuff that is known to not be stable yet
14:40:52 <jjardon> Sotk yeah , we get complains about that all the time
14:40:54 <tristan> It was also an incubation grounds for domain specific stuff
14:41:25 <jjardon> Tristan problem is that there are things there that are stable now
14:41:50 <jjardon> And they are needed to build both fdsk and gnome
14:41:53 <persia> If we want to consider it incubation, maybe there needs to be a graduation policy for things in there, so messaging can indicate "go package foo instead".
14:41:54 <tristan> jjardon, except they were never intended to stablize "in bst-external", but rather find a more appropriate home
14:42:03 <tristan> really should have been called bst-experimental
14:42:10 <juergbi> it's supposed to be easy to install with pip, though, isn't it?
14:42:20 <juergbi> that apparently has some issues but maybe we can fix those
14:42:20 <persia> And projects that use stuff in bst-external can be told "if you rely on stuff in there, make an effort to get it graduated, or your projects may not be consumable by others".
14:43:15 <tristan> Right, so on the ML I will be proposing a gstreamer like packaging of the plugins we want to maintain outside of core
14:43:27 <jjardon> Tristan if that is the case, is should be better documented I think. So where should we put git_tag and the flatpak plugings then?
14:43:42 <SotK> juergbi: iirc it is, but `git clone $link; cd bst-external; pip install --user .` is way more complicated than it needs to be (except for the fact it sounds like bst-external was never meant to actually be used by anyone)
14:43:58 <tristan> Because there is no current plan or contributor willing to step up and work on code which makes it easier for projects to depend on plugins from various sources
14:44:03 <jjardon> tristan oh, I though nobody likes that when I proposed it :)
14:44:08 <juergbi> SotK: I meant via pypi, i.e., not requiring manual git clone
14:44:09 <cs-shadow> SotK: you can do `pip install git+https://bst-external-url.git`
14:44:16 <juergbi> or that
14:44:30 <SotK> juergbi: it isn't on pypi
14:44:39 <SotK> cs-shadow: oh neat, TIL, thanks
14:44:42 <tristan> jjardon, I don't like it - but unless someone volunteers to make `git source for plugins` a thing, I don't see how else to approach the problem
14:45:05 <jjardon> right
14:45:47 <jjardon> Maybe we should document better the pip approach as cs-shadow mentioned?
14:46:20 <tristan> Ok so without giving it enough thought, this is what I propose: (A) Branch bst-external-1.2 in the bst-external repository, and make sure we update any surrounding docs to recommend that branch
14:46:32 <valentind> Cannot we use junctions to import plugins?
14:46:35 <cs-shadow> OR if fdsk used it via submodules, then we can sidestep this problem. And you also get the benefit that all users will be using the same version of the plugins that you can cotnrol
14:46:43 <jjardon> But I think bst-external is pretty stable now; I do not see a problem on it being packaged
14:46:45 <tristan> for anyone packaging, they should use this, for README etc for building freedesktop-sdk, we should use bst-external-1.2 branch
14:47:08 <tristan> And then we make bst-external-1.2 "stable" for the remainder of bst-1.2 lifetime
14:47:24 <juergbi> valentind: interesting idea
14:47:26 <tristan> If we need further changes that are breaking, we have to think of putting them elsewhere
14:47:40 <jjardon> tristan Yeah, I like that, but only branch when we introduce a breaking change, not branching for branching
14:47:50 <tristan> jjardon, No we actually need it right now
14:47:59 <juergbi> valentind: would not help with dependencies, though
14:48:03 <tristan> jjardon, Because there is the current problem of running BuildStream 2
14:48:36 <tristan> if we want to run BuildStream 2 with bst-external, we probably need a venue for BuildStream 2 supporting plugins, and by default that will be the master branch of bst-external
14:48:37 <jjardon> Buildstream 2 should not use bst-external at all, if we stick to the plans
14:48:54 <tristan> jjardon, yeah but what about from now until that other thing exists ?
14:49:12 <jjardon> I guess is a good compromise
14:49:12 <tristan> jjardon, We need to still have a strategy for doing CI of real world projects with BuildStream 2 (master)
14:49:34 <SotK> my ideal workflow would be having it on pypi, with a requirements.txt in fdsdk or whatever project which specifies the version of bst-external required (since that approach requires no actual additional work)
14:49:52 <jjardon> I'd like to force people to not use bst-external for 2.0 but yeah I think that would work
14:49:57 <persia> I think for BuildStream2(master), external stuff should live in bst-experimental (fixing the namespace issue).
14:50:13 * aevri runs for next meeting
14:50:14 <tristan> persia++ (for the stop gap solution)
14:50:17 <persia> There's the manual step of cloning bst-external into bst-experimental to start that process, but that's probably better long-term than branch.
14:50:29 <laurence> so, i think we're all in agreement to release a stable bst-external (call it 1.2) and get it packaged for pypi, is that right?
14:50:42 <jjardon> Persia the plugings we need don't belong in experimental
14:50:53 <persia> laurence: For some value of "release": I think it is important to be careful about the level of promises made.
14:51:02 <jjardon> That's the main problem
14:51:36 <tristan> jjardon, That is true but there needs to be a pathway - I mean doing what persia suggests we can do right away without any fuss
14:51:36 <SotK> what about moving the plugins that are mature into a new place, and packaging that?
14:51:42 <tristan> jjardon, And we can keep doing CI
14:51:49 <persia> jjardon: Then create new plugin repos for BuildStream 2 to handle them, based on the (emerging) policy on external plugins.  But that doesn't have to happen now, because for 1.2, bst-external works.  For buildstream 2, only experimental stuff belongs in bst-experimental, and other stuff should be properly homed.
14:52:02 <jjardon> laurence: if it gets packaged for pip, it will be for all distros (which I'm fine with)
14:52:02 <SotK> key point being "packaging" not "releasing", with warning about potential brokenness
14:52:03 <tristan> jjardon, Then we can go ahead and have that complicated conversation about what goes into bst-plugins-good after
14:52:11 <persia> SotK: That would also work, but someone would have to define "mature" :)
14:52:20 <laurence> SotK, isn't that the same as having a bst-external for 1.2 and then seprarting out bst-experimental for master?
14:52:35 <tristan> As a side benefit, we also get to test out (and document) our story about "How a plugin graduates from bst-experimental into bst-plugins-good"
14:52:41 <SotK> laurence: pretty much, but I was assuming that some of bst-external doesn't fit the definition of "mature"
14:52:42 <persia> SotK: Also, in order to make packaging simple, there are some "release" steps that are important, especially for subnitting to pypi.
14:53:19 <SotK> persia: sure, I was just imagining a bit warning in the readme/docs that things are not necessarily stable
14:53:39 <SotK> rather than something that suggests a stable and supported release
14:53:57 <SotK> it has tags already, despite being unstable
14:54:09 <persia> That, plus generating a blessed tarball, is probably all that is needed for "release".  I doubt anyone wants to commit to long-term support for bst-external (but I'd be delighted to be wrong).
14:54:27 <jjardon> Sotk is not unstable
14:54:55 <jjardon> Some plugings are being used in production for a while
14:54:58 <persia> Indeed.  It's stable, just not actually necessarily reliable, usable, good, or supported.
14:55:19 <persia> (mostly because nobody ever defined "mature" or a graduation policy, so the good stuff in bst-external hasn't been sorted out)
14:55:28 <jjardon> It's supported as well, in the sense we fix bugs if we find them
14:55:38 <laurence> #summary for now, let's create a stable bst-external (tethered to buildstream 1.2) so that it can be packaged for pip, and update all appropriate docs
14:55:59 <tristan> jjardon, So to clarify; "unstable" does not necessarily mean not ready for production; it means that it is not unchanging
14:56:21 <SotK> ^ this is what I meant, I should've been clearer, sorry
14:56:24 <tristan> jjardon, for it to be stable, it means that you should be able to use *any* version of bst-external with your project, and upgrading bst-external will not change things
14:56:30 <jjardon> For me means it's not mean to break things
14:56:39 <tristan> jjardon, We are talking about packaging it
14:57:05 <tristan> jjardon, Right now the only real way of using it reliably is as a git submodule of your project
14:57:31 <tristan> Otherwise there is no guarantee that the bst-external you have installed is the one you need
14:57:40 <laurence> #summary and we'll split up #bst-external into #bst-experimental for master (not impacting 1.2 negatively)
14:57:43 <tristan> jjardon, if we're packaging it, then the exact same copy has to be good for everyone
14:57:49 <jjardon> to simplify things, I'd say keep bst-external for bst-1.2, then create new repos for 2.0. if that is not good the create a branch in bst-external for 1.2
14:58:04 <tristan> Sure
14:58:13 <jjardon> But that branch will be way more active than master, probable
14:58:13 <persia> jjardon: +1
14:58:16 <tristan> The first thing is that bst-external receives no breaking changes
14:58:22 <jjardon> Yup
14:58:25 <tristan> jjardon, And by that I mean "Does not change API at all"
14:58:27 <jjardon> Agree on that
14:58:45 <tristan> And agreed about other preliminary steps
14:58:53 <jjardon> Let's do it then :)
14:58:59 <laurence> #summary agreed on a way forward for now to improve user experience for bst-external - there's still work to do to agree a clear policy around plug-ins becoming mature and being 'blessed'
14:59:02 <tristan> We can't figure out the whole future but for now we kind of have to make it stable
14:59:10 <laurence> OK we're out of time here
14:59:12 * persia is not convinced the current API for everything in bst-external is sufficiently bug-free to be particularly aggressive about that promise
14:59:30 <laurence> anyone disagree with my summaries ? please feel free to amend them or add more detail
14:59:52 <persia> laurence: They look good to me.
15:00:17 <laurence> ok, time's up - thanks everybody
15:00:25 <tristan> Thanks laurence !
15:00:26 <laurence> see you next time...!
15:00:30 <laurence> yw
15:00:35 <laurence> #endmeeting