16:00:20 <jforbes> #startmeeting FESCO (2018-01-12)
16:00:20 <zodbot> Meeting started Fri Jan 12 16:00:20 2018 UTC.  The chair is jforbes. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:20 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:20 <zodbot> The meeting name has been set to 'fesco_(2018-01-12)'
16:00:20 <jforbes> #meetingname fesco
16:00:20 <jforbes> #chair maxamillion dgilmore nirik jforbes jsmith kalev sgallagh bowlofeggs tyll
16:00:20 <zodbot> The meeting name has been set to 'fesco'
16:00:20 <zodbot> Current chairs: bowlofeggs dgilmore jforbes jsmith kalev maxamillion nirik sgallagh tyll
16:00:20 <jforbes> #topic init process
16:00:25 <bowlofeggs> .hello2
16:00:26 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <randy@electronsweatshop.com>
16:00:35 <sgallagh> .hello2
16:00:38 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:00:43 <kalev> .hello2
16:00:44 <zodbot> kalev: kalev 'Kalev Lember' <klember@redhat.com>
16:00:46 <maxamillion> .hello2
16:00:47 <nirik> morning
16:00:47 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
16:01:05 * jsmith waves
16:01:17 * dgilmore is kinda here
16:01:28 <dgilmore> but has a 30 minute conflict
16:02:17 <jforbes> Yeah, let's try to keep this quick, I have another meeting in an hour, though nirik agreed to chair the end if I have to go
16:02:24 <jforbes> Looks like we have quorum
16:02:31 <jsmith> WORKSFORME
16:02:39 <jforbes> #topic #1767 F28 Self Contained Changes
16:02:40 <jforbes> .fesco 1767
16:02:40 <jforbes> https://pagure.io/fesco/issue/1767
16:02:42 <zodbot> jforbes: Issue #1767: F28 Self Contained Changes - fesco - Pagure - https://pagure.io/fesco/issue/1767
16:03:15 <jforbes> There are quite a few here.
16:03:24 <maxamillion> is fontconfig really self contained?
16:03:36 <maxamillion> similar question for virtualbox guest
16:03:44 <nirik> +1 on all for me.
16:04:14 <jsmith> Honestly, the only one that gives me any heartburn is the Django one, and I'm still not concerned enough to give it a -1
16:04:18 <kalev> +1 on all for me as well, not sure it's worth nitpicking here whether they should be self contained or not
16:04:30 <jsmith> Count me as +1 to all of them
16:04:43 <maxamillion> kalev: is it not?
16:04:49 <sgallagh> maxamillion: vbox guest is really just adding packages to a comps group, isn't it?
16:04:51 <maxamillion> feel like now is the perfect time
16:05:02 <jforbes> maxamillion: virtualbox is.
16:05:14 <bowlofeggs> i am +1 to all as well
16:05:20 <sgallagh> +1 to all of them
16:05:27 <jforbes> +1 to all here too
16:05:33 <sgallagh> The details of the implementations will (as always) be worked out as we go
16:05:35 <maxamillion> jforbes: alright, your answer to that was the one I was looking for mostly .... I know virtualbox does ugly things in kernel land but didn't know if that extended to the guest bits
16:05:42 <maxamillion> alright
16:05:44 <maxamillion> +1 to all
16:05:48 <bowlofeggs> jsmith: the django one does have a plan to continue providing the old django version for py 2
16:06:12 <jsmith> bowlofeggs: I saw that, but I'm concerned that the compat version will be abandonware... maybe it's an unfounded concern
16:06:21 <bowlofeggs> yeah possible
16:06:22 <sgallagh> jsmith: Additionally, I'm going to be using Djagno as a prototype for a module
16:06:44 <jsmith> OK, sounds like I shouldn't worry then :-)
16:06:58 <jforbes> #agreed Current self contained changes are approved (+7,0,-0)
16:07:10 <jforbes> pingou: around?
16:07:47 <jforbes> Pingou needs to be present for 1810, but he has time constraints
16:07:50 <jforbes> #topic #1808 inclusion of crippled (but free?) AAC decoder
16:07:51 <jforbes> .fesco 1808
16:07:51 <jforbes> https://pagure.io/fesco/issue/1808
16:07:52 <zodbot> jforbes: Issue #1808: inclusion of crippled (but free?) AAC decoder - fesco - Pagure - https://pagure.io/fesco/issue/1808
16:08:11 <sgallagh> Workstation folks asked me to make sure this got considered today
16:08:44 <sgallagh> The concerns on this are basically:
16:08:55 <sgallagh> 1) Is the license actually free? RH-Legal says "yes"
16:09:25 <sgallagh> 2) Is the lack of *all* algorithms in the codec more of a problem than having none of it in the OS?
16:09:43 <bowlofeggs> for 1 i think we just go with RH legal
16:09:45 <kalev> I think it's a clear win to get AAC decoding into Fedora, even if it's less capable than what's available in 3rd party repos right now
16:09:53 <jsmith> I'm +1
16:10:05 <sgallagh> kalev: I think it's a win. I don't necessarily agree with "clear" :)
16:10:16 <kalev> fair enough :)
16:10:16 <jforbes> Right, so I would prefer uncrippled, but some is better than none in my opinion. I am sure people who want complete can get it from another repository. ABI compatible means it should be an improvmeent for all users
16:10:33 <bowlofeggs> yeah i think it could lead to negative press, but i also don't feel inclined to block it
16:10:34 <sgallagh> jforbes: That's actually my open question
16:10:36 <nirik> I'm +1 to adding it... but yes, we need to make sure its documented what it doesn't do...
16:10:44 <sgallagh> Is this going to be incompatible with the third-party one?
16:10:55 <jforbes> sgallagh: comment says it is compatible
16:10:58 <maxamillion> how difficult is it for someone to install the/an uncrippled codec to replace it if they 1) are willing to accept the realities of what that entails ... 2) want to
16:11:01 <maxamillion> ?*
16:11:12 <nirik> you would need to replace this one with a other party one... but thats the case for a number of things already.
16:11:25 * sgallagh nods
16:11:42 <sgallagh> Yeah, it's not possible to simply add another package and get the rest of the codec
16:11:47 <sgallagh> It has to be a *replacement*.
16:11:59 <jforbes> I am perfectly comfortable with the RH Legal results for the other issue
16:12:08 <sgallagh> I'm fine with making that a manual process, though
16:12:24 <jforbes> +1 here
16:12:28 <sgallagh> I'm +1
16:12:44 <pingou> jforbes: I am now, sorry for missing the slot :)
16:13:04 <kalev> +1
16:13:08 <bowlofeggs> yeah +1
16:13:08 <maxamillion> +1
16:13:19 <jforbes> pingou: will get you next
16:13:28 <pingou> tx
16:14:08 <jforbes> nirik jsmith?
16:14:14 <jsmith> still +1
16:14:16 <nirik> I am still +1
16:14:30 <jforbes> Oh, missed those further up :)
16:15:00 <jforbes> #agreed inclusion of crippled (but free?) AAC decoder is approved (+7,0,-1)
16:15:20 <sgallagh> Who was the -1? I missed it
16:15:33 <jforbes> #undo
16:15:33 <zodbot> Removing item from minutes: AGREED by jforbes at 16:15:00 : inclusion of crippled (but free?) AAC decoder is approved (+7,0,-1)
16:15:38 <jforbes> #agreed inclusion of crippled (but free?) AAC decoder is approved (+7,0,-0)
16:15:41 <jforbes> no one, thinko
16:15:51 <jforbes> #topic #1810 Let's flip the switch on January 15th: gating in Fedora
16:15:56 <jforbes> .fesco 1810
16:15:57 <zodbot> jforbes: Issue #1810: Let's flip the switch on January 15th: gating in Fedora - fesco - Pagure - https://pagure.io/fesco/issue/1810
16:16:05 <jforbes> https://pagure.io/fesco/issue/1810
16:16:45 <kalev> how would this work? is there any way to waive issues that the tests flag up, to still push builds through even if a test fails?
16:16:56 <sgallagh> As I hit a bug this week that gating would have prevented, I'm all for this :)
16:16:59 <pingou> yes that is waiverdb
16:17:17 <maxamillion> yeah, I'm in
16:17:21 <maxamillion> I love the idea
16:17:29 <pingou> kalev: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/thread/MUZSA4Q5LMQAIQAWZY23LOU7XMNSILOE/ has a summary of how things work
16:17:39 <jsmith> I'm cautiously optimistic on this
16:17:41 * nirik is +1
16:17:50 <jsmith> Count me as a hopeful +1
16:17:58 <jforbes> pingou: are these using koji builds now, or using their own builds still?
16:18:11 <jsmith> (If it fails horribly, we can always turn it back off, I'm assuming)
16:18:11 <tyll> .hello till
16:18:12 <zodbot> tyll: till 'Till Maas' <opensource@till.name>
16:18:27 <bowlofeggs> i don't think there is a way to waive failed test results yet
16:18:30 <sgallagh> To be fair, I expect this to be a rocky process, but one that we have to do if we want to continue maintaining our usual level of excellence into the next ten years
16:18:54 <sgallagh> I'm +1
16:18:54 <pingou> jforbes: for the atomic CI tests, still their own builds
16:18:59 <maxamillion> +1
16:19:01 <jforbes> bowlofeggs: what is the wait on that?
16:19:33 <pingou> but we're working on a) have a separate pipeline that will work on all packages and not do the build step and b) have the atomic CI pipeline do the build elsewhere
16:19:45 <bowlofeggs> jforbes: there is a proposed PR on bodhi, but it's not merged yet (and i've been on PTO a lot lately and have been catching up on other fires)
16:19:51 <kalev> ahhh, so this is only enabled for packages that explicitly add tests in dist git? so for packages that don't have tests in dist git it doesn't change anything?
16:19:55 <bowlofeggs> i don't think we can have that patch on production by jan 15
16:19:58 <pingou> bowlofeggs: there is, the UI in bodhi isn't there but the functionality is
16:20:00 <bowlofeggs> since that is monday
16:20:17 <jforbes> kalev: correct
16:20:20 <pingou> kalev: yes
16:20:31 <kalev> awesome, +1 then! sounds like a great way to start testing it
16:20:33 <pingou> kalev: and be part of fedora-atomic hosts, so that quite limits the set
16:20:51 <jforbes> I am +1 though will be more enthusiastic when the tests are run on actual koji builds (kernel and a few other packages can't really use it until then)
16:20:57 <bowlofeggs> pingou: is there some other way to waive tests wthout the bodhi ui?
16:21:00 <pingou> jforbes: same here
16:21:37 <bowlofeggs> like a CLI or something?
16:21:49 <pingou> bowlofeggs: I assume so since the integration with bodhi wasn't part of the original plans
16:22:00 <pingou> (where only rel-eng would be able to waive tests)
16:22:25 <bowlofeggs> i would feel concerned about enabling it unless we knew for sure there was a way to waive
16:22:30 * pingou makes a note to confirm this
16:22:54 <bowlofeggs> also, i will be on PTO on jan 15, so i won't be around to make the config change (someone from infra can though)
16:23:16 <bowlofeggs> (config change to bodhi, to turn gating on)
16:23:22 <jforbes> bowlofeggs tyll votes?
16:23:58 <bowlofeggs> jforbes: i have a conditional +1 - if it isn't possible to waive, i'm a -1.
16:24:05 <pingou> bowlofeggs: I'm fine with waiting an extra day to ensure you're there
16:24:10 <bowlofeggs> things will not be good if waiving can't be done yet
16:24:19 <tyll> I am also +1 with waiving enabled
16:24:22 <pingou> https://src.fedoraproject.org/rpms/waiverdb
16:24:26 <pingou> I'm being pointed to ^
16:24:28 <pingou> (thanks threebean )
16:24:46 <threebean> waiverdb-cli is packaged, yup.
16:24:54 <pingou> %package cli
16:24:55 <pingou> Summary: A CLI tool for interacting with waiverdb
16:25:00 <pingou> Primarily, submitting new waiverdbs.
16:25:08 <jforbes> #agreed Issue #1810: Let's flip the switch on January 15th: gating in Fedora is approved (+8,0,-0)
16:25:15 <bowlofeggs> cool
16:25:15 * threebean grumbles.  should be "new waivers."
16:25:17 <pingou> thanks threebean
16:25:24 <jforbes> That seems to settle it then :) Thanks threebean and pingou
16:25:41 <jforbes> #topic #1811 F28 System Wide Change: GHC 8.2
16:25:41 <jforbes> .fesco 1811
16:25:41 <jforbes> https://pagure.io/fesco/issue/1811
16:25:48 <zodbot> jforbes: Issue #1811: F28 System Wide Change: GHC 8.2 - fesco - Pagure - https://pagure.io/fesco/issue/1811
16:26:19 <kalev> +1
16:26:20 <maxamillion> sorry, GNOME crashed ... reading backscroll
16:26:31 <nirik> +1
16:26:43 <jsmith> +1
16:26:44 <maxamillion> +1
16:26:50 <maxamillion> good, didn't miss too much :)
16:26:51 <tyll> +1
16:26:57 <sgallagh> +1
16:26:59 <dgilmore> +1 to GHC
16:27:01 <bowlofeggs> +1
16:27:08 <jforbes> Gnome seems to crash for me a bit lately too, when the monitor turns off
16:27:10 <jsmith> maxamillion: You running rawhide, by chance?
16:27:11 <jforbes> +1 here too
16:27:17 <dgilmore> my other meeting is finished now
16:27:43 * jsmith has seen lots of Gnome crashes in Rawhide (using Wayland) when an app opens a new window
16:27:57 <jforbes> #agreed Issue #1811: F28 System Wide Change: GHC 8.2 is approved (+9,0,-0)
16:28:14 <nirik> jsmith: yeah, have hit that here a few times too... haven't isolated it enough for a bug yet.
16:28:26 <jforbes> #topic #1812 F28 System Wide Change: Hardening Flags Updates for Fedora 28
16:28:26 <jforbes> .fesco 1812
16:28:26 <jforbes> https://pagure.io/fesco/issue/1812
16:28:30 <zodbot> jforbes: Issue #1812: F28 System Wide Change: Hardening Flags Updates for Fedora 28 - fesco - Pagure - https://pagure.io/fesco/issue/1812
16:28:51 <jsmith> nirik: Me either :-(
16:29:23 <nirik> +1
16:29:29 <jsmith> +1 from me
16:29:34 <tyll> +1
16:29:54 <dgilmore> +1
16:29:57 <sgallagh> +1
16:30:13 <bowlofeggs> +1
16:30:15 <maxamillion> reading, sorry ... just a sec
16:30:24 <kalev> +1, I assume if any of the flags is causing large scale breakage it is going to backed off
16:30:40 <maxamillion> yeah, +1
16:31:16 <jsmith> I would assume so
16:31:37 <jforbes> I am conditionally +1 only because I am curious as to the impacts of this and the discussion of retpoline upstream.
16:32:17 <fweimer> jforbes: Retpolines aren't planned for Fedora 28.
16:32:35 <fweimer> (Except for the kernel.)
16:33:08 <jforbes> fweimer: There was some discussion about using them for other packages as well. I wasn't certain it had been fully hashed out yet
16:34:03 <jforbes> Either way, that would be another change submission that would need an exception and such. So no problem in approving this now and considering again if that is needed
16:35:28 <jforbes> #agreed  Issue #1812: F28 System Wide Change: Hardening Flags Updates for Fedora 28 is approved (+9,0,-0)
16:35:47 <jforbes> topic #1813 F28 System Wide Change: Strong crypto settings
16:35:47 <jforbes> .fesco 1813
16:35:47 <jforbes> https://pagure.io/fesco/issue/1813
16:35:48 <zodbot> jforbes: Issue #1813: F28 System Wide Change: Strong crypto settings - fesco - Pagure - https://pagure.io/fesco/issue/1813
16:36:29 <nirik> sure, +1
16:36:36 <bowlofeggs> +1
16:36:43 <jforbes> +1
16:36:44 <maxamillion> +1
16:36:49 <dgilmore> +1
16:37:00 <sgallagh> +1
16:37:29 <tyll> +1
16:37:38 <jsmith> +1
16:37:40 <kalev> +1
16:38:15 <jforbes> #agreed Issue #1813: F28 System Wide Change: Strong crypto settings is approved (+9,0,-0)
16:38:28 <jforbes> #topic Next week's chair
16:38:59 <sgallagh> I probably won't make the meeting next week
16:39:28 <dgilmore> I will always be late until daylight savings starts again
16:39:51 <jforbes> Any takers?  I will have the same conflict next week 1 hour after start so chairing might be difficult
16:40:14 <maxamillion> I can take next week
16:40:24 <dgilmore> if we start half an hour late I can take it
16:40:55 <jforbes> #info maxamillion will chair next week
16:40:58 <jforbes> thanks maxamillion
16:41:05 <jforbes> #topic Open Floor
16:41:22 <sgallagh> I have one item for Open Floor
16:41:23 <nirik> I had one quick item to note.
16:41:35 <sgallagh> Go ahead nirik, mine may not be quick
16:42:28 <nirik> was just going to mention there was discussion about updates and the batching policy on the devel list. If someone wants to propose changes to those feel free... I am not sure what would be best, as there are many knobs to turn.
16:43:11 <sgallagh> Ha, that was the same topic I was going to bring up
16:43:30 <jforbes> nirik: I have been following that discussion. But haven't come to the point of a proposal yet. I think we might need some client work to come up with a better solution
16:43:32 <jsmith> I'm not sure it isn't just a matter of communication and documentation, rather than a real technical problem per se
16:43:48 <dgilmore> what jsmith said
16:44:05 <nirik> I was meaning to look more at stats, but haven't had time...
16:44:07 <sgallagh> I'd like to propose that we limit the set of people who can push non-urgent-security updates directly to stable to a limited set.
16:44:11 <sgallagh> And make batched otherwise mandatory.
16:44:16 <nirik> in particular how many maintainers push to stable directly.
16:44:26 <jforbes> I do
16:44:35 <jforbes> Pretty much every update
16:44:39 <dgilmore> jforbes: you do what?
16:44:51 <jforbes> push to stable directly and bypass batch
16:45:17 <jforbes> Mainly because kernel seems to get a number of CVEs
16:45:23 <bowlofeggs> it may be possible to get data on how often that happens
16:45:31 <dgilmore> we would probably need to look at the data inBodhi to see what is going on
16:45:48 <dgilmore> bowlofeggs: the data should be there
16:45:50 <bowlofeggs> a lot of updates i've followed do use the batching system, but that's anecdotal
16:46:00 <bowlofeggs> dgilmore: yeah it is - we just look at the comments
16:46:14 <dgilmore> just need the right query
16:46:28 <nirik> looks like tons of maintainers push to stable
16:46:51 * jsmith has certainly pushed to stable a few times
16:47:09 <nirik> https://paste.fedoraproject.org/paste/McKrqEwKOyCNQPzoIVfTsA for january 2018 if I got it right.
16:47:17 <sgallagh> So, in other words, the batching is completely useless at the moment because we don't enforce it
16:48:20 <nirik> well, s/don't enforce/maintainers don't understand why they shouldn't bypass it normally/
16:48:41 <bowlofeggs> there might be some "maintainers don't agree with the idea" too
16:49:34 <nirik> there's definitely at least one of those (see thread)
16:50:01 <bowlofeggs> i haven't caught up with the thread yet (just got back from a long PTO), but i'll look soon
16:50:16 <nirik> btw, if you don't exclude bodhi from the query:
16:50:19 <nirik> 387 bodhi
16:50:28 <nirik> so, there are a good deal that are using batches
16:50:37 <bowlofeggs> yeah that sounds to me like most are actually
16:50:53 <nirik> but if you have just 1 per day that isn't...
16:50:59 <nirik> it makes batched pretty useless.
16:51:37 <dgilmore> indeed
16:52:23 <nirik> we could easily 'enforce' things by just not doing pushes every day. Look for urgent things, if not, no push
16:52:42 <nirik> but then people get upset.
16:53:04 <bowlofeggs> if fesco wanted to set a policy around it, bodhi could also just enforce it directly
16:53:05 * jforbes notes that batched isn't even mentioned in https://fedoraproject.org/wiki/Updates_Policy
16:53:14 <bowlofeggs> but then people might falsely mark updates as urgent
16:53:15 <dgilmore> nirik: we could just push only updates-testing
16:53:20 * sgallagh was wondering which one he had done; it was a security update that I mis-categorized, so I pushed it to stable.
16:53:37 <sgallagh> bowlofeggs: If they start doing that, they get warned and then lose packager status
16:53:39 <bowlofeggs> jforbes: that's because there hasn't been any policy around it so far
16:53:48 <nirik> jforbes: yeah, docs are... not very existant around this
16:54:05 <bowlofeggs> there are docs about this actually
16:54:17 <bowlofeggs> see https://fedoraproject.org/wiki/Bodhi#Package_States
16:54:44 <jforbes> bowlofeggs: even without policy, it could be linked to as a best practice type of thing
16:55:00 <jforbes> bowlofeggs: realistically, who ready bodhi docs other than maybe new packagers?
16:55:09 <bowlofeggs> i also recently wrote https://github.com/fedora-infra/bodhi/blob/develop/docs/user/update_states.rst which will appear in the bodhi 3.3.0 docs
16:55:47 <nirik> did we ever send anything about it to devel-announce?
16:55:56 <bowlofeggs> jforbes: yeah we could mention best practices
16:56:19 <bowlofeggs> nirik: i can't remember for sure, but i think we did. i know for sure it was discussed a lot on devel
16:56:28 <nirik> the updates_policy page has a bunch of "SHOULD"s
16:56:34 <tyll> Do we all agree that enforcing/handling batched is something that should be done in Bodhi btw? I was wondering if it would be more useful to just mark an updates as badged/low priority in the metadata and then let dnf/packagekit decide when to install batched/low priority updates.
16:56:39 <nirik> ie, you should do this...
16:57:16 <nirik> tyll: batched is not composed to any repo (well, updates-testing I guess)
16:57:23 <bowlofeggs> tyll: one problem is that there is more than one package manager involved
16:57:25 <sgallagh> tyll: It needs to be done in Bodhi because otherwise we're wasting metadata download
16:57:36 <bowlofeggs> tyll: since gnome updates doesn't use dnf, for example
16:57:40 <nirik> yes, we did send to devel-announce.
16:59:11 <jforbes> https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/message/UDXVXLT7JXCY6N7NRACN4GBS3KA6D4M6/ (and it sounds like feature if you want to use it, but totally optional)
16:59:13 <bowlofeggs> i assume changes to update policy are a fesco thing? even shoulds?
16:59:15 <dgilmore> gnome-software does its own thing tryuing to make it look like updates are done in batches
16:59:28 <nirik> I can try and add into Updates_policy, or propose changes to it for next week?
16:59:37 <nirik> bowlofeggs: yes
16:59:55 <tyll> sgallagh: I do not follow regarding the metadata, since the updates-testing metadata will be different already if there is just one non-batched update
17:00:04 <bowlofeggs> jforbes: yeah the original intent was to make it the packager's choice
17:00:30 <jforbes> bowlofeggs: Right, so why get up in arms when people follow that intent?
17:00:43 <bowlofeggs> jforbes: well i'm not upset when people push to stable myself
17:01:04 <nirik> jforbes: I'm not up in arms, but it means that the feature is usless and doesn't help any. ;(
17:01:18 <sgallagh> Yeah, I'm with nirik here.
17:01:33 <sgallagh> I think we either set a required policy on batched or we drop it completely.
17:01:39 <bowlofeggs> well i think it can stil help a little - your package manager won't think there are updates as often, especially if your system has a more minimal package set
17:01:40 <sgallagh> But the current state is meaningless
17:02:03 <bowlofeggs> i still think it has some purpose, even if it doesn't stop the daily compose from happening (and metadata being downloaded)
17:02:05 <jforbes> I don't really see what it helped to begin with, but I have always managed updates with 'sudo dnf update'
17:02:13 <nirik> bowlofeggs: if we compose that repo, you (and every other fedora user on the planet due to dnf makecache timer) will download the metadata...
17:02:20 <bowlofeggs> i wouldn't say useless or meaningless, but i would agree that an enforcement could achieve mroe
17:02:43 <bowlofeggs> nirik: yes, but your PM might also say "nothing to do" more often than before, which i think is useful
17:02:53 <jforbes> Then again, I use updates-testing, so it wouldn't be visible to me eithe rway
17:04:23 <jforbes> So, propose we open an issue to discuss whether a policy around this should be created at all?
17:04:33 <bowlofeggs> sure
17:04:41 <nirik> bowlofeggs: not sure how useful that is, but sure
17:05:47 <nirik> anyhow, sure we can propose things... food for thought.
17:05:47 <sgallagh> jforbes: Yes
17:05:52 <tyll> Is there some kind of description about the goals that we would like to achieve with the batched feature?
17:06:01 <jforbes> So who wants to create this issue?
17:06:19 <tyll> E.g. if the idea is to avoid metadata traffic, then maybe the metadata itself could be improved
17:06:25 <dgilmore> seems like we should file a issue, and track/participate in the discussion on devel list
17:06:32 <nirik> tyll: IMHO it was to reduce metadata downloads...
17:06:45 <bowlofeggs> the original goal was to reduce the number of daily updates for end users, and iirc was proposed by mattdm
17:06:49 <nirik> and sure, but there has been talk about that for like 10 years.
17:06:59 <bowlofeggs> nirik: i don't think it was about metadata originally
17:06:59 <tyll> I assumed it was to provide administrators with a fixed patch day :-)
17:07:12 <dgilmore> there is conlicts between, dnf gnome-software and bodhi in how updates are and should be managed
17:07:24 <nirik> it could make it worse for daily updates for end users...
17:07:40 <dgilmore> there is conflicts between, dnf gnome-software and bodhi in how updates are and should be managed
17:08:10 <nirik> foo and bar are in updates-testing, foo is pushed to stable, user updates, the next day bar is pushed to stable user updates. Without batches they would have both been on one day and no updates the second day
17:08:21 <kalev> I'm happy to make gnome-software weekly updates follow the batched schedule, by the way
17:08:42 <tyll> Btw. we could also do badges for pushing updates to batched if we would like to promote this btw
17:08:43 <kalev> but I think gnome-software needs some help to know when new batched has landed, like a batched push serial number or something in the metadata
17:09:00 <dgilmore> kalev: it should just follow the distros updates and not try to do its own thing honestly
17:09:37 <kalev> sure, if we get enforced batched state then it might be possible :)
17:09:37 <nirik> dgilmore: update daily? I think some people would find that anoying.
17:09:50 <nirik> I can file the ticket...
17:10:02 <nirik> jforbes: you still around, or want me to finish up the rest of the meeting
17:10:23 <jforbes> nirik: I am, but this just started.
17:10:43 <jforbes> #info nirik will file a ticket to discussed batched policy
17:10:47 <dgilmore> nirik: sure, but as it is things are quite broken by gnome-software implementing its own policies
17:10:48 <jforbes> Anyone have anything else?
17:11:10 <dgilmore> I have one thing
17:11:33 <dgilmore> it will come up next week I guess, I may have missed it this week with my conflict https://fedoraproject.org/wiki/Changes/AArch64_Server_Promotion
17:11:48 <dgilmore> it would be good to get FESCo people to weigh in on the discussion
17:13:31 <maxamillion> is there hardware people can get their hands on yet?
17:13:55 <jforbes> nirik: mind taking over, my attention is going elsewhere.
17:14:01 <nirik> sure.
17:14:11 <jforbes> thanks
17:14:12 <dgilmore> there is various SBC's that work well, and there is more expensive enterprise hardware available
17:14:39 <maxamillion> ah ok, I didn't realize there was support for man SBCs yet, but I see them in the wiki page https://fedoraproject.org/wiki/Changes/aarch64SBCImages
17:14:42 <dgilmore> AFAIK RHEL officially supports aarch64 as of 7.4
17:15:11 <fweimer> dgilmore: RHELSA 7.4 was a developer preview.
17:15:21 <fweimer> RHEL Server for ARM is a separate product.
17:15:21 <dgilmore> fweimer: yes its dead
17:15:26 <maxamillion> RHEL officially supports POWER and s390x also ... that hasn't really changed those architecture's Fedora status, nor should it have any influence
17:16:04 <dgilmore> maxamillion: I am only using it as an example to show that there is wide support
17:16:14 <maxamillion> dgilmore: fair
17:16:35 <dgilmore> I am not saying because RHEL does we should move it to primary, but that RHEL supports it because there is hardware available
17:17:30 <dgilmore> anyway, I just thought it would be good to make sure that we thought about it and engaged in the discussion about it
17:18:02 <nirik> #info everyone should think about and discuss https://fedoraproject.org/wiki/Changes/AArch64_Server_Promotion
17:18:04 <maxamillion> does the AArch64 Fedora SBC "Pine64 (all variants)" also means it supports the Pinebook?
17:18:43 <dgilmore> maxamillion: the pinebook works. but only via serial currently
17:19:03 <maxamillion> :/
17:19:21 <dgilmore> I believe there will be basic video support soonish, in the next 2 upstream kernel releases
17:19:42 <dgilmore> the pine64 hardware is all serial only
17:19:45 * nirik nods. That was my understanding as well.
17:20:04 * dgilmore has a couple of them up and running
17:20:18 <dgilmore> and a 64 bit orangepi also
17:20:36 <tyll> what would be the expected problems with promoting Aarch64 as primary?
17:21:14 <dgilmore> tyll: well propting it only for server is the proposal
17:21:24 <dgilmore> workstation etc would stay secondary
17:22:01 <dgilmore> we would have to put Everything Server and updates on the mirrors in /pub/fedora
17:22:25 <nirik> and it would become release blocking right?
17:22:32 <dgilmore> it would use a little more space on the master mirrors
17:22:36 <dgilmore> it would be
17:22:45 <tyll> ah, ok, thank you
17:22:58 <sgallagh> Right, the Server SIG will be voting on Tuesday if we're comfortable making it release-blocking
17:23:02 <sgallagh> (I'm in favor, for the record)
17:23:19 <nirik> ok, anything else on this?
17:23:58 <nirik> or anything else for open floor?
17:24:46 <nirik> ok, will close out in a min if nothing else.
17:24:58 <nirik> https://pagure.io/fesco/issue/1820 is the batched updates ticket
17:25:06 <sgallagh> Thanks jforbes and nirik for chairing!
17:25:44 <tyll> thank you
17:25:48 <nirik> #endmeeting