15:00:13 <mhroncok> #startmeeting FESCO (2019-05-10)
15:00:13 <zodbot> Meeting started Fri May 10 15:00:13 2019 UTC.
15:00:13 <zodbot> This meeting is logged and archived in a public location.
15:00:13 <zodbot> The chair is mhroncok. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:13 <zodbot> The meeting name has been set to 'fesco_(2019-05-10)'
15:00:13 <mhroncok> #meetingname fesco
15:00:13 <zodbot> The meeting name has been set to 'fesco'
15:00:13 <mhroncok> #chair nirik, bowlofeggs, jforbes, zbyszek, bookwar, sgallagh, contyk, mhroncok, otaylor
15:00:13 <zodbot> Current chairs: bookwar bowlofeggs contyk jforbes mhroncok nirik otaylor sgallagh zbyszek
15:00:13 <mhroncok> #topic init process
15:00:20 <contyk> .hello psabata
15:00:21 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:00:24 <jforbes> .hello2
15:00:25 <zodbot> jforbes: jforbes 'Justin M. Forbes' <jforbes@redhat.com>
15:00:38 <bowlofeggs> .hello2
15:00:39 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <rbarlow@redhat.com>
15:00:48 <nirik> morning
15:00:57 <bowlofeggs> are you going ready to RULE
15:02:00 <mhroncok> I see contyk, jforbes, bowlofeggs, nirik and myself, that's 5
15:02:14 <mhroncok> sgallagh won't make it today
15:02:19 <zbyszek> .hello2
15:02:19 <contyk> if one of us leaves, we can go home
15:02:19 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:02:27 <bowlofeggs> contyk:haha
15:02:30 <mhroncok> contyk: make it 2 now :)
15:02:51 <zbyszek> Sorry I'm late.
15:03:00 <zbyszek> Whats the quorum status?
15:03:04 <mhroncok> zbyszek: 6
15:03:22 <zbyszek> Oh.
15:03:50 <mhroncok> lets start at :05
15:04:00 <zbyszek> Why the delay?
15:04:11 <contyk> for the suspense
15:04:26 <jforbes> Yeah, I only saw sgallagh say he wouldn't make it. I didn't expect a lack of quorum
15:05:13 <mhroncok> #topic #2088 F31 Change – “dnf --best” as default behavior
15:05:24 <mhroncok> .fesco 2088
15:05:26 <zodbot> mhroncok: Issue #2088: F31 Change – “dnf --best” as default behavior - fesco - Pagure.io - https://pagure.io/fesco/issue/2088
15:05:42 <zbyszek> So... nothing new here?
15:06:08 <mhroncok> not really
15:06:15 <nirik> I think bowlofeggs's proposal was nice, but yeah, it needs upstream buy in and implementation...
15:06:32 <mhroncok> upstream is not sure whatever it is deliverable
15:07:39 <mhroncok> I really think we should either move this forward or reject it
15:07:51 <mhroncok> and it is frankly not moving anywhere
15:08:33 <contyk> that sounds reasonable
15:08:35 <zbyszek> I think we should reject the proposal in current form.
15:08:46 <zbyszek> "Please come back with a new proposal when ready."
15:08:49 <contyk> previously I was okay with this in stable and against it in rawhide
15:08:51 <bowlofeggs> yeah i'm -1 unless they can provide a better user experience
15:09:07 <contyk> I don't really have a strong opinion, though; let alone on the implementation details or messages
15:09:16 <bowlofeggs> to be clear, i'm not demanding they do exactly what i proposed, just something to address the possible problem of a user missing a security update
15:09:44 <bowlofeggs> i'm open to other ideas on that, but i don't like that the proposal will result in people missing security updates taht they don't miss today
15:09:48 <mhroncok> proposal: FESCo rejects the change proposal as is. please come back with a new proposal when ready. move the discussion to the devel ML.
15:09:50 <zbyszek> bowlofeggs: yeah, I think it's understood that we're not talking about the details, but about the general user experience
15:09:56 <bowlofeggs> mhroncok: +1
15:10:04 <zbyszek> mhroncok: +1
15:10:07 <nirik> +1
15:10:12 <jforbes> +1
15:10:26 <contyk> so what exactly should they change in their proposal?
15:10:56 <mhroncok> contyk: that's an open ended question. that's why i proposed to move the discussion to devel
15:11:19 <zbyszek> contyk: make it discoverable to users that important updates are not installed and what options could be used to install them.
15:11:33 <contyk> it feels like we're refusing it for no reason, just "come up with something different, no likey"
15:11:40 <nirik> I think there's better ways to determine what packages are broken than making our end users hit them... and we should do that instead of this.
15:11:53 <contyk> zbyszek: isn't that part of the error message with --best?
15:12:00 <contyk> while today the updates are ignored silently
15:12:23 <zbyszek> First, they are not ignored silently. The output is there.
15:12:40 <zbyszek> Second, --best is a really terrible experience for users.
15:12:47 * contyk shrugs
15:13:01 <contyk> +0
15:13:02 <bowlofeggs> contyk: well i proposed a user experience that would solve my concern, so i dint' think it's "come up with something different"
15:13:32 <bowlofeggs> and it's not no reason either - this will result in users missing security updates
15:13:50 <mhroncok> #agree FESCo rejects the change proposal as is. please come back with a new proposal when ready. move the discussion to the devel ML. (+5, 1, -0)
15:14:01 <contyk> bowlofeggs: they can miss them today too
15:14:16 <contyk> but let's move that to the ML then
15:14:19 <bowlofeggs> contyk: this will result in *more* of them being missed than today's situation
15:14:25 <bowlofeggs> moves teh needle int eh wrong direction
15:14:30 * nirik notes some bugfixes are more important that some security updates, but sure.
15:14:35 <zbyszek> contyk: (In my evalatuation of this) the proposal makes user experience noticably worse. And I did set the option to see how my system behaves with it, for a while, and it wasn't nice.
15:14:37 <bowlofeggs> nirik: also true
15:14:47 <mhroncok> ready to move on?
15:15:17 <mhroncok> #topic #2120 F31 Change: Adopt new Go Packaging Guidelines
15:15:17 <mhroncok> .fesco 2120
15:15:19 <zodbot> mhroncok: Issue #2120: F31 Change: Adopt new Go Packaging Guidelines - fesco - Pagure.io - https://pagure.io/fesco/issue/2120
15:15:45 <bowlofeggs> has FPC looked at this?
15:15:55 <bowlofeggs> and isn't this FPC's domain anyway (i.e., not us?)
15:16:09 <contyk> bowlofeggs: I'd say so
15:16:12 <mhroncok> I see 2 ways to go
15:16:33 <mhroncok> 1) say this not a change material and delegate to the fpc only
15:16:39 <contyk> +1
15:17:01 <jforbes> The last comment in the ticket said the fpc would revisit, but no update on their revisit
15:17:03 <mhroncok> 2) keep the change (for documentation purposes and migration notes, etc.), but only ack the FPC decision on this
15:17:15 <bowlofeggs> i'm +1 to option 1
15:17:22 <contyk> definitely option 1
15:17:23 <zbyszek> The Change is a combo: guidelines update + mass package change. I think it's OK that we give our blessing at least to the second part.
15:17:30 <bowlofeggs> this is why we have the FPC AFAIK
15:17:43 <mhroncok> I'm leaning to 2) for what zbyszek said
15:17:47 * nirik too
15:18:21 <zbyszek> proposal: The Change is accepted conditional on FPC accepting the change to the Guidelines.
15:18:23 <bowlofeggs> what if we ask them to alter the change to be just about the second part then?
15:18:27 <bowlofeggs> zbyszek: +1
15:18:39 <mhroncok> zbyszek: +1
15:18:41 <jforbes> zbyszek: +1
15:18:48 <nirik> zbyszek: +1
15:18:55 <contyk> yeah, would make more sense if the change isn't about the guidelines, just the package update
15:19:03 <contyk> but fine, +1 to zbyszek
15:19:42 <mhroncok> #agree The Change is accepted conditional on FPC accepting the change to the Guidelines. (+6, 0, -0)
15:20:22 <nirik> jforbes: I think this last week they had no quorum, they did discuss it the week before...
15:20:53 <mhroncok> nirik: correct
15:20:57 <mhroncok> #topic Open Floor
15:20:59 <nirik> oh, I think they did approve it...
15:21:08 <bowlofeggs> wow, 20 minutes. go us!
15:21:11 <zbyszek> There was also movement in the other PRs... I think this is moving in the right direction, albeit a bit slowly.
15:21:15 <contyk> I have one thing for the open floor
15:21:23 <mhroncok> contyk: go
15:21:32 <zbyszek> contyk: the floor is yours, you have 100 minutes
15:21:37 <bowlofeggs> haha
15:21:56 <contyk> I was told about a bug in MBS today, one that prevents you from pulling a module that was built against an unsupported platform into the buildroot
15:22:12 <contyk> of course the javapackages-tools modules was built against f28 which will go eol soon
15:22:22 <mhroncok> what does "built against an unsupported platform" even mean?
15:22:35 <contyk> the MBS team doesn't have a fix yet; I wanted to raise this here for awareness
15:22:56 <contyk> mhroncok: the module was built against f28 and claims to run on all platforms, which should be perfectly fine
15:22:58 <mhroncok> I thought that we rebuild modules for all "platforms". we don't?
15:23:08 <contyk> mhroncok: but MBS refuses to use it because it was built against something it considers garbage
15:23:18 <contyk> that depends on what the maintainer configures
15:23:31 <mhroncok> and that makes sense, we have regular rebuilds in Fedora for a reason
15:23:37 <contyk> in the case of javapackages-tools they build once, run everywhere
15:23:47 <mhroncok> imagine a module build against f28 still being shipped in f35
15:23:59 <contyk> yeah, that would be okay in some cases
15:24:01 <mhroncok> Java, build once, run everywhere
15:24:06 <contyk> like this one
15:24:15 <bowlofeggs> since f28 is still supported, isn't that ok?
15:24:23 <bowlofeggs> or are you saying that in a month, it will still do f28?
15:24:38 <contyk> the reason I'm bringing it up is it most likely won't get fixed before it goes eol
15:24:40 <mhroncok> except we have new buildroot policies etc. that effectively are blocked by not rebuilding modules
15:24:53 <mhroncok> contyk: and a rebuild on f29 is not an option?
15:24:58 <contyk> it is
15:25:14 <mhroncok> so why don't we demand such thing then?
15:25:23 <mhroncok> make the bug a feature
15:25:24 <contyk> I think we should :)
15:25:32 <contyk> well, I wouldn't make it a feature
15:25:52 <mhroncok> we should demand it by policy, not broken tools
15:26:47 <nirik> we probibly need some way to notify affected module owners?
15:26:53 <contyk> yes
15:27:10 <contyk> and find out what those modules are; I'm only aware of that one but that doesn't mean it's the only one
15:27:22 <contyk> https://pagure.io/fm-orchestrator/issue/1243
15:27:25 <contyk> this is the issue, btw
15:27:38 <contyk> I suppose I can own this -- find the modules and file bugs for rebuilds
15:27:53 <nirik> +1
15:28:20 <mhroncok> contyk: and make a policy?
15:28:20 * nirik has one info item too when we are done with this one
15:28:29 <mhroncok> nirik: noted
15:28:50 <contyk> I'm not sure why we should mandate rebuilds
15:29:02 <mhroncok> contyk: why do we mandate them in Fedora proper?
15:29:20 <mhroncok> contyk: if the package built in F24 and is still installable, what's wrong with that?
15:29:21 <contyk> if the packages still follow guidelines and a rebuild changes nothing besides the timestamps, I'm not sure what the benefit is
15:29:42 <zbyszek> contyk: new gcc, new glibc, linker, flags, warnings
15:29:43 <contyk> mhroncok: that's a good question -- so why would you extend that rule rather than revisit it?
15:29:57 <contyk> zbyszek: doesn't affect everything
15:30:29 <bowlofeggs> i think it's easier to say to do it for everything than to try to analyze it on a case by case basis
15:30:30 <mhroncok> you are right. if it still is buildable and results only in timestamps bump, shipping the new build brings no benefit
15:30:33 <bowlofeggs> that's probably why
15:30:37 <zbyszek> But we do mass rebuilds because it's easier to rebuild everything than to consider each package individually... I think something similar would apply to modules.
15:30:38 <mhroncok> except it makes sure it is actually that way
15:31:09 <nirik> there are cases that affect everything... like rpm moving to xz or the like
15:31:38 <contyk> I'm not going to draft a policy for this :)
15:31:39 <mhroncok> new virtual provides, different man pages compression...
15:32:02 <mhroncok> contyk: who is?
15:32:16 <contyk> whoever feels it's necessary; that's not me
15:32:38 <contyk> I like giving the maintainers control over this
15:33:04 <contyk> currently they can declare they want to build for every release
15:33:14 <contyk> or declare they want to build once, against which, and where to run
15:33:23 <contyk> it's up to them
15:33:37 <mhroncok> can they build against epel?
15:33:47 <contyk> there's no epel with module support yet
15:33:53 <zbyszek> Dunno, this seems like a step back
15:33:55 <mhroncok> in theory, epel8
15:34:00 <contyk> in theory they can
15:34:18 <mhroncok> so in theory, they have an option to have a long supported build platfrom
15:34:40 <nirik> so, perhaps we shouldn't get mbs to change it's behavior?
15:34:43 <mhroncok> building once against f28 and keeping it shipped forever past f28 EOL is not good
15:35:17 <mhroncok> if I read that ticket correctly, it includes more problems
15:36:35 <nirik> if it could be enforced in mbs, no need for a policy. ;)
15:36:47 <mhroncok> right
15:37:03 <mhroncok> that's what I proposed in the first place, make the bug a feature
15:37:13 <contyk> if you want to set some rules here, it should be a policy, not the tool
15:37:41 <mhroncok> anyway
15:37:58 <contyk> yes, anyway :)
15:37:59 <mhroncok> #action contyk to find the modules (built on f28 only) and file bugs for rebuilds
15:38:05 <contyk> as I said, I'll find the modules and files bugs for rebuilds
15:38:09 <contyk> ack
15:38:18 <jforbes> thanks contyk
15:38:45 <mhroncok> #action mhroncok to open a followup ticket about the policy
15:38:54 <zbyszek> thank you both
15:39:06 <mhroncok> (not promising to draft the actual policy)
15:39:20 <mhroncok> move on? nirik...
15:40:30 <nirik> yeah, just real quick... we wrote up steps for epel8 (non modular) enablement: https://pagure.io/fedora-infrastructure/issue/7777 and will be working on those... if anyone sees something we missed or are going to do wrong, let us know. Hopefully we will have something in staging next week ish.
15:40:57 <nirik> this is mostly the same as for fedora...
15:41:22 <nirik> so once we have that we can also look at the fedora buildroot stuff
15:41:38 <mhroncok> nirik: so what's the modularity idea in EPEL -> default streams of modular packages in the buildroot?
15:42:55 <nirik> mhroncok: you mean the non modular builds? yes, default modules plus any buildroot only ones yes.
15:43:13 <contyk> I still owe nirik that releng ticket
15:43:24 <contyk> got a bit distracted this week
15:43:35 <nirik> modularity will need mbs work... we will have to figure a way to use external module repos or import modules into koji, not sure what the plan is there.
15:43:43 <nirik> contyk: no worries.
15:43:53 <mhroncok> so suppose there is a Python 3.6 module in RHEL, how do people build Python 3.6 packages? Is there a general "EPEL Python 3.6" module?
15:44:28 <mhroncok> or is everybody expected to create a singlepackage module for their package?
15:44:40 <nirik> if it's default, they will be able to build non modular packages against it.
15:44:47 <contyk> RHEL modules will be available in EPEL just like normal packages are
15:45:01 <contyk> and the defaults will be in the non-modular buildroot with this setup
15:45:12 <contyk> so... it should work
15:45:14 <contyk> should
15:45:22 <nirik> the S word! :)
15:45:32 <nirik> but yeah, we will see in staging...
15:45:48 <mhroncok> cool
15:46:00 <nirik> mhroncok: so, normal small python packages can just be non modular...
15:46:24 <nirik> but of course if the defaults change we need to rebuild everything... hopefully they don't often
15:46:26 <mhroncok> makes sense
15:46:59 <bowlofeggs> mhroncok: RFE: Please provide me with a Python 2.4 module - i'm gonna be a hipster and downgrade bodhi to that one. modern python just doesn't have the warmth of 2.4…
15:47:15 <bowlofeggs> vintage
15:47:24 <bowlofeggs> i can make my vintage small batch bodhi updates with 2.4
15:47:26 <nirik> to build against a non default module, you will have to make your thing a module. ;)
15:47:34 <contyk> rewrite it in php4
15:47:37 <bowlofeggs> hahaha
15:47:57 <bowlofeggs> the with statement makes things too easy!
15:48:18 <mhroncok> bowlofeggs: go with Python 1.5, it was so muách faster
15:48:20 * nirik thinks we are === done here.
15:48:24 <bowlofeggs> haha
15:48:27 <jforbes> Just a reminder. Nominations are open, there are currently only 3 nominated to fill 4 seats.
15:48:34 <bowlofeggs> nirik: oooh, is that a JS triple ='s‽
15:48:41 <bowlofeggs> we are the identity of done
15:48:41 <mhroncok> jforbes thanks
15:48:59 <mhroncok> #info Don't forget to nominate (self) if you want to run for FESCo
15:49:01 <nirik> bowlofeggs: php
15:49:07 <mhroncok> anything else for open floor?
15:49:21 <mhroncok> you can still have the floor for 70 minutes
15:49:34 <bowlofeggs> oh did php have that too? you know, i used to be a php developer, but it's been so long i can hardly remember anythign about it. it was 15 years ago that i last did that (at nortel networks!)
15:49:39 <bowlofeggs> now that's vintage!
15:50:18 <bowlofeggs> once you have 2 CEOs in a row go to prison, your company's stock tanks and you lose your job, you also forget everything you knew about php
15:50:20 <mhroncok> nirik: nice issue number for epel8 infra ticket
15:50:22 <bowlofeggs> it's like it was all a dream
15:50:44 <nirik> mhroncok: yeah, I expected smooge to get a stream of tokens. :)
15:51:11 <mhroncok> :D
15:51:28 <mhroncok> ok, I'll end...
15:51:33 <mhroncok> thanks all
15:51:41 <contyk> who's the chair next week?
15:51:43 <contyk> did I miss it?
15:51:44 <mhroncok> ah
15:51:48 <mhroncok> contyk++
15:51:48 <zodbot> mhroncok: Karma for psabata changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:51:56 <mhroncok> #topic Next week's chair
15:52:24 <contyk> then I guess I should do it
15:52:40 <contyk> it's been a while anyway
15:52:50 <mhroncok> #action contyk will chair next meeting
15:52:56 <mhroncok> contyk: thanks
15:53:20 <mhroncok> #endmeeting