14:00:20 <nils> #startmeeting modularity_wg
14:00:20 <zodbot> Meeting started Tue Sep 18 14:00:20 2018 UTC.
14:00:20 <zodbot> This meeting is logged and archived in a public location.
14:00:20 <zodbot> The chair is nils. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:20 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:20 <zodbot> The meeting name has been set to 'modularity_wg'
14:00:20 <nils> #meetingtopic Weekly Meeting of the Modularity Working Group
14:00:20 <nils> #chair dgilmore langdon
14:00:20 <zodbot> Current chairs: dgilmore langdon nils
14:00:21 * asamalik waves
14:00:23 <asamalik> .hello2
14:00:24 <zodbot> asamalik: asamalik 'Adam Samalik' <asamalik@redhat.com>
14:00:29 <nils> #topic Roll Call
14:00:32 <nils> .hello nphilipp
14:00:32 <contyk> .hello psabata
14:00:33 <zodbot> nils: nphilipp 'Nils Philippsen' <nphilipp@redhat.com>
14:00:36 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
14:00:42 <bcotton> .hello2
14:00:43 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
14:00:50 <hellbanger> hello
14:01:23 <langdon> .hello2
14:01:24 <zodbot> langdon: langdon 'Langdon White' <langdon@redhat.com>
14:02:06 <nils> #topic Agenda
14:02:06 * contyk hums
14:02:30 <contyk> I have one topic -- tracking our work, meetings, general... restructuring?
14:02:39 <contyk> is there anything else, like tickets and iportant things?
14:02:51 <nils> At the moment, the Pagure issue tracker has two of Adam's topics which we discussed last time, too. Are they done yet or do we continue on them today?
14:02:57 <asamalik> I have a topic — managing module lifecycle
14:03:12 <asamalik> nils: I don't think we need to discuss them again
14:03:13 <langdon> asamalik: did you see the discussion from last time?
14:03:33 <asamalik> langdon: I did, why?
14:03:35 <langdon> asamalik: wasn't one of the lifecycle?
14:03:35 <nils> asamalik, managing module lifecycles is one of them
14:03:43 <asamalik> nils: ah, cool
14:03:43 <langdon> ha
14:04:08 <nils> yeah I think the docs.pagure.org redirect to Fedora Docs should be done
14:04:09 <nils> okay
14:04:38 <asamalik> nils: I just removed the "meeting" label from the docs one because we've already discussed it and I think the label was just forgotten there
14:04:54 <nils> asamalik, 👍
14:04:57 <nils> #info [contyk] tracking our work, meetings, general... restructuring?
14:04:58 * asamalik would start with contyk's topic
14:05:10 <nils> #info [asamalik] managing module lifecycles
14:05:19 <nils> #info open floor
14:05:30 <nils> #topic tracking our work, meetings, general... restructuring?
14:05:32 <nils> #chair contyk
14:05:32 <zodbot> Current chairs: contyk dgilmore langdon nils
14:05:34 <contyk> okay
14:05:47 <contyk> so we've been thinking about how to track work in the future
14:06:20 <contyk> the pagure tracker isn't really working well, it seems; we track issues in many different places, projects, websites, some are even just Red Hat internal
14:06:35 <contyk> so we created a new Taiga board on taiga.io yesterday
14:07:02 <contyk> we'd like to identify all the issues and gaps we currently have in our processes and tooling and track them there as some meaningful, SMART projects / epics
14:07:13 <contyk> in one place, in the open!
14:07:35 <contyk> we've also had quite poor attendance here in the past year, so it'd be good if we could pull in some more people
14:07:47 <contyk> especially from releng, infra and possibly swmgmt
14:07:59 <langdon> well.. we proposed a while ago to allow for "if present, you can vote"
14:08:37 <contyk> the thing is nobody's really present ;)
14:08:37 <nils> we probably should make that official policy then
14:09:02 <contyk> anyway, does taiga make sense to you all?
14:09:07 <langdon> contyk: true
14:09:10 <asamalik> I agree that we need a sort of a "restart" in terms of tracking work and decision making
14:09:44 <bcotton> one thing that may or may not help is asking releng, infra, etc to nominate a person to represent them here instead of making it open-ended. the if "no one owns it, it doesn't get done" philosophy
14:09:58 <contyk> bcotton: +1
14:10:17 <contyk> yes, I think we need to get a lot better at identifying next actions and ensuring they all have owners
14:10:24 <langdon> mind you .. we have tried that :) but we haven''t revisited in a *long* time .. and people have changed roles
14:10:31 <asamalik> bcotton +1
14:11:17 <asamalik> langdon that's probably why we need the restart, it sort of died off
14:11:26 <bcotton> i'm interested to see how taiga works for this group. i know there's been some discussion about the internal one and whether or not that will continue or if we'll pay for a subscription or do something else. i think we need something taiga-like, so if we can show that it's useful to the community, that will help us find funding for a Fedora-paid hosted instance
14:11:45 <langdon> we setup one at taiga.io
14:12:07 <contyk> yes, just yesterday; we need to populate it with epics, tasks and people :)
14:12:21 <asamalik> bcotton: that would be good, I also use it for the Docs project and it's really beneficial in the way we can structure everything
14:12:31 <contyk> I kinda have a list of problems we need to tackle, it's rather long
14:13:10 <bcotton> asamalik: would you mind sending me a quick writeup on that out-of-band? that way i can collect our arguments
14:13:25 <asamalik> bcotton: definitely!
14:13:42 <asamalik> I'm using the instance at taiga.fedorainfracloud.org no one really maintains
14:13:52 <contyk> it's never been officially supported
14:14:21 <asamalik> it would be awesome to have a fedora-backed instance with FAS integration, and possibly someone helping us develop new features such as pagure.io integration
14:14:32 <contyk> taiga.io seems to work pretty well; and I think we could also link it with various github projects we have, and hopefully pagure, too
14:15:16 <langdon> i am not sure pushing a fedora hosted instance is the best idea.. i think the taiga folks would appreciate the publicity.. i also think they have been open to taking patches..
14:15:25 <asamalik> contyk: it doesn't support pagure.io, but we could probably workaround it by setting up some sort of API translation service that would fake, let's say, the github format Taiga would understand
14:15:39 * contyk nods
14:15:47 <contyk> also I agree with langdon
14:15:50 <bcotton> yeah. i think taiga.io is probably the way we'll go, since infra doesn't have the resources to maintain an instance for us at least right now. but if we can potentially get an enterprise subscription for a central, official fedora group, that would be helpful for the community
14:16:17 <asamalik> bcotton: +1
14:16:29 <contyk> bcotton: will you look into it?
14:16:46 <bcotton> contyk: yep, i'll work on that
14:16:57 <contyk> great! sounds like an action
14:17:34 <contyk> #info We set up a taiga.io board yesterday and would like to use it for tracking our work properly
14:17:49 <asamalik> bcotton++
14:17:49 <zodbot> asamalik: Karma for bcotton changed to 10 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
14:17:51 <contyk> #info In the long term it would be better if we got an enterprise subscription for the Fedora group
14:17:58 <nils> contyk, can you put in the #link yet?
14:17:59 <contyk> #action bcotton will look into the last point
14:18:14 <contyk> #link https://tree.taiga.io/project/modularity-wg
14:18:24 <contyk> it's still very fresh
14:19:06 <contyk> so, in addition to this, I think it'd be great if we scheduled some regular, perhaps daily 10 minute sync calls on jit.si
14:19:22 <contyk> voice often works better than long discussions on IRC; just to see what everyone is working on
14:19:46 <contyk> and maybe a weekly call where we discuss our epics and open problems
14:19:58 <contyk> not suggesting we cancel this IRC meeting, just add a few more
14:20:18 <contyk> jit.si also supports streaming to youtube; we could make these discussions public on the modularity channel
14:21:12 <jwf> jitsi++ :)
14:21:41 <asamalik> would it be worth to do some sort of update/demo every 2-4 weeks and stream/record that?
14:21:56 <contyk> that would be good, too, yes
14:22:58 <asamalik> I think the daily sunc calls or the weekly discussions are beneficial, but not sure recording/streaming these is — who would just watch those? an update/demo feels more "watchable" for me
14:23:23 <bcotton> i worry daily calls would be rough for community contributors. i do like the idea of a regular demo/update video call, though
14:23:27 <asamalik> and yay jitsi
14:23:30 <contyk> nobody would watch the daily sync calls; the weekly calls might be interesting but we'd see
14:24:06 <contyk> bcotton: it's all best-effort and voluntary
14:24:54 <contyk> we can think about these a bit more and perhaps discuss on our main channel
14:25:20 <contyk> but if everyone's generally supportive of the taiga board idea, I'll take an action to process my list into workable epics and some actions
14:25:20 <bcotton> contyk: sure, but if someone can't attend regularly, they may not feel connected to the effort and lose interest. at least with IRC meetings there are minutes that get generated automatically. harder to do that with video calls (but someone could do it manually)
14:26:00 <asamalik> maybe if se set the new board up in a way people would understand what's going on, and we commit to keeping it up-to-date, we might not need a daily call at a specific time
14:26:58 <asamalik> yeah that... I definitely see the benefit for the "core group" of us working on it daily, but it might feel like the exact opposite to someone who just wants to contribute time to time...
14:27:38 <langdon> i wouldn't encourage anyone who is not doing this full time to come to the daily sync.. i think the weekly is much more likely to be useful
14:27:49 <contyk> someone who attends could commit to providing a summary of the sync on our main channel
14:28:05 <langdon> i also had proposed doing the "people from other teams" only coming every so often... like once a month
14:28:08 <contyk> if there are any highlights
14:28:41 <contyk> langdon: would be nice if they could attend the weekly call but we can't force anyone, of course
14:28:45 <langdon> if there are highlights that aren't relevant only to the people talking to each other they should be going out in an email anyway
14:28:59 <bcotton> i like asamalik's idea of starting with a maintained taiga board and see how much it improves coordination and communication
14:29:00 <langdon> contyk: depends on how "fast" the work is going
14:29:39 <contyk> remains to be seen :)
14:30:04 <contyk> well, okay, I'll take the action to start transforming my list into epics within the next two weeks
14:30:22 <bcotton> contyk++
14:30:22 <zodbot> bcotton: Karma for psabata changed to 7 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
14:30:54 <contyk> #action contyk will transform his list of Things into Taiga epics before the next meeting
14:31:22 <contyk> we can see about the calls (frequency and people) once we get this going
14:31:34 <contyk> I think that's all I had today
14:31:43 <asamalik> I'm also about to write a blog post about how we use Taiga in Docs, titled something like "issues are dead, long live issues, goals, and action", discussing the distinction between the specific goals we want to achieve (epics), actions that take us closer to the goals (cards within epics), and user feedback (issues)... maybe that could be even useful as the writeup for bcotton
14:31:55 <bcotton> asamalik++
14:31:56 <zodbot> bcotton: Karma for asamalik changed to 8 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
14:32:00 <bcotton> that would be a great commblog post
14:32:03 <contyk> +1
14:32:37 <asamalik> sound like it's not a completely terrible idea, cool :)
14:33:09 <contyk> oh
14:33:22 <contyk> we might also modernize the objective we have
14:33:27 <contyk> langdon: any comments on that?
14:34:24 <langdon> yeah.. we have been working on the write up for "what's next" for the next couple releases.. the current objective kinda runs through f29 .. but is already kinda outdated
14:34:40 <langdon> we should be sharing that with people soon
14:34:48 <contyk> ok, thanks
14:35:24 <contyk> nils: time for the next topic?
14:35:29 <nils> sure :)
14:35:40 <nils> #topic managing module lifecycles
14:35:43 <nils> #chair asamalik
14:35:43 <zodbot> Current chairs: asamalik contyk dgilmore langdon nils
14:36:56 <asamalik> I've started this 4 weeks ago on this very meeting, it's about a way how we manage lifecycles of modules which are meant to be independent from the Fedora release lifecycles.
14:37:45 <asamalik> There is a sort-of active thread on the devel list: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/KGXBMTUR72FHQEG7IBHDPPX276QHSD2I/
14:38:07 <asamalik> Let's not read it now, I'll summarize...
14:38:16 <contyk> #link https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/KGXBMTUR72FHQEG7IBHDPPX276QHSD2I/
14:39:46 <asamalik> Thing No.1: Setting the lifecycle. It feels like it's not always easy to come up with a specific EOL (end of life) date when creating a package or module. We need a different / additional way of setting an EOL.
14:40:28 <langdon> different how?
14:40:55 <dgilmore> hi
14:41:03 <contyk> dgilmore: hey
14:41:07 <asamalik> langdon: like not setting it and retiring it manually in rawhide when the time comes
14:41:14 <asamalik> dgilmore: greetings
14:41:29 <langdon> like the timing isn't right (as in you don't know the eol at creation) ? or it needs to change over time?
14:41:43 <contyk> both, I'd say
14:42:00 <contyk> usually you just don't know; you support it until you decide to drop it
14:42:10 <langdon> but the date is for "not owner" info.. consumers need to know an expectation
14:42:12 <asamalik> Thing No.2: EOL of packager, or only modules? One proposal by contyk was that we wouldn't set an EOL for packages, but only for the modules. And maintainers of a module would be responsible for maintaining the packages in their module. There wouldn't be a dedicated package maintainer in this case. "you build it, you maintain it" — that sort of thing.
14:42:21 <contyk> in that case we could just add eol to the released modules, kinda like "won't be in the next release"
14:42:32 <langdon> hopefully we aren't eol'ing packagers
14:42:42 <langdon> :)
14:42:46 <contyk> langdon: sometimes that happens, too
14:43:37 <contyk> yeah, I think there are two scenarios
14:43:56 <contyk> 1) the package is maintained in release branches + stream branches
14:44:18 <contyk> the release branch maintainer might also own the modules that provide alternatives, in that case they also care about the stream branches
14:44:54 <contyk> or it's someone who doesn't care about modules and has no interest in maintaining stream branches with content they don't care about, so it should be the module maintainer who's directly consuming it
14:45:09 <contyk> of course they could collaborate
14:45:27 <contyk> 2) the package doesn't exist in regular fedora and is only included in modules
14:45:39 <asamalik> and in cases a package is in multiple modules, these multiple module maintainers would collaborate on maintaining it
14:45:40 <contyk> in that case it was added by the module maintainer and they care about it directly
14:45:51 * contyk nods
14:46:43 <asamalik> and in cases a package is in no module, it's not even built, so no one maintains it. We might not even ned to retire it, since it's not anywhere. And if someone adds it into their module, it's their responsibility to maintain it again.
14:47:15 <contyk> yep
14:47:58 <asamalik> And this "you build it, you maintain it" could be applied on the current state as well — who builds traditional packages usually maintains them. And we even have different maintainers for Fedora and EPEL branches.
14:48:28 <asamalik> ...in some cases
14:48:49 <contyk> I also argued for seeting EOL for modules only, not packages
14:49:28 <contyk> the reason is it's more user and developer friendly; you don't have to worry about individual upstreams and the chances that one of your 200 modular components causes your module to be dropped
14:49:46 <contyk> of course you need to watch it to some extent as you're maintaining these, but that could be very low effort
14:50:06 <contyk> you could also maintain them long after they're dead upstream, because you simply need them
14:50:45 <contyk> I was thinking whether package-level EOL would be useful for release branches or building release-style, non-modular packages from stream branches, and I don't think it is
14:50:49 <asamalik> contyk: that's what I've mentioned as a "Thing No.2" above
14:50:56 <asamalik> and I like that idea
14:51:01 <nils> EOLs for packages could be set on a voluntary basis. Some upstreams are really good with publishing their intents, so having this information to be able to flag it to module maintainers could be beneficial.
14:51:05 <asamalik> because it perfectly ties to what we've just discussed
14:51:08 <contyk> for release branches the EOL is defined by the branch; for building from stream branches by the target, just like with modules
14:51:30 <contyk> asamalik: you did, just explaining my thinking
14:52:28 <contyk> nils: in very few cases where upstream does so and you actually follow that downstream, the maintainers should still have the possibility to define EOL ahead of time
14:52:57 <nils> that's what I meant :)
14:53:25 <asamalik> nils: and also as a maintainer, you might decide to stretch the lifecycle so it matches other stuff in the distro for example
14:53:32 <nils> sure
14:53:45 <asamalik> so having it a bit more dynamic could be a win
14:53:59 <contyk> one of my packages's been dead upstream for 11 years now
14:54:04 <contyk> I still maintain it
14:54:39 <langdon> dwm?? ;)
14:54:41 <contyk> and more often than that we just drop packages because we don't have anyone to maintain them, even though they're still supported upstream
14:54:50 <contyk> langdon: dwm's alive and well; tinyfugue :)
14:54:56 <asamalik> yeah that's also important note
14:57:22 <asamalik> so it looks like we're on the same page here, what's next?
14:57:33 <contyk> good question
14:57:35 <contyk> any proposals?
14:57:57 <asamalik> also, as we've recognized in the previous topic, we don't have a great attendance here, so we might want to involve other groups before making a final decision :)
14:59:15 <contyk> so let's make it an epic and figure out the next action later? :)
14:59:16 <asamalik> let's write this down as a specific proposal and approach other groups with that
14:59:23 <asamalik> contyk++
14:59:23 <zodbot> asamalik: Karma for psabata changed to 8 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
14:59:49 <asamalik> contyk: did you read the blog post I haven't even drafted?!
15:00:02 <contyk> :)
15:00:37 <contyk> we're out of time
15:00:42 <asamalik> but we probably need to have an action, so writing this down as a specific proposal might be a good start
15:00:45 <asamalik> yes, that too
15:01:02 <contyk> asamalik: will you post to the thread
15:01:03 * asamalik takes an action
15:01:20 <contyk> *?
15:01:31 <asamalik> contyk: yes
15:01:56 <asamalik> #action asamalik writes a specific proposal, sends it back to the thread
15:02:13 <contyk> cool
15:02:15 <contyk> nils: let's close this?
15:02:20 <nils> sure
15:02:27 <nils> #topic open floor
15:02:42 <nils> anything for open floor?
15:03:08 <asamalik> nils: yes, next meeting :-D
15:03:15 <nils> heh
15:04:02 <nils> thanks everybody!
15:04:04 <nils> #endmeeting