15:00:00 <nils> #startmeeting modularity_wg
15:00:00 <zodbot> Meeting started Tue Jan 15 15:00:00 2019 UTC.
15:00:00 <zodbot> This meeting is logged and archived in a public location.
15:00:00 <zodbot> The chair is nils. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:00 <zodbot> The meeting name has been set to 'modularity_wg'
15:00:01 <nils> #meetingtopic Weekly Meeting of the Modularity Working Group
15:00:01 <nils> #topic Roll Call
15:00:12 <nils> .hello nphilipp
15:00:13 <zodbot> nils: nphilipp 'Nils Philippsen' <nphilipp@redhat.com>
15:00:16 <contyk> o/
15:00:16 <asamalik> .hello2
15:00:17 <zodbot> asamalik: asamalik 'Adam Samalik' <asamalik@redhat.com>
15:00:19 <contyk> .hello psabata
15:00:21 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:01:41 <nils> #topic Agenda
15:01:51 <nils> #info #112 Discussion: Module lifecycles
15:01:51 <nils> #info #115 Discussion: Stream branch ownership for packages & modules
15:01:51 <nils> #info #119 Modularity WG Charter (contd.)
15:01:51 <nils> #info #123 & #124 Service Levels, EOLs
15:02:01 <nils> anything else?
15:03:17 <nils> okay...
15:03:25 <nils> #topic #112 Discussion: Module lifecycles
15:03:25 <nils> #link https://pagure.io/modularity/issue/112
15:03:25 <nils> .modularity 112
15:03:25 <nils> #link https://pagure.io/fesco/issue/2027
15:03:27 <zodbot> nils: Issue #112: Discussion: Module lifecycles - modularity - Pagure.io - https://pagure.io/modularity/issue/112
15:04:24 <langdon> .hello2
15:04:25 <zodbot> langdon: langdon 'Langdon White' <langdon@redhat.com>
15:04:26 * contyk is reading yesterday's comments
15:04:30 <asamalik> I'm discussing this one with FESCo
15:04:45 <nils> so, still ongoing -> postpone?
15:05:04 <asamalik> yeah, nothing significant to report
15:05:07 <nils> ok
15:05:31 <nils> #info ongoing, asamalik in discussion with FESCo, postponed
15:05:42 <nils> #topic #115 Discussion: Stream branch ownership for packages & modules
15:05:43 <nils> #link https://pagure.io/modularity/issue/115
15:05:44 <nils> .modularity 115
15:05:46 <nils> #link https://pagure.io/fesco/issue/2028
15:05:46 <zodbot> nils: Issue #115: Discussion: Stream branch ownership for packages & modules - modularity - Pagure.io - https://pagure.io/modularity/issue/115
15:06:22 <asamalik> also discussing, but for this one I have a tiny update
15:06:45 <asamalik> my proposal with implicit package branch ownership wasn't the most popular one
15:06:55 <asamalik> the group feels that an explicit ownership would work better
15:07:20 <asamalik> I have an action item to update the proposal to reflect that
15:07:22 <asamalik> EOF
15:07:43 <contyk> could you also update the ticket with that summary?
15:07:56 <asamalik> contyk: sure
15:08:17 * asamalik will take an action to write an update about his other action
15:08:59 <nils> heh
15:09:11 <nils> anything we should #info?
15:10:03 <asamalik> #info asamalik will update the proposal to include explicit package branch ownership and will review that with FESCo again
15:10:52 <nils> #topic #119 Modularity WG Charter (contd.)
15:10:53 <nils> #link https://pagure.io/modularity/issue/119
15:10:53 <nils> .modularity 119
15:10:54 <zodbot> nils: Issue #119: Modularity WG Charter (contd.) - modularity - Pagure.io - https://pagure.io/modularity/issue/119
15:12:12 <nils> asamalik, contyk, I see your comments as essentially +1, modulo contyk's questions about wording?
15:12:16 <contyk> re:the first comment and your answer, nils -- I guess I was mostly commenting on the first sentence
15:12:29 <contyk> "This document was ratified by ... (fill in details once it's approved)."
15:12:37 <contyk> that feels fairly unnecessary
15:12:58 <nils> Ahh ok. That one can go as far as I'm concerned, just something I inherited and restyled from Langdon's original proposal :)
15:13:26 <contyk> that was back when it was also mentioning the Council's explicit approval
15:13:32 <nils> yeah
15:17:27 <nils> So how about we vote on it with these amendments?
15:17:27 <nils> - s/Working Group/Team/g
15:17:27 <nils> - nix "This document was ratified by ... (fill in details once it's approved)."
15:19:12 <contyk> +1
15:19:26 <nils> asamalik, langdon? ^^
15:19:58 <asamalik> +1
15:20:25 <langdon> so im a little confused about what we are voting on.. that contyk's changes be included but otherwise it is done?
15:20:42 <nils> yeah
15:20:47 <langdon> ahh ok..
15:20:49 <langdon> +1
15:21:35 <nils> +1
15:22:20 <nils> #agreed with amendment (+4, 0, -0)
15:22:47 <nils> finally, new business?
15:23:02 <nils> "!" I mean
15:24:10 <nils> #topic #123 & #124 Service Levels, EOLs
15:24:11 <nils> #link https://pagure.io/modularity/issue/123
15:24:11 <nils> #link https://pagure.io/modularity/issue/124
15:24:11 <nils> .modularity 123
15:24:11 <nils> .modularity 124
15:24:12 <zodbot> nils: Issue #123: Please adjust service level for PostgreSQL module - modularity - Pagure.io - https://pagure.io/modularity/issue/123
15:24:15 <zodbot> nils: Issue #124: The "adding new modules" page should explain what "rawhide:SL" means - modularity - Pagure.io - https://pagure.io/modularity/issue/124
15:25:06 <contyk> co this is related to the other two tickets
15:25:21 <contyk> perhaps not the branch ownership but definitely the lifecycles
15:25:26 <nils> yeah
15:25:35 <contyk> so as noted in the ticket, I'd rather disable this mechanism that's just causing pain
15:25:46 <asamalik> contyk: +1
15:25:48 <contyk> it's not used for anything else, just to torture packagers
15:25:58 <nils> this is the more concrete thing which cropped up last week when praiskup tried to push into the 9.6 stream branch of the postgresql module and couldn't
15:26:10 <nils> yeah, +1 from me, too
15:27:05 <nils> also, there's a ticket about unblocking this specific thing:
15:27:21 <nils> #link https://pagure.io/releng/issue/8057 Unblock/reactivate the 9.6 stream branch of the postgresql module
15:30:28 <nils> ..and regarding #124 -- explain what the different SLs (rawhide, bug_fixes, security_fixes, ...) mean is kinda obviated if we switch off gating. IMO this'd make more sense as purely informational fields but the question is which maintainer would put in this data any longer? I guess not many.
15:31:11 * asamalik will check what the docs say again
15:32:05 <asamalik> OK we should clarify it's not used, that we're working on a functional replacement, and that people should just put some future date?
15:32:37 <nils> Ideally maintainers would put in this information where it exists (e.g. with postgresql upstream has a table listing EOLs for the different branches) but I don't think it makes sense to pull a date out of thin air just to have it filled with something.
15:33:48 <nils> And as I understand contyk, the functional replacement should be no functional replacement other than maybe ensuring the future FPDC will have a way to record this info for the few maintainers who will do it?
15:34:06 <contyk> if we decide to store it and store it there
15:34:20 <contyk> turning this off would require some changes, possibly in the infra and in the client tooling
15:34:24 <contyk> and the docs
15:34:40 <contyk> e.g. we would need to ensure that we can create stream branches without this information in the infra
15:34:52 <contyk> we would need to change the tool to not require SLs when requesting branches
15:35:06 <nils> yes
15:35:07 <contyk> and we would need to drop this from the docs, perhaps explaining that it used to be one way but is different now
15:35:21 <contyk> and the git hooks
15:35:27 <asamalik> yeah I think it's easier at this point to tell people "just put 2043 there, we're working on a fix"
15:36:06 <asamalik> because as contyk says, that's a lot of work, so let's just do it once
15:37:12 <nils> well, if people know anything more concrete than 2043 they should put that in, but lack of information (with many projects there are no statements about how long a version will be maintained) shouldn't keep them from creating the branches.
15:42:16 <asamalik> anything else on this topic?
15:42:30 <nils> I guess not, except summarizing it?
15:42:36 <nils> I'll give it a shot:
15:43:14 <nils> - document that we need the SLs at the moment because tooling depends on them present (and in the future) to let you commit/push changes to the respecive branches
15:44:11 <nils> - change tooling so that it doesn't gate on SLs being present and in the future
15:44:59 <nils> - update documentation accordingly, i.e. that this was required in the past but now are just informational fields
15:45:06 <nils> contyk, asamalik, ^^ ?
15:46:02 <contyk> that's reasonable
15:46:14 <contyk> someone will have to coordinate the git change
15:47:30 <nils> I kept that intentionally vague, if we're lucky only pagure/git is affected but who knows if koji etc. don't gate on this information?
15:50:47 <contyk> ok, so who's going to do that?
15:51:02 <nils> I think the first two points can happen concurrently, asamalik how about you make the docs changes and I'll follow up with pagure/releng/whomever else about tooling changes?
15:51:22 <asamalik> I'll take it
15:51:55 <nils> DYM docs or everything? :D
15:52:10 * asamalik will do everything
15:52:35 <contyk> EVERYTHING
15:52:53 <nils> I'm tempted to #action it verbatim like this
15:53:20 <asamalik> exactly
15:53:41 <nils> #action asamalik updates docs and coordinates the necessary tooling changes
15:53:53 <nils> ^^ fine?
15:54:12 <asamalik> sounds good
15:54:17 <nils> nice
15:54:29 <nils> anything for open floor?
15:55:04 <contyk> not from me
15:55:17 <langdon> nope
15:55:26 <nils> :)
15:55:28 <asamalik> nope
15:55:32 <nils> Thanks everybody!
15:55:35 <nils> #endmeeting