14:01:02 <nils> #startmeeting modularity_wg
14:01:02 <zodbot> Meeting started Tue Aug 21 14:01:02 2018 UTC.
14:01:02 <zodbot> This meeting is logged and archived in a public location.
14:01:02 <zodbot> The chair is nils. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:01:02 <zodbot> The meeting name has been set to 'modularity_wg'
14:01:02 <nils> #meetingtopic Weekly Meeting of the Modularity Working Group
14:01:02 <nils> #chair dgilmore mikedep333
14:01:02 <zodbot> Current chairs: dgilmore mikedep333 nils
14:01:14 <nils> #topic Roll Call
14:01:16 <contyk> o/
14:01:19 <nils> .hello nphilipp
14:01:20 <zodbot> nils: nphilipp 'Nils Philippsen' <nphilipp@redhat.com>
14:01:22 <contyk> .hello psabata
14:01:26 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
14:01:35 <bcotton> .hello2
14:01:36 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
14:02:30 <dgilmore> hi
14:02:36 <nils> #topic Agenda
14:02:47 <x3mboy> Hi
14:02:49 <x3mboy> .hello2
14:02:50 <zodbot> x3mboy: x3mboy 'Eduard Lucena' <eduardlucena@gmail.com>
14:03:07 <nils> #info [asamalik] Replacing docs.pagure.org/modularity with a redirect to the Fedora Docs / Modularity
14:03:20 <asamalik> .hello2
14:03:21 <zodbot> asamalik: asamalik 'Adam Samalik' <asamalik@redhat.com>
14:03:24 <nils> #info [contyk] open issues
14:03:26 * asamalik waves
14:03:28 <nils> #info AOB
14:03:36 <contyk> just one thing? cool
14:03:42 <nils> #topic Replacing docs.pagure.org/modularity with a redirect to the Fedora Docs / Modularity
14:03:45 <nils> #chair asamalik
14:03:45 <zodbot> Current chairs: asamalik dgilmore mikedep333 nils
14:04:07 <asamalik> do we also wanna talk about lifecycles?
14:04:30 <nils> I think this is the first, or at most second time that someone used the issues for the WG meeting agenda :)
14:04:32 <asamalik> maybe it's just me, but I don't understand how it works exactly now
14:04:43 <contyk> it doesn't
14:04:44 <asamalik> nils: is there a badge for that?
14:04:47 * asamalik demands a badge
14:05:12 <nils> asamalik++
14:05:13 * contyk awards asamalik one of his badges
14:05:25 <asamalik> contyk: hahahaha
14:05:53 * asamalik is happy
14:06:52 <asamalik> nils: should I create an issue for that lifecycle topic?
14:07:23 <nils> asamalik, let's just do it in AOB, or let's wedge it in before we deal with the open issues (contyk?)
14:07:39 <nils> I'm fine with either
14:07:46 <contyk> sure
14:07:54 <nils> It's not as if something not being on the agenda has ever stopped us before :)
14:09:29 <nils> anyway, asamalik, the docs topic?
14:10:27 <asamalik> nils: ah is that active now? sure
14:10:52 <asamalik> so we have this URL we share everywhere: docs.pagure.org/modularity
14:11:12 <asamalik> right now it hosts a landing page and people can click at "docs" at the top-right corner to go to our docs
14:11:27 <asamalik> I was wondering if we could remove that page completely and only have a redirect to the docs
14:12:00 <asamalik> so we would have a single place with all the information, while having the old link we share everywhere working
14:12:09 <asamalik> opinions?
14:12:26 <contyk> +1
14:12:27 <asamalik> langdon might also care about ^^
14:12:35 <nils> +1, but we should fix the most visible places of the old URL to the new one
14:13:23 <asamalik> nils: or we could keep this one... and having a flexibility to redirect it even somewhere else next time we change our docs provider :P
14:14:14 <nils> asamalik, I really prefer old-old-old pointing to old-old pointing to old pointing to current... not :)
14:14:45 <asamalik> nils: hahahaha... but that's not what I meant... it's just old always pointing to current
14:14:48 <contyk> asamalik bought a new domain name we could use
14:14:57 <asamalik> contyk: we couldn't
14:15:22 <nils> asamalik, I just looked into my I-Can't-Believe-It's-Not-Crystal™ ball :)
14:15:31 * asamalik shall keep horsefunerals.co.uk to himself
14:16:00 <nils> 👍
14:16:02 <asamalik> anyway, looks like we've decided we should go for it, right?
14:16:20 <nils> yup
14:17:05 <nils> #agreed let old Pagure instance redirect to Fedora Docs/Modularity
14:17:10 <asamalik> proposed #agreed We'll replace the content of docs.pagure.org/modularity with a redirect to the Fedora Docs / Modularity — this way, the URL we have everywhere keeps working while we have all our content at a single place
14:17:23 <asamalik> nils: or that, yes
14:17:34 <nils> :)
14:17:49 <langdon> +1
14:17:58 <contyk> he lives!
14:18:29 <langdon> ha.. didn't realize the meeting had started.. on another call
14:18:30 <nils> #topic Wanna talk about lifecycles?
14:18:42 <asamalik> langdon: yay parallel meetings!
14:18:43 <nils> asamalik, yours, too :)
14:19:12 <asamalik> allright
14:19:38 <nils> If it looks as if I'm rushing the meeting it's because I'm rushing the meeting. :D
14:19:45 <asamalik> so... after Flock I've been rewriting the Adding New Modules docs (with a lot of help from others, thanks!) https://docs.fedoraproject.org/en-US/modularity/making-modules/adding-new-modules/#_rpm_sources
14:20:05 <asamalik> and when I was describing the command for requesting a new repo, there was this "--sl rawhide:2020-12-01 BRANCH"
14:20:49 <asamalik> and I realized I didn't quite know how does it work... so I only documented it as "expected end of life, must end with either 12-01 or 06-01"
14:21:14 <asamalik> earlier at this meeting, contyk pointed out it doesn't quite work
14:21:55 <nils> AIUI the command doesn't work without it, but does it do something? I guess it would record this in PDC or whatever?
14:22:17 <asamalik> nils: that's my theory
14:22:30 <langdon> basically, it should be at least 13 months from release.. or one month after the second Fedora release after the module release
14:22:59 <asamalik> so I thought it would be beneficial to: 1) update everyone on the actual state
14:23:06 <langdon> Ohh.. yeah.. I think it does but that is another PDC challenge
14:23:19 <nils> langdon, wasn't the point of modules to decouple things from downstream release cycles?
14:23:22 <langdon> we would have to confirm with threebean
14:23:22 <asamalik> and 2) have a plan or at least a plan to have a plan :)
14:23:23 <nils> one of them I mean
14:23:41 <langdon> nils yes, but, slowly so people don't get confused
14:24:11 <contyk> so PDC is going away, I think; or maybe it's already deprecated
14:24:25 <contyk> another thing is nothing is really checking this information or providing it to users in any way
14:24:34 <langdon> not dead yet... future dead
14:24:42 <contyk> just recently we were going to rebuild modules for f29 and to build them for platform:f30
14:24:57 <contyk> apparently we also built some EOL'd modules because that information just doesn't affect anything
14:25:23 <langdon> to contyk and nils' points.. Unless dnf can tell a user the lifecycle, we can't have things going away randomly
14:25:23 <contyk> we might need to come up with a new plan for this
14:25:27 <contyk> where to store it and how to use it
14:25:30 <asamalik> I remember having these discussions :)
14:25:56 <asamalik> but I feel like we're not on the same page, or at least we don't have a formal decision how to deal with this
14:26:12 <nils> also: what if I don't have a clue about a project's EOL plans because there aren't any?
14:26:38 <langdon> asamalik same page on what?
14:26:45 <nils> I mean we could tell people to tie it to downstream releases then, but there needs to be a way to extend it.
14:26:51 <asamalik> langdon: how exactly is that going to work
14:27:04 <contyk> when I was creating my modules, I just picked a random date five years from now
14:27:08 <langdon> ha.. still not enough info for me to understand
14:27:15 <asamalik> see? :)
14:27:25 <asamalik> should we discuss that on devel@l.fp.o before the next meeting? that would give us two weeks
14:27:30 * langdon still a little addled from devconf
14:27:48 <asamalik> I'm happy to start a thread
14:28:02 <langdon> well.. mattdm had made the policy I mentioned pretty clear..
14:28:18 <langdon> I think the "how" might be more useful on ml
14:28:25 <asamalik> langdon: do you have any link?
14:28:30 <asamalik> with more info?
14:28:55 <langdon> it was in the guidelines before they were "edited"
14:28:58 <asamalik> I remember those discussions.. just can't find anything about it
14:29:57 <asamalik> langdon: which guidelines? we had so many :)
14:30:04 <langdon> but.. I am not sure it matters.. we can adjust the policy as we go.. the how is the hard part.. particularly with PDC being an issue
14:30:18 <langdon> the module guidelines page on the wiki
14:30:36 <asamalik> langdon: I think we should figure out the what, before thinking about how
14:31:12 * asamalik feels like sgallagh could be interested in this discussion as well
14:31:19 <langdon> you mean whether it is 1 year or 13 months or whatever?
14:31:48 * sgallagh looks up
14:31:54 <sgallagh> Oh, is it meeting day?
14:32:15 <langdon> we know we want eol info.. and it should be reasonable.. but we don't have a way to ask for it or enforce it
14:32:22 <langdon> or telk users
14:32:29 <asamalik> langdon: I mean the basic mechanics of managing that info
14:33:04 <asamalik> langdon: yes, that would be also part of that... do we force people to have it? or do we simply assume it's maintained for the active releases, until manually retired?
14:33:11 <asamalik> there are many ways we could do this
14:33:25 <asamalik> that's what I'd like to discuss
14:33:36 <asamalik> and then we can think about implementation, PDC, and other things
14:34:00 <langdon> well.. I think the only question is how much in advance of retiring you have to let people know
14:34:07 <contyk> to me it would make sense to have the "rawhide" SL by default, without any specific dates
14:34:20 <contyk> basically until retired
14:34:32 <asamalik> contyk: that was my thinking, too
14:34:33 <langdon> sorry SL?
14:34:47 <contyk> langdon: service level
14:34:53 <contyk> we have four of those
14:34:55 <langdon> Ahh duh
14:35:00 <asamalik> if you build it for rawhide, it's maintained for all active + one future release
14:35:05 <asamalik> and you retire it when you need to
14:35:24 <contyk> you can always define more SLs if you want to
14:35:43 <contyk> but I think unless upstream is very specific about it, most people won't
14:36:05 <asamalik> contyk: see? I haven't even mentioned service levels, or actually remembered we have (had? talked about?) these
14:36:24 <contyk> well, the life cycles are bound to those
14:36:34 <contyk> "what level of support I provide until when?"
14:36:38 <asamalik> contyk: do we have this documented somewhere?
14:36:48 <contyk> asamalik: you're the docs master :)
14:36:57 <asamalik> contyk: that means no :)
14:37:02 <langdon> ha
14:37:06 <contyk> asamalik: https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml#L40
14:37:16 <asamalik> which enforces the need of the discussion, and why we're even talking about this right now :)
14:38:14 <asamalik> contyk: thanks, that's a good start
14:38:43 <asamalik> even though it doesn't explain how it actually works or what people should use (or how)
14:39:02 <contyk> indeed, this is just the format
14:39:06 <contyk> but you see what you can expect
14:39:12 <asamalik> so do we wanna collect all the info we have, and discuss that on devel?
14:39:18 <contyk> +1
14:39:28 <langdon> +1
14:39:39 <asamalik> ok, I can start the thread
14:39:46 <asamalik> nils: I'll make an action I guess?
14:40:38 <asamalik> proposed #action asamalik starts a thread on the devel list about managing module lifecycles. The result (or a first iteration) will be reviewed in the next meeting.
14:41:04 <contyk> also make a ticket and label it so we don't forget
14:41:34 <asamalik> proposed #action asamalik starts a thread on the devel list about managing module lifecycles. The result (or a first iteration) will be reviewed in the next meeting. asamalik will also create a ticket for that so we don't forget.
14:41:34 <asamalik> :)
14:42:06 <nils> sounds good
14:42:13 <asamalik> ok, let me get that in so we can look at the issues also
14:42:19 <asamalik> #action asamalik starts a thread on the devel list about managing module lifecycles. The result (or a first iteration) will be reviewed in the next meeting. asamalik will also create a ticket for that so we don't forget.
14:42:46 <nils> #topic open issues
14:43:09 <nils> contyk, were there any specific ones you wanted to talk about?
14:43:34 <contyk> nils: I haven't checked
14:43:36 <nils> #link https://pagure.io/modularity/issues
14:43:41 <contyk> I guess we should just address whatever is open
14:43:58 <nils> so we just talked about asamalik's #106
14:44:14 * asamalik looked at the issues today, too, and some of them felt pretty old
14:44:26 <nils> #105 "no explanation of how to build packages for modules"
14:44:46 <nils> looks like it only needs feedback from the reporter
14:44:47 <asamalik> that's what I feel like it's done
14:45:07 <nils> #103 "Building Fedora modules locally" doc lacks information on streams
14:46:06 <nils> looks like docs side is covered but it needs an RFE issue in rpkg/fedpkg to me
14:46:12 <nils> asamalik, sgallagh, do you agree?
14:46:20 <nils> https://pagure.io/modularity/issue/103
14:46:46 <asamalik> nils: yeah
14:46:49 <sgallagh> I started filing an RFE this morning and then lost it in a GNOME Shell crash :-/
14:46:52 <sgallagh> But yes, I agree
14:47:05 <langdon> :(
14:47:36 * contyk recommends dwm instead, now modular!
14:47:43 <langdon> ha
14:48:24 * asamalik thinks dwm is cool
14:48:51 <contyk> we just need a dwm-based silverblue
14:49:01 <asamalik> contyk: YES!!
14:49:08 <asamalik> :)
14:49:18 <asamalik> anyway, next issue? :P
14:49:30 <nils> :)
14:49:48 <nils> I didn't want to interrupt you. The world needs more discussions about window managers :)
14:50:04 <nils> #102 Block modules when their service levels are expired
14:50:10 <contyk> oh look
14:50:20 <nils> I guess this is blocked by the SL convo above being resolved.
14:50:24 <contyk> yeah
14:50:38 <nils> #97 RFE (and policy change request): automatic creation of module repos and branches for modules which comprise a single RPM
14:50:43 <nils> https://pagure.io/modularity/issue/97
14:50:48 <asamalik> I think that's done!
14:50:59 <asamalik> I've commented today
14:51:12 <contyk> yeah
14:51:27 <contyk> we don't generate modulemd, though
14:51:33 <contyk> but branches are created
14:51:56 <asamalik> true
14:52:26 <nils> ok, next?
14:52:39 <nils> #72 Make it clear how to query module metadata for a yum/dnf repo
14:52:45 <nils> https://pagure.io/modularity/issue/72
14:53:42 <asamalik> I feel like that's what nils is working on, right?
14:53:51 <contyk> sorta kinda
14:54:04 <asamalik> :)
14:54:06 <nils> sorta kinda, yes :)
14:54:13 <contyk> I think it's safe to say we don't plan any changes in the repodata format to accomodate for easier queries
14:54:28 <asamalik> fair enough
14:54:34 <contyk> what modules are in the repo and what rpms they include can be listed with dnf module list/info
14:54:37 <nils> it's a bit more than that
14:54:47 <nils> e.g. "Documenting the current repo-level metadata format that DNF itself uses"
14:54:54 <nils> I'm not touching that :)
14:54:57 <contyk> but I think it's asking for more machine-readable things
14:55:42 <nils> I'd say my fedmod work covers the "user wants to know this" angle, but not any of the low-level stuff
14:56:05 <contyk> which is fine
14:56:18 <nils> mhm
14:56:22 <contyk> because if you want something low level and specific, just parse the modules.yaml with libmodulemd yourself
14:56:28 <nils> yep
14:56:46 <nils> I'm gonna ignore #71 [Meeting Agenda] a new agenda topic for the wg meeting
14:56:47 <asamalik> yeah
14:56:55 <nils> and #45 Clarify which kind of issues should be reported here
14:57:03 <nils> #31 syntax with check_modulemd has fallen out of sync
14:57:12 <nils> I guess this is obsolete
14:57:15 <asamalik> +1
14:57:25 <nils> the tools for this are modulemd-validator and/or fedmod lint
14:57:34 <asamalik> let's just kill them with ⽕
14:57:34 <nils> once I'm done with the latter for modulemd v2 anyway
14:57:43 <nils> whatever that kanji is :)
14:57:43 <contyk> check_modulemd was a script executed by taskotron
14:57:57 <contyk> maybe it still is but I have no idea what the status of the CI infra is
14:58:12 <nils> me neither
14:58:14 <contyk> it was reporting issues to resultsdb and you could technically subscribe to the notifications
14:58:23 <nils> but looking at it, modulemd-validator should do the trick for automated testing
14:58:23 <contyk> perhaps someone could take an action and investigate
14:59:04 <contyk> not saying we need to resurrect or port check_modulemd, it could be whatever nils is working on
14:59:05 <nils> who was involved with getting check_modulemd into taskotron?
14:59:16 <contyk> but if there is something still running in the infra, it should be replaced
14:59:21 <nils> absolutely
14:59:36 <contyk> nils: well, originally that was tflink (now unavailable) and bgoncalv
15:00:07 <nils> I could give it a go, but have a hunch I won't get to it before my PTO next week.
15:00:22 <asamalik> I could look into that probably
15:00:56 <asamalik> I also need to disappear right now, but if someone could please #action me?
15:01:09 <nils> asamalik, thanks. Feel free to reassign to me at will.
15:01:55 <nils> #action asamalik looks into what if anything runs in infrastructure testing, if it needs replacing (https://pagure.io/modularity/issue/31)
15:02:18 <nils> it seems we're through the list!
15:02:22 <langdon> I may look at this as well
15:03:03 <langdon> so we done?
15:03:18 <langdon> we are over time
15:03:33 * asamalik is on a phone
15:03:35 <nils> Yep, unless someone wants to discuss something else :)
15:03:36 <asamalik> thanks nils
15:03:54 <langdon> I have to run too..
15:03:56 <nils> Thanks everybody!
15:03:59 <nils> #endmeeting