15:00:02 <contyk> #startmeeting FESCO (2018-12-03)
15:00:02 <zodbot> Meeting started Mon Dec  3 15:00:02 2018 UTC.
15:00:02 <zodbot> This meeting is logged and archived in a public location.
15:00:02 <zodbot> The chair is contyk. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:02 <zodbot> The meeting name has been set to 'fesco_(2018-12-03)'
15:00:06 <contyk> #meetingname fesco
15:00:06 <zodbot> The meeting name has been set to 'fesco'
15:00:10 <contyk> #chair nirik, maxamillion, jsmith, jforbes, zbyszek, tyll, sgallagh, contyk, bowlofeggs
15:00:10 <zodbot> Current chairs: bowlofeggs contyk jforbes jsmith maxamillion nirik sgallagh tyll zbyszek
15:00:16 <contyk> #topic init process
15:00:20 <contyk> .hello psabata
15:00:21 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:00:21 <jsmith> .hello2
15:00:22 <jforbes> .hello2
15:00:23 <zodbot> jsmith: jsmith 'Jared Smith' <jsmith.fedora@gmail.com>
15:00:25 <nirik> morning.
15:00:26 <zodbot> jforbes: jforbes 'Justin M. Forbes' <jforbes@redhat.com>
15:00:39 <contyk> apologies for not sending out the reminder
15:01:02 <bowlofeggs> .hello2
15:01:03 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <rbarlow@redhat.com>
15:01:23 <maxamillion> .hello2
15:01:24 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
15:01:55 <contyk> yay, quorum
15:02:13 * contyk gives it another minute
15:02:56 <contyk> ok
15:03:13 <contyk> so we have no new business if I don't count the non-existent gpg ticket
15:03:27 <contyk> we have a bunch of follow-ups, though
15:03:34 <contyk> #topic F29 – rebase of dnf, libdnf, dnf-plugins-core, dnf-plugins-extras
15:03:37 <contyk> .fesco 2016
15:03:39 <zodbot> contyk: Issue #2016: F29 – rebase of dnf, libdnf, dnf-plugins-core, dnf-plugins-extras - fesco - Pagure.io - https://pagure.io/fesco/issue/2016
15:03:40 <contyk> https://pagure.io/fesco/issue/2016
15:03:53 <zbyszek> .helloe2
15:03:55 <zbyszek> .hello2
15:03:56 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:04:05 <contyk> so we have +3 in the ticket
15:04:19 <contyk> the dnf team believes this is needed
15:04:22 <bowlofeggs> i'll be +1
15:04:36 <nirik> +1 here as well
15:04:37 <zbyszek> sorry for being late again, this meeting time is complicated for me
15:04:55 <maxamillion> +1
15:05:04 <jsmith> It seems everyone else is +1... I'm still considering voting +0.  I still feel there's an impedance mismatch between the way DNF is being developed and the Fedora releases, which could bite us.
15:05:43 <zbyszek> jsmith: true, in general. I don't think this particular case qualifies a problematic.
15:05:45 <bowlofeggs> i do wish he answered my question
15:06:31 * contyk nods
15:06:39 <zbyszek> "It is a huge release that fix a lot of problems. But the problem for one user could mean a feature for other."
15:06:45 <zbyszek> "We slightly improved behavior list conf class (now behave like python list or like in dnf-2.7.5) and removed behavior of append conf list class. It was requested but some users already could require formal behavior."
15:07:10 <zbyszek> I think this should be read as "strictly speaking, not bw compatible, but we hope it doesn't matter in practice"
15:07:30 <bowlofeggs> hmm that does sound not great actually
15:07:59 <contyk> agreed but I think in this case it really doesn't matter in practice
15:08:58 <maxamillion> I think it should be backwards compatible, old version there's a list-like data type that's immutable but now it's a proper mutable iterator
15:09:20 <contyk> proposed #agreed FESCo approves of the DNF stack rebase (+6, 1, -0)
15:09:45 <maxamillion> so not *technically* backwards compatible but anyone using it isn't going to notice because it shouldn't affect currently working code
15:09:47 <jforbes> I am +1, it has been in testing for a decent amount of time, though I would like to see pbrobinson comment as to whether his issue was addressed.
15:10:18 <contyk> ok
15:10:27 <bowlofeggs> a slightly reluctant +1 from me
15:10:27 <contyk> #agreed FESCo approves of the DNF stack rebase (+7, 1, -0)
15:10:43 <contyk> #topic Enabling pm_request in fedoraproject koji
15:10:46 <contyk> .fesco 2004
15:10:48 <zodbot> contyk: Issue #2004: Enabling pm_request in fedoraproject koji - fesco - Pagure.io - https://pagure.io/fesco/issue/2004
15:10:49 <contyk> https://pagure.io/fesco/issue/2004
15:11:21 <contyk> so it's a little unclear what the next step here is
15:11:24 <zbyszek> I don't think there's much to discuss here until there's another concrete proposal
15:11:32 <jsmith> Agreed...
15:11:34 * nirik nods
15:11:55 * contyk nods
15:12:07 <bowlofeggs> yeah we need someone to implement something on this one
15:12:09 <jforbes> Right, we gave a list of requirements. It's up to them now
15:12:12 <bowlofeggs> nothing we can do at this point
15:12:28 <contyk> #info We're waiting for another concrete proposal to resolve this
15:12:36 <contyk> #topic Ursa Major (modules in buildroot) enablement
15:12:40 <contyk> .fesco 2003
15:12:42 <zodbot> contyk: Issue #2003: Ursa Major (modules in buildroot) enablement - fesco - Pagure.io - https://pagure.io/fesco/issue/2003
15:12:43 <contyk> https://pagure.io/fesco/issue/2003
15:12:50 <contyk> so, any more questions here?
15:13:22 <zbyszek> actually yes
15:13:39 <zbyszek> You said: "It would also require additional changes to UM to understand the defaults structure and how to properly load them"
15:14:02 <zbyszek> How much work, some estimate?
15:14:05 <zbyszek> EOQ
15:14:20 <nirik> I don't think maintaining a list would be very hard... so I think this defaults thing is a sidetrack
15:14:25 <contyk> ah, I see the last comments -- you would still prefer that over a separate config
15:14:26 * sgallagh arrives late
15:15:02 <contyk> an estimate...
15:15:09 <jforbes> nirik: If it proves to be, a ticket could always be opened stating so
15:15:16 <contyk> well, UM has a simple config that tells it what names+streams go into which tags
15:15:18 <sgallagh> zbyszek: Could we agree that automating that would be a great thing to do, but in the interest of getting UM in production, we could temporarily maintain the list manually?
15:15:34 <zbyszek> contyk: yes I would, I think it'd make things simpler. But if there are technical reasons to prefer a differnt approach, I won't be obstinate
15:15:35 <contyk> with this it would need to know where the defaults are stored, understand the branching schema and map it to tags somehow
15:15:42 <contyk> and then parse the defaults
15:16:26 <contyk> I don't know how long it would take as I don't know how busy the people behind the project are
15:16:57 <bowlofeggs> sgallagh: +1
15:17:16 <bowlofeggs> i don't think fesco needs to be too particular about how requirements are met, just what the requirements are
15:17:29 <zbyszek> sgallagh: +1
15:17:41 <contyk> mizdebsk also says he would like to ues buildroot-only modules; if we do this, these building blocks would need to go into repos
15:17:59 <contyk> that might be developer friendly, not so much end user friendly
15:18:00 <nirik> yep
15:18:36 <sgallagh> contyk: How would they not be end-user friendly?
15:18:47 <nirik> so in the end how pratical is the idea of a 'buildroot' repo, thats just the repodata pointing to the modular/non modular repos? (that we can publish for end users)
15:18:53 * sgallagh assumes we're not talking about making them default streams
15:19:00 <contyk> sgallagh: see the mess we have in f29 :)
15:19:07 <contyk> sgallagh: we are
15:19:27 <contyk> zbyszek's proposal is to only include default streams in the ursine buildroot
15:19:36 <contyk> so if you want to have such modules, they need to be default
15:19:39 <sgallagh> hmm
15:20:05 <sgallagh> There's no middle ground? Like, "All default streams go into the ursine buildroot, plus this manual exception list"?
15:20:26 <bowlofeggs> couldn't that easily lead to conflicts?
15:20:27 * sgallagh thinks
15:20:45 <contyk> well, I'd like to have that
15:21:11 <sgallagh> bowlofeggs: I'd like to assume that manual curation means some human avoiding conflicts
15:21:49 <bowlofeggs> what if initially there isnt'a conflict, and then someone comes along later and needs the default stream/
15:21:57 <maxamillion> I'm against the "temporarily maintain the list be hand", I'd personally reject the change until everything is fully automated
15:22:13 <maxamillion> I've seen too many infrastructure decisions be "temporary" and then live for a decade
15:22:33 <maxamillion> not specifically in Fedora, but in general
15:22:41 <jsmith> maxamillion: I tend to agree...
15:23:12 <nirik> sometimes you need the thing sooner than automating it would take.
15:23:32 <bowlofeggs> i personally feel ok leaving that decision to infra though
15:23:35 <sgallagh> maxamillion: Well, I suppose it wouldn't be too hard to write a script to read from fedora-module-defaults and output the ursa major config format
15:23:36 <bowlofeggs> i agree in general
15:23:51 <bowlofeggs> i just dont' think fesco should tell infra whether to automate or not
15:23:57 <contyk> sgallagh: that might be easier than adding support to UM directly, yes
15:23:59 <sgallagh> Better long-term if UM did this automatically, but we could at least "automate" it as part of the compose
15:24:02 <maxamillion> I also tend to err on the side of caution when considering something that might place more burden on a packager ... it's already a thankless job and I'm not super excited about Ursa Major to begin with
15:24:26 <bowlofeggs> will this place burden on packagers?
15:24:47 <bowlofeggs> or does it just make a buildroot of all module default stream packages?
15:24:51 * nirik notes epel8 is pretty limited if at all until we have ursa major
15:24:55 <maxamillion> bowlofeggs: it was my understanding that's by RelEng pushed back and it was brought to FESCo in the first place
15:24:56 <contyk> my proposal adds one extra task
15:25:06 <jforbes> maxamillion: I think the burden is only on packagers who decide they wish to use it.
15:25:10 <maxamillion> that's why*
15:25:11 <zbyszek> Yeah, a script to dump fedora-module-defaults sounds like a workable solution
15:25:14 <sgallagh> maxamillion: I don't think it was pushback. I think they wanted assurance we agreed.
15:25:19 <contyk> if a packager wanted their module to be in the buildroot, they would submit a PR to the config
15:25:25 <bowlofeggs> maxamillion: ah interesting, i hadn't noticed taht
15:25:38 <nirik> the problem is that it makes non koji users life more difficult.. unless we can make them a buildroot repo or some other solution
15:26:13 <contyk> is there a problem with buildroot repos?
15:26:19 <contyk> besides being somewhat expensive
15:26:36 <maxamillion> jforbes: I don't disagree, but if more and more of the fundamental components that are building blocks for upstream projects become modularized in Fedora, then the packagers won't have a choice
15:27:00 <maxamillion> nirik: wait, who's a non koji user?
15:27:11 <nirik> the reason releng brough it to fesco was the non koji user case...
15:27:11 <contyk> COPR
15:27:26 <till__> or local mock
15:27:28 <nirik> copr, mock on a local machine, rpmbuild on a local machine
15:27:42 <maxamillion> ah ok
15:28:08 <nirik> if you take foo.src.rpm from fedora and try and build it in those and it needs something from a module it will fail.
15:28:15 <maxamillion> yeah, -1 to the whole thing then until it can be figured out how to not introduce that burden on packagers
15:28:32 <zbyszek> contyk: the problem with PRs to enable modules is that they will often have to be created by maintainers of packages which BuildRequire something which is a module, and not by maintainers of the module itself.
15:28:39 <bowlofeggs> yeah i think rpmbuild users are important
15:28:59 * till__ agrees with maxamillion and bowlofeggs
15:29:02 <nirik> well, thats why I suggested making a buildroot repo
15:29:03 <contyk> zbyszek: that's an interesting thought
15:29:24 <contyk> maxamillion: so what burden are you referring to?
15:29:28 <jforbes> rpmbuild is the easier part to handle, because if some a buildreq is installed locally it just works
15:30:17 <jforbes> Though perhaps more convoluted as to how the replicate the success in mock
15:30:36 <contyk> if you generate repo for the build tag, everyone can just consume that
15:30:43 <maxamillion> contyk: having to figure out where to find the deps in module correlation as compared to how it is now, because today everything resides in the single source of truth
15:30:44 <bowlofeggs> jforbes: well what if we allow non-default stream as proposed? how would the rpmbuild user know which stream is needed?
15:30:56 <maxamillion> contyk: I can't do that in mock on my laptop
15:30:58 <bowlofeggs> and what if rpmbuild user has the default stream?
15:31:01 <nirik> contyk: we don't really want to point the world at koji do we?
15:31:18 <jforbes> bowlofeggs: right, that was the more convoluted piece I was referring to
15:31:26 <contyk> so
15:31:48 <contyk> mock config files support modules (according to msuchy)
15:32:00 <contyk> the config files are also distributed with mock; they could just list the modules we include the buildroot
15:32:13 <contyk> of course that means someone would need to keep these configs up to date
15:32:16 <nirik> as long as we don't change them too quickly...
15:32:23 * contyk nods
15:32:34 <contyk> but it's an option which doesn't rely on koji repos
15:32:41 <zbyszek> nirik: if modularity takes off, I'm pretty sure we'll be changing them pretty quickly
15:32:53 <mizdebsk> contyk, and doesn't work with buildroot-only modules
15:32:53 <bowlofeggs> contyk: that sounds ok to me i think
15:33:08 <contyk> mizdebsk: it doesn't?
15:33:15 <nirik> zbyszek: well, quicker than the modules go to stable?
15:33:39 <mizdebsk> contyk, how does user get the module if it's not in repos on mirrors, but only in koji?
15:33:51 <nim> contyk, depending on mock cofigs is going to be a PITA for packagers that fork the configs to add their own package repo
15:34:01 <contyk> mizdebsk: point
15:34:16 * nirik notes mock configs are seperate from mock these days...
15:34:32 <nim> contyk, which is pretty much what you have to do to work on packages not yet included in the distro
15:34:45 <bowlofeggs> we have modules that won't be on the mirrors?
15:34:53 <mizdebsk> we already do
15:34:55 <contyk> bowlofeggs: that's the building block modules
15:35:12 <bowlofeggs> why do those exist?
15:35:21 <tyll> we could get mock changed to support including other config files so that the module config lives in its own file that can be included by forked configs
15:35:26 <contyk> we also have packages that are not included in the repos
15:35:44 <bowlofeggs> that is also news to me
15:35:53 <nim> tyll, that would solve this, yes
15:35:57 <nirik> glibc32? not sure there are any others....
15:36:03 <tyll> is there a list of building block modules?
15:36:03 <contyk> nirik: yes :)
15:36:20 <mizdebsk> tyll, mock already does support including config files
15:36:44 <contyk> tyll: not readily available but can be put together
15:36:55 <mizdebsk> nirik, cisco codec?
15:36:57 <contyk> tyll: all modules in MBS for your platform minus all modules included in the compose
15:37:15 <nirik> I suppose... sure.
15:38:53 <tyll> contyk, not sure how to compute this in my head :-)
15:38:54 <contyk> feels like we have more confusion and questions than last week
15:38:59 <bowlofeggs> this all seems very complicated
15:39:09 <bowlofeggs> it's hard for me to get a clear model in my mind of it all
15:39:58 <contyk> so there are two main issues, if I understand it
15:40:08 <nirik> so perhaps another proposal... we could allow it to be setup/enabled for epel8 only while we sort out fedora cases?
15:40:21 <contyk> one is the configuration and how to automate it so that packagers don't have to care
15:40:39 <contyk> and the other is how to make the buildroot available to non-koji users; the only option is probably a buildroot compose
15:41:08 <mizdebsk> nirik, epel8 doesn't really require ursa-major as all the packages are included in existing external repo
15:41:59 <nirik> mizdebsk: they are? in the appstream repo? wouldn't yum4 see those as modular with the modular repodata?
15:42:00 * contyk would like to have this ready for f30 rather than in 2020
15:42:33 <zbyszek> contyk: yes, I think that if we answer those two questions, we are good
15:42:38 <nirik> contyk: but couldn't we do a buildroot compose where we point the actual packages at the other existing repos?
15:43:23 <contyk> nirik: not sure I follow
15:43:27 <mizdebsk> nirik, koji repos are not modular, koji repo is a single, non-modular repo created from epel8 packages with rhel8 repos merged in, mock in koji sees non-modular repos
15:44:10 <mizdebsk> ursa-major does not add modules to koji repos, it adds contents of modules; koji repos, with or without ursa-major, are still not modular - they don't include modulemd
15:44:49 <sgallagh> contyk: repodata doesn't have to be a relative directory
15:44:58 <nirik> mizdebsk: well, no epel8 repos actually exist yet... my understanding from the beta is we have a base repo (traditional rpms) and a appstream repo (modules). If we add them both as external repos, the appstream one will not have non modular repodata and not work?
15:45:02 <sgallagh> So we could create a buildroot repo whose repodata merely pointed to other existing repos
15:45:24 <sgallagh> Instead of copying all the files into it
15:45:25 <contyk> but what other existing repos?
15:45:42 <nirik> Everything/$arch/ and Modular/$arch/
15:45:50 <tyll> nirik, Appstream also contains tradtiotional RPMS AFAIU
15:45:51 <mizdebsk> nirik, no, koji repo will see all rpms from appstream, from all module streams
15:45:56 <tyll> nirik, maybe also extra modules
15:46:23 <nirik> ok.
15:46:24 <contyk> that would behave differently from the koji environment
15:46:59 <contyk> 1. Modular/$arch/ doesn't have to match the config, and
15:47:09 <contyk> 2. as mizdebsk said, in koji it all appears ursine
15:47:16 <nirik> in that case could we do the same for Fedora? Just include Modular as another repo?
15:47:18 <contyk> here that wouldn't be the case
15:48:21 <sgallagh> nirik: No. That way leads to disaster.
15:48:36 <nirik> would it for epel8 as well?
15:48:40 <mizdebsk> i agree with sgallagh, not a good idea
15:48:40 <sgallagh> There are packages in the Fedora Modular repos that would upgrade each other unexpectedly
15:49:28 <sgallagh> nirik: Representative example: I have both Node.js 10.x (LTS) and Node.js 11.x (experimental) modules in Fedora right now.
15:49:46 <sgallagh> The 11.x would replace the 10.x ones if the module metadata doesn't cause it to be filtered out
15:50:14 <tyll> sgallagh, how is this handled with UM?
15:50:25 <contyk> it's not
15:50:33 <contyk> UM includes what you tell it to include
15:50:52 <sgallagh> Right, if you tell UM to include both, it'll do so (and things will go wrong)
15:51:40 <contyk> so
15:51:48 <contyk> should we move the discussion to the ticket again?
15:51:55 <contyk> with focus on the two main questions I noted earlier?
15:52:10 <contyk> I don't think we can solve it here
15:52:19 <zbyszek> What it releng's stance on maintaing a list by hand, would they be OK with doing that?
15:52:36 <contyk> zbyszek: note they already maintain the defaults in the same manner
15:52:59 <bowlofeggs> releng is already doing waaaay too much by hand
15:53:14 <zbyszek> right,  and it'd be 2x as much work possibly
15:53:16 <bowlofeggs> but again, i think we can just authorize requirements and not demand an implementation
15:53:54 <sgallagh> zbyszek: If someone shows me what the UM config file format is, I'll write a damned git hook for the defaults repo to generate it for us
15:54:06 <zbyszek> bowlofeggs: right, but that's a question that weighs on the requirements that we specify, whether we ask for something automatic, or just a list kept somewhere
15:54:18 <zbyszek> sgallagh: OK, so that'd mean automation
15:54:22 <bowlofeggs> zbyszek: i think we should not ask for either of those
15:54:31 <contyk> sgallagh: it's a simple JSON
15:54:36 <bowlofeggs> zbyszek: i think we should leave that up to the implementors
15:55:05 <zbyszek> bowlofeggs: but this is also visible externally, because w/o automatism, we have to ask packagers to open PRs/tickets to add modules
15:55:34 <sgallagh> zbyszek: I don't think it's a prerequisite, but it's both easy enough and valuable enough that yes it will happen.
15:55:36 <contyk> we could go for the combined approach, as suggested earlier
15:55:51 <contyk> generate part from the defaults, append some other manually maintained config for special cases
15:55:58 <contyk> I think that's fairly reasonable
15:56:12 <zbyszek> +1
15:56:15 <sgallagh> +1
15:56:19 <tyll> why would the manual config not conflict with the automated configs?
15:56:28 <contyk> it could
15:56:40 <contyk> there's always a potential for error
15:56:41 <sgallagh> tyll: It *could*, but i'm trusting that rel-eng and FESCo aren't unaware of this
15:56:41 <bowlofeggs> zbyszek: that's a fair point
15:57:13 <sgallagh> I'd also like to express that I think it should be a REAL exception that causes us to use something other than the defaults.
15:57:32 <bowlofeggs> i still worry about someone adding something that is non-default and then someone else later needing default
15:57:45 <bowlofeggs> allowing non-default seems like a path to problems
15:57:48 <tyll> sgallagh, how easy would it be for rel-eng to verify that someting does not conflict?
15:57:51 <contyk> you could add a CI check for that
15:57:52 <sgallagh> bowlofeggs: I'm perfectly comfortable treating the exception list like the defaults services list
15:57:59 <sgallagh> Requires a FESCo decision to add to it
15:58:22 <nirik> well, the building blocks or whatever modules wouldn't be default right?
15:58:30 <jforbes> sgallagh: that might be more stomachable
15:58:31 <contyk> they wouldn't
15:58:37 <mizdebsk> they could be
15:58:39 <tyll> sgallagh, if we do not have an exception list, a FESCo dcision would also be required to get it created
15:58:53 <contyk> mizdebsk: well, if they are, I wouldn't call them building blocks
15:58:58 <sgallagh> tyll: I'm good with that
15:59:01 <mizdebsk> contyk, module can have default stream and yet not be included in repos
15:59:21 <contyk> mizdebsk: ...yes, that's true
15:59:33 * nirik thinks this is getting pretty far into implementation... and we still haven't answered the 2 base questions contyk noted.
15:59:46 <smooge> hi guys.. looking at this conversation, I am seeing a lot of people talking past each other with no clear consensus on what they are talking about. Everyone seems to have different ideas about what modules/ursamajor/etc are doing and solving and this is the 3-4th meeting like this.
16:00:28 <tyll> smooge, I guess the problem is that the ticket is about enabling UM, which is already an implementation :-)
16:02:32 <maxamillion> smooge: that's a fair point
16:02:47 <bowlofeggs> i do feel like i don't fully understand modules, why we have some that don't get shipped in repos, why we want to allow rpms to depend on modules (especially non-default ones), and probably also things i don't realize that i don't understand ☺
16:03:33 <nirik> the non shipped ones are things used to build other modules that maintainer don't want to support for building *, only specific stuff....
16:04:00 <contyk> :)
16:04:31 <contyk> as, as proposed above -- can we continue this in the ticket?
16:04:43 <contyk> I think we identified two major pain points
16:04:45 <nirik> for epel8 at least the case for rpms to depend on modules is to allow smaller add on things... like python or php or whatever packages that could be modules, but a module for 1 package is really overkill.
16:05:07 <nirik> contyk: +1
16:05:30 <zbyszek> contyk: and who can answer those two points in the ticket?
16:05:32 <bowlofeggs> contyk: +1
16:05:42 <contyk> zbyszek: I hope we can figure it out together
16:05:56 <zbyszek> ok, I hope so too ;)
16:06:00 <jforbes> contyk: +1
16:06:02 <zbyszek> contyk: +1 to moving on
16:07:21 <contyk> #info There two major points that need to be addressed regarding Ursa Major. #1 Make it painless for package maintainers and releng to maintain the UM config, and #2 Make it reasonably easy for non-koji users to consume our buildroot content
16:07:37 <contyk> #info We will discuss these topics in the ticket
16:07:42 * contyk nods
16:07:44 <zbyszek> ack
16:07:54 <contyk> ok, onwards
16:07:58 <contyk> #topic The FTBFS cleanup policy is not happening
16:08:03 <contyk> .fesco 1973
16:08:05 <zodbot> contyk: Issue #1973: The FTBFS cleanup policy is not happening - fesco - Pagure.io - https://pagure.io/fesco/issue/1973
16:08:07 <contyk> https://pagure.io/fesco/issue/1973
16:08:19 <zbyszek> It *is* happening ;)
16:08:19 <contyk> I put this on the agenda just to check the status
16:08:45 <contyk> good!
16:08:56 <contyk> #info It *is* happening!
16:09:00 <contyk> #topic Action needed: Orphan packages will be retired if they remain orphaned for six weeks
16:09:04 <contyk> .fesco 1970
16:09:06 <zodbot> contyk: Issue #1970: Action needed: Orphan packages will be retired if they remain orphaned for six weeks - fesco - Pagure.io - https://pagure.io/fesco/issue/1970
16:09:07 <contyk> https://pagure.io/fesco/issue/1970
16:09:10 <contyk> same thing here
16:10:36 <contyk> #info Also ongoing
16:10:53 <contyk> #topic https://fedoraproject.org/wiki/Changes/GnuPG2_as_default_GPG_implementation
16:10:59 <contyk> this one doesn't have a ticket, still
16:11:10 <contyk> last week we decided to wait
16:11:28 <contyk> any news here?
16:11:39 <zbyszek> maintainers for gpg and gpg2 are all for it
16:11:43 <ignatenkobrain> .hello2
16:11:44 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <i.gnatenko.brain@gmail.com>
16:12:01 <zbyszek> I'm +1
16:12:07 <tyll> +1
16:12:12 <jsmith> +1
16:12:12 <contyk> so am I, +1
16:12:30 <jforbes> I am still +1
16:12:44 <nirik> +1here
16:12:55 <bowlofeggs> i thought we were gonna wait for bcotton to file a ticket?
16:12:57 <bowlofeggs> but i'm +1
16:13:58 <contyk> that would make sense but it wasn't what the minutes said :)
16:14:18 <contyk> but the change's been ready for wrangler for weeks
16:14:42 <zbyszek> bowlofeggs: it seems to have fallen through the cracks in the process
16:14:59 <zbyszek> I don't think we gain anything by waiting, it seems rather noncontroversial
16:15:12 <contyk> agreed
16:15:31 <bowlofeggs> yeah i'm not against +1ing it
16:15:36 <bowlofeggs> it's a good change
16:15:41 <zbyszek> The bonus is we get to finally handle a ticket before it's even opened
16:16:20 <contyk> #agreed GnuPG2 as the default GPG implementation approved (+7, 0, -9)
16:16:38 <contyk> alright, that's all for today
16:16:40 <jforbes> precog FESCp
16:16:44 <tyll> contyk, there is a typo in the agreed
16:16:52 <tyll> contyk, too many against
16:16:59 <bowlofeggs> -9
16:17:01 <bowlofeggs> haha
16:17:05 <contyk> #undo
16:17:05 <zodbot> Removing item from minutes: AGREED by contyk at 16:16:20 : GnuPG2 as the default GPG implementation approved (+7, 0, -9)
16:17:09 <bowlofeggs> 7 of us approved an unapproved it
16:17:10 <contyk> #agreed GnuPG2 as the default GPG implementation approved (+7, 0, -0)
16:17:18 <contyk> better? :)
16:17:22 <bowlofeggs> :)
16:17:25 <tyll> contyk++
16:17:25 <zodbot> tyll: Karma for psabata changed to 4 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:17:40 <contyk> #topic Next week's chair
16:17:54 <contyk> I won't be around next week
16:17:59 <contyk> any volunteers?
16:18:27 <zbyszek> *crickets
16:18:31 <zbyszek> I can do it
16:18:33 * tyll will be travelling
16:18:41 <contyk> thanks, zbyszek
16:18:45 <bowlofeggs> zbyszek wins the prize!
16:18:49 <contyk> #action zbyszek will chair the next meeting
16:18:53 <nirik> so I am guessing we will still be meeting the 10th and 17th, but skip 24th and 31st?
16:19:00 <contyk> #topic Open Floor
16:19:10 <contyk> nirik: good point
16:19:17 <jforbes> nirik: seems right
16:19:22 <zbyszek> nirik: +1
16:19:32 <contyk> nirik: +1
16:20:27 <tyll> nirik, +1
16:21:04 <contyk> #info No FESCo meetings on Dec 24 & Dec 31
16:21:19 <contyk> anything else?
16:22:20 <contyk> alright
16:22:24 <contyk> #endmeeting