14:00:20 #startmeeting modularity_wg 14:00:20 Meeting started Tue Sep 18 14:00:20 2018 UTC. 14:00:20 This meeting is logged and archived in a public location. 14:00:20 The chair is nils. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:20 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:00:20 The meeting name has been set to 'modularity_wg' 14:00:20 #meetingtopic Weekly Meeting of the Modularity Working Group 14:00:20 #chair dgilmore langdon 14:00:20 Current chairs: dgilmore langdon nils 14:00:21 * asamalik waves 14:00:23 .hello2 14:00:24 asamalik: asamalik 'Adam Samalik' 14:00:29 #topic Roll Call 14:00:32 .hello nphilipp 14:00:32 .hello psabata 14:00:33 nils: nphilipp 'Nils Philippsen' 14:00:36 contyk: psabata 'Petr Šabata' 14:00:42 .hello2 14:00:43 bcotton: bcotton 'Ben Cotton' 14:00:50 hello 14:01:23 .hello2 14:01:24 langdon: langdon 'Langdon White' 14:02:06 #topic Agenda 14:02:06 * contyk hums 14:02:30 I have one topic -- tracking our work, meetings, general... restructuring? 14:02:39 is there anything else, like tickets and iportant things? 14:02:51 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 I have a topic — managing module lifecycle 14:03:12 nils: I don't think we need to discuss them again 14:03:13 asamalik: did you see the discussion from last time? 14:03:33 langdon: I did, why? 14:03:35 asamalik: wasn't one of the lifecycle? 14:03:35 asamalik, managing module lifecycles is one of them 14:03:43 nils: ah, cool 14:03:43 ha 14:04:08 yeah I think the docs.pagure.org redirect to Fedora Docs should be done 14:04:09 okay 14:04:38 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 asamalik, 👍 14:04:57 #info [contyk] tracking our work, meetings, general... restructuring? 14:04:58 * asamalik would start with contyk's topic 14:05:10 #info [asamalik] managing module lifecycles 14:05:19 #info open floor 14:05:30 #topic tracking our work, meetings, general... restructuring? 14:05:32 #chair contyk 14:05:32 Current chairs: contyk dgilmore langdon nils 14:05:34 okay 14:05:47 so we've been thinking about how to track work in the future 14:06:20 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 so we created a new Taiga board on taiga.io yesterday 14:07:02 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 in one place, in the open! 14:07:35 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 especially from releng, infra and possibly swmgmt 14:07:59 well.. we proposed a while ago to allow for "if present, you can vote" 14:08:37 the thing is nobody's really present ;) 14:08:37 we probably should make that official policy then 14:09:02 anyway, does taiga make sense to you all? 14:09:07 contyk: true 14:09:10 I agree that we need a sort of a "restart" in terms of tracking work and decision making 14:09:44 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 bcotton: +1 14:10:17 yes, I think we need to get a lot better at identifying next actions and ensuring they all have owners 14:10:24 mind you .. we have tried that :) but we haven''t revisited in a *long* time .. and people have changed roles 14:10:31 bcotton +1 14:11:17 langdon that's probably why we need the restart, it sort of died off 14:11:26 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 we setup one at taiga.io 14:12:07 yes, just yesterday; we need to populate it with epics, tasks and people :) 14:12:21 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 I kinda have a list of problems we need to tackle, it's rather long 14:13:10 asamalik: would you mind sending me a quick writeup on that out-of-band? that way i can collect our arguments 14:13:25 bcotton: definitely! 14:13:42 I'm using the instance at taiga.fedorainfracloud.org no one really maintains 14:13:52 it's never been officially supported 14:14:21 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 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 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 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 also I agree with langdon 14:15:50 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 bcotton: +1 14:16:29 bcotton: will you look into it? 14:16:46 contyk: yep, i'll work on that 14:16:57 great! sounds like an action 14:17:34 #info We set up a taiga.io board yesterday and would like to use it for tracking our work properly 14:17:49 bcotton++ 14:17:49 asamalik: Karma for bcotton changed to 10 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 14:17:51 #info In the long term it would be better if we got an enterprise subscription for the Fedora group 14:17:58 contyk, can you put in the #link yet? 14:17:59 #action bcotton will look into the last point 14:18:14 #link https://tree.taiga.io/project/modularity-wg 14:18:24 it's still very fresh 14:19:06 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 voice often works better than long discussions on IRC; just to see what everyone is working on 14:19:46 and maybe a weekly call where we discuss our epics and open problems 14:19:58 not suggesting we cancel this IRC meeting, just add a few more 14:20:18 jit.si also supports streaming to youtube; we could make these discussions public on the modularity channel 14:21:12 jitsi++ :) 14:21:41 would it be worth to do some sort of update/demo every 2-4 weeks and stream/record that? 14:21:56 that would be good, too, yes 14:22:58 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 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 and yay jitsi 14:23:30 nobody would watch the daily sync calls; the weekly calls might be interesting but we'd see 14:24:06 bcotton: it's all best-effort and voluntary 14:24:54 we can think about these a bit more and perhaps discuss on our main channel 14:25:20 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 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 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 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 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 someone who attends could commit to providing a summary of the sync on our main channel 14:28:05 i also had proposed doing the "people from other teams" only coming every so often... like once a month 14:28:08 if there are any highlights 14:28:41 langdon: would be nice if they could attend the weekly call but we can't force anyone, of course 14:28:45 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 i like asamalik's idea of starting with a maintained taiga board and see how much it improves coordination and communication 14:29:00 contyk: depends on how "fast" the work is going 14:29:39 remains to be seen :) 14:30:04 well, okay, I'll take the action to start transforming my list into epics within the next two weeks 14:30:22 contyk++ 14:30:22 bcotton: Karma for psabata changed to 7 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 14:30:54 #action contyk will transform his list of Things into Taiga epics before the next meeting 14:31:22 we can see about the calls (frequency and people) once we get this going 14:31:34 I think that's all I had today 14:31:43 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 asamalik++ 14:31:56 bcotton: Karma for asamalik changed to 8 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 14:32:00 that would be a great commblog post 14:32:03 +1 14:32:37 sound like it's not a completely terrible idea, cool :) 14:33:09 oh 14:33:22 we might also modernize the objective we have 14:33:27 langdon: any comments on that? 14:34:24 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 we should be sharing that with people soon 14:34:48 ok, thanks 14:35:24 nils: time for the next topic? 14:35:29 sure :) 14:35:40 #topic managing module lifecycles 14:35:43 #chair asamalik 14:35:43 Current chairs: asamalik contyk dgilmore langdon nils 14:36:56 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 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 Let's not read it now, I'll summarize... 14:38:16 #link https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/KGXBMTUR72FHQEG7IBHDPPX276QHSD2I/ 14:39:46 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 different how? 14:40:55 hi 14:41:03 dgilmore: hey 14:41:07 langdon: like not setting it and retiring it manually in rawhide when the time comes 14:41:14 dgilmore: greetings 14:41:29 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 both, I'd say 14:42:00 usually you just don't know; you support it until you decide to drop it 14:42:10 but the date is for "not owner" info.. consumers need to know an expectation 14:42:12 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 in that case we could just add eol to the released modules, kinda like "won't be in the next release" 14:42:32 hopefully we aren't eol'ing packagers 14:42:42 :) 14:42:46 langdon: sometimes that happens, too 14:43:37 yeah, I think there are two scenarios 14:43:56 1) the package is maintained in release branches + stream branches 14:44:18 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 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 of course they could collaborate 14:45:27 2) the package doesn't exist in regular fedora and is only included in modules 14:45:39 and in cases a package is in multiple modules, these multiple module maintainers would collaborate on maintaining it 14:45:40 in that case it was added by the module maintainer and they care about it directly 14:45:51 * contyk nods 14:46:43 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 yep 14:47:58 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 ...in some cases 14:48:49 I also argued for seeting EOL for modules only, not packages 14:49:28 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 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 you could also maintain them long after they're dead upstream, because you simply need them 14:50:45 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 contyk: that's what I've mentioned as a "Thing No.2" above 14:50:56 and I like that idea 14:51:01 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 because it perfectly ties to what we've just discussed 14:51:08 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 asamalik: you did, just explaining my thinking 14:52:28 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 that's what I meant :) 14:53:25 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 sure 14:53:45 so having it a bit more dynamic could be a win 14:53:59 one of my packages's been dead upstream for 11 years now 14:54:04 I still maintain it 14:54:39 dwm?? ;) 14:54:41 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 langdon: dwm's alive and well; tinyfugue :) 14:54:56 yeah that's also important note 14:57:22 so it looks like we're on the same page here, what's next? 14:57:33 good question 14:57:35 any proposals? 14:57:57 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 so let's make it an epic and figure out the next action later? :) 14:59:16 let's write this down as a specific proposal and approach other groups with that 14:59:23 contyk++ 14:59:23 asamalik: Karma for psabata changed to 8 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 14:59:49 contyk: did you read the blog post I haven't even drafted?! 15:00:02 :) 15:00:37 we're out of time 15:00:42 but we probably need to have an action, so writing this down as a specific proposal might be a good start 15:00:45 yes, that too 15:01:02 asamalik: will you post to the thread 15:01:03 * asamalik takes an action 15:01:20 *? 15:01:31 contyk: yes 15:01:56 #action asamalik writes a specific proposal, sends it back to the thread 15:02:13 cool 15:02:15 nils: let's close this? 15:02:20 sure 15:02:27 #topic open floor 15:02:42 anything for open floor? 15:03:08 nils: yes, next meeting :-D 15:03:15 heh 15:04:02 thanks everybody! 15:04:04 #endmeeting