17:00:12 <bcotton> #startmeeting F31 Beta Go/No-Go meeting
17:00:13 <zodbot> Meeting started Thu Sep 12 17:00:12 2019 UTC.
17:00:13 <zodbot> This meeting is logged and archived in a public location.
17:00:13 <zodbot> The chair is bcotton. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:13 <zodbot> The meeting name has been set to 'f31_beta_go/no-go_meeting'
17:00:14 <bcotton> #meetingname F31-Beta-Go_No_Go-meeting
17:00:14 <zodbot> The meeting name has been set to 'f31-beta-go_no_go-meeting'
17:00:21 <bcotton> #topic Roll Call
17:00:29 <adamw> .hello adamwill
17:00:30 <zodbot> adamw: adamwill 'Adam Williamson' <awilliam@redhat.com>
17:00:33 <pwhalen> .hello pwhalen
17:00:34 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com>
17:00:40 <coremodule> .hello2 coremodule
17:00:41 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
17:00:59 <lruzicka> .hello2
17:01:00 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
17:01:31 <alciregi> .hello2
17:01:32 <zodbot> alciregi: alciregi 'Alessio Ciregia' <alciregi@gmail.com>
17:01:32 <nirik> morning
17:01:33 <bcotton> i see the QA team is arriving in force to make me sad :-)
17:01:47 <pbokoc> .hello2
17:01:48 <zodbot> pbokoc: pbokoc 'None' <pbokoc@redhat.com>
17:02:03 <dump> .hello2
17:02:04 <zodbot> dump: Sorry, but you don't exist
17:02:31 <mhroncok> hi
17:02:58 <lbrabec> .hello2
17:02:59 <zodbot> lbrabec: lbrabec 'Lukas Brabec' <lbrabec@redhat.com>
17:03:27 <bcotton> okay, while folks are filing in (there are some seats up front still), i'll go ahead and do the boilerplate
17:03:38 <bcotton> #topic Purpose of this meeting
17:03:40 <bcotton> #info Purpose of this meeting is to check whether or not F31 Beta is ready for shipment, according to the release criteria.
17:03:41 <bcotton> #info This is determined in a few ways:
17:03:45 <bcotton> #info 1. No remaining blocker bugs
17:03:47 <bcotton> #info 2. Release candidate compose is available
17:03:48 <bcotton> #info 3. Test matrices for Beta are fully completed
17:04:36 <bcotton> let's get to item #1
17:04:43 <bcotton> #topic Current status — blocker bugs
17:04:52 <bcotton> #link https://qa.fedoraproject.org/blockerbugs/milestone/31/beta/buglist
17:05:03 <bcotton> #info 2 Proposed Blockers
17:05:04 <bcotton> #info 3 Accepted Blockers
17:05:27 <adamw> so, two of the accepted blockers are the same bug
17:05:27 <bcotton> i'll go through the accepted blockers first, since if we don't get that list down to zero, the proposed blockers can wait
17:05:50 <bcotton> #topic (1744266) Fedora 31 still using Fedora 30 backgrounds AND (1749086) Needs updating for Fedora 31 background etc.
17:05:56 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1744266
17:06:00 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1749086
17:06:13 <nirik> backgrounds. why is is always backgrounds. ;)
17:06:17 <bcotton> adamw: did i see on the mailing list that these are fixed enough to meet the criteria?
17:06:18 <adamw> so, i think we can say this no longer technically blocks beta
17:06:31 <adamw> the KDE background in beta-1.1 is wrong (it's an upstream background), but it is not the same as the f29 or f30 background
17:06:36 * satellit_ listening
17:06:44 <bcotton> that's technically correct, which is the best kind of correct
17:06:48 <mhroncok> :D
17:07:00 <adamw> so it satisfies the beta criteria. i'd propose we move it to Final blocker (per "The proposed final Fedora artwork must be included and used as the background on release-blocking desktops" criterion)
17:07:10 <bcotton> objections?
17:07:12 <coremodule> +1
17:07:12 <mhroncok> next time, we can put a big red letter over the last background saying TECHNICALLY CORRECT
17:07:15 <nirik> +1
17:07:18 <bcotton> mhroncok++
17:07:19 <pwhalen> xfce is also 'wrong', but also not the same as F30
17:07:31 <adamw> pwhalen: man. why is this so painful :/
17:07:35 <nirik> huh, nothing should have changed there. ;( Is there a bug on it?
17:07:49 <adamw> i can't figure out why kde is wrong either
17:07:53 <bcotton> #info KDE and XFCE backgrounds are 'wrong', but not the same as F29 or F30, so they do not violate the criteria
17:07:53 <adamw> backgrounds are just cursed
17:08:04 <pwhalen> nirik, dont think so. The right background is shown at login, but replaced once I log in
17:08:06 <adamw> pwhalen: can you file a bug for xfce and mark it as blocking Final?
17:08:12 <adamw> that's same for KDE
17:08:13 <lruzicka> nobody pays attention to them until it is too late
17:08:16 <pwhalen> adamw, will do
17:08:23 <adamw> login and lock screens get the right one, desktop doesn't
17:08:26 <adamw> lruzicka: oh, *I* do
17:08:28 <adamw> :P
17:09:01 <bcotton> #agreed BZs 1744266 and 1749086 satisfy the beta criteria and are moved to Final blocker per the "The proposed final Fedora artwork must be included and used as the background on release-blocking desktops" criterion
17:09:08 * nirik thinks he sees the Xfce issue. Dropped patch. ;(
17:09:10 <lruzicka> ack
17:09:13 <pwhalen> ack
17:09:24 <nirik> hum, or not. anyhow, we can fix it.
17:09:25 <nirik> ack
17:09:32 <bcotton> #info bcotton has started a conversation with design about changing the background deadline to avoid this
17:09:38 <bcotton> #link https://pagure.io/design/issue/657
17:10:12 <bcotton> anything else on backgrounds?
17:10:18 <adamw> oh
17:10:32 <adamw> can we also grant 'wrong background' bugs Beta FE, in case we slip and want to fix them?
17:10:40 <bcotton> +1
17:10:43 <pwhalen> +1
17:10:47 <lruzicka> +1
17:10:50 * nirik now has found the problem, a sed invocation.
17:10:51 <adamw> i'm +1 FE in general for any desktop having the wrong background, including specifically 1749086
17:11:11 <coremodule> +1
17:11:34 <lruzicka> yes, I do not suppose that adding a background could break something important, we could be adding an automated FE to backgrounds
17:12:13 <nirik> +1 on FE for those (if it's just that change)
17:12:20 * mboddu is here
17:12:20 <mhroncok> lruzicka: for a QA person, you sound overly optimistic
17:13:01 <bcotton> #agreed BZ 1744266 and 1749086 AcceptedFreezeException (Beta)
17:13:22 <bcotton> look at me skipping 'proposed #agreed' like a madman :-)
17:13:48 <lruzicka> mhroncok, well ... maybe you know more risks than I do, but adding a bunch of pngs should be safe ?
17:13:58 <adamw> bcotton: not 1744266...oh never mind.
17:14:06 <adamw> i already closed that one.
17:14:20 <adamw> lruzicka: breathing on things the wrong way can break everything sometimes. :P
17:14:58 <lruzicka> adamw, better to clean one's teeth then :D
17:15:07 <bcotton> 1744266 receives FE posthumous ly
17:15:21 <bcotton> #topic (1751438) Workstation x86_64 live image is over size target
17:15:22 <mboddu> May be we change the criteria to FE for beta and Blocker for Final on new backgrounds
17:15:23 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1751438
17:15:24 <bcotton> #info Accepted Blocker, LiveCD, NEW
17:15:32 <adamw> mboddu: that's already what they are.
17:15:49 <adamw> mboddu: the criteria can't dictate FEs. that's not what criteria are for.
17:15:51 <adamw> anyhoo
17:15:52 <adamw> so, yeah, this
17:15:55 <bcotton> is this where i remind everyone that we have a new policy for late-filed blockers? :-)
17:15:59 <mboddu> Oh, nvm then :)
17:16:01 <adamw> we should've known about this in June, but, uh, whoops.
17:16:12 <adamw> i mean, technically we knew about it, the script has been filing the results in the wiki religiously
17:16:17 <adamw> we just sort of forgot to notice and file a bug
17:16:34 <adamw> (in case anyone wondered, i've looked at making the robot file bugs but it's sort of awful)
17:17:02 <bcotton> i'm generally not a fan of rewriting our criteria on the fly (despite past evidence), but this one strikes me as a "do we actually care?", at least for beta
17:17:03 <nirik> so, can we just adjust the size and move on? or is there some need for the size asked for?
17:17:13 <adamw> so, yeah, we could try applying our new 'late-filed blocker' policy here (though it conflicts interestingly with the 'automatic blocker' policy in this case)
17:17:33 <adamw> the other fudge we have available is just to declare a new size target for workstation.
17:17:41 <bcotton> the current size is still larger than a CD and smaller than a DVD, so i'm not sure a slight overage actually matters unless someone can explain why
17:17:42 <adamw> but i kinda hate if we're perpetually doing that
17:18:01 <nirik> well, I think the idea was that it would fit on a 2gb usb...
17:18:01 <adamw> the ostensible justification for 2 power-of-ten GBs is USB sticks, i think.
17:18:01 <coremodule> you guys dont all install using cds?
17:18:06 <coremodule> what world have I been living in?
17:18:07 <coremodule> sheesh
17:18:13 <mboddu> I guess these size restrictions are for making bootable dvd's which is not a thing afaik, so we can change the criteria
17:18:14 <adamw> kalev: ahoy
17:18:19 <nirik> but 2gb usb's are... really small these days
17:18:41 * adamw wishes he had the log of the last time we argued the toss about this handy
17:19:00 <adamw> the other thing we can do is...just block on this
17:19:09 <lruzicka> I wonder, why we cannot keep the compose below 2gb when we know about this criteria?
17:19:10 <adamw> because, you know, some of those FEs look like things i'd kinda like fixed
17:19:16 <adamw> and we also have the GNOME 3.34.0 megaupdate lying around
17:19:17 <adamw> JUST SAYIN
17:19:38 <nirik> yeah, but people will get it in updates... 🤷
17:19:39 <adamw> lruzicka: we probably could fix this. just because no bug was filed, no-one looked at it
17:19:45 <bcotton> i would note here that optical boot is release blocking for workstation, so maybe "can be burned to a single DVD" is better than a set size
17:19:45 <adamw> won't be in the live image, though.
17:19:56 <nirik> right
17:19:58 <adamw> bcotton: i mean, for that you just declare the size limit as the size of a DVD
17:20:15 <adamw> bcotton: that's what all the '4.7 GB' limit images are
17:20:43 <bcotton> yeah. we probably shouldn't rewrite workstation's rules for them unannounced
17:20:46 <nirik> I guess I'd prefer to not block on this, but it would be good to have some workstation WG people weigh in.
17:20:59 <bcotton> so i'd say we either keep blocking on this or invoke the late blocker policy
17:21:13 <adamw> nirik: yeah, i just pinged #fedora-desktop
17:21:16 <nirik> late blocker vs auto blocking. FIGHT!
17:21:21 <adamw> DING DING DING
17:21:31 <lruzicka> bcotton, but it is not a late blocker this time ... it is a long time known problem that nobody thought was severe enough to report it
17:21:52 <adamw> but yeah tbh i'd quite like a beta with 1749433 fixed and 1731415 fixed and 1750120 fixed
17:22:04 <bcotton> lruzicka: sure, but that's why we wrote the policy. it was inspired by a similar issue in the last cycle
17:22:07 <adamw> lruzicka: no, that's not accurate
17:22:12 <mboddu> I kinda like adamw proposal to block it for the reasons he mentioned and also, we tested it for less than a day, I would like more days of testing
17:22:20 <adamw> lruzicka: it meets the policy definition perfectly
17:22:41 <adamw> "Last minute blocker bugs - bugs proposed as blockers 5 days or fewer before the scheduled Go_No_Go_Meeting for a milestone release (Beta or Final) can be considered under this policy"
17:22:41 <pwhalen> mboddu, adamw I tend to agree.
17:22:47 <adamw> ok, this was proposed and accepted at the same time, but eh.
17:22:57 <lruzicka> adamw, so I maybe do not understand what a late blocker is ... I thought it is something found in the last hours before go/nogo
17:23:01 <adamw> mboddu: yeah, late arrival of the candidate is also a consideration
17:23:11 <adamw> lruzicka: it's that thing i just quoted.
17:23:29 <bcotton> proposed #agreed This bug remains a blocker, but we will ask the Workstation WG to revisit their size limit to see if it still makes sense
17:23:29 <adamw> this was proposed (and immediately accepted) as a blocker yesterday, by me.
17:23:47 <adamw> patch
17:23:56 <bcotton> adamw: waiting
17:24:05 * nirik is unhappy blocking on it, but will bow to everyone else
17:24:35 <lruzicka> another unhappy person will be frantisekz :)
17:24:48 <adamw> proposed #agreed 1751438 - this is a blocker per the criteria, but we have the option of changing the target size (in consultation with workstation WG) or invoking the last-minute blocker policy. we will revisit these choices later in the meeting
17:25:08 <adamw> let's get through matrix coverage and so on too
17:25:10 <nirik> ack
17:25:12 <mboddu> ack
17:25:13 <lruzicka> ack
17:25:14 <lbrabec> ack
17:25:16 <bcotton> ack
17:25:19 <adamw> and it gives time for workstation wg to show up
17:25:23 <coremodule> ack
17:25:37 <pwhalen> ack
17:25:42 <bcotton> #agreed 1751438 - this is a blocker per the criteria, but we have the option of changing the target size (in consultation with workstation WG) or invoking the last-minute blocker policy. we will revisit these choices later in the meeting
17:25:56 <bcotton> now this forces us to look at the proposed blockers, you sneaky man
17:26:06 <adamw> you're welcome
17:26:12 <bcotton> #topic (1750575) dnfdragora complains that dnf is locked by another process after updates
17:26:14 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1750575
17:26:15 <lruzicka> let's sneak into it
17:26:15 <bcotton> #info Proposed Blocker, dnfdaemon, NEW
17:26:27 <bcotton> -1 blocker. it's functional, just with a dumb error message. i can live with that in a beta
17:26:46 <adamw> yeah, on current description -1 for me
17:26:48 <pwhalen> -1 blocker, +1 beta FE, +1 final blocker
17:26:57 <adamw> assuming there are no later consequences of the error?
17:27:01 <pwhalen> it does affect most of the desktops
17:27:13 <nirik> -1blocker, +1FE
17:27:14 <pwhalen> adamw, none I saw, packages can be installed and removed
17:27:15 <mboddu> +1 FE
17:27:18 <lruzicka> does the problem go away after some time, pwhalen ?
17:27:21 * satellit_ it does unlock eventually for me
17:27:22 <adamw> cool
17:27:25 <coremodule> -1 blocker, +1FE
17:27:30 <lruzicka> when dnf frees the lock?
17:27:50 <pwhalen> lruzicka, not that I've seen
17:28:05 <pwhalen> affects all arches as well so will need to be documented
17:28:51 <bcotton> proposed #agreed 1750575 RejectedBlocker (Beta) AcceptedFreeException (Beta) - Updates are installed so it is functional, but the error message needs to be fixed
17:28:55 <adamw> throw a CommonBugs at it then
17:28:57 <lruzicka> pwhalen, and the updates are applied via dnfdragora or dnf itself?
17:29:28 <lruzicka> ack
17:29:29 <mboddu> ack
17:29:34 <pwhalen> lruzicka, dnfdragoria
17:29:37 <pwhalen> ack
17:29:38 <nirik> ack
17:29:40 <lbrabec> ack
17:29:47 <adamw> ack
17:29:50 <adamw> er
17:29:51 <adamw> patch
17:29:54 <adamw> AcceptedFreezeException
17:29:57 <adamw> not FreeException :P
17:29:59 * lruzicka thinks it might be a race condition
17:30:03 <bcotton> ah yes
17:30:14 <bcotton> #info there's no such thing as a free exception
17:30:27 <lruzicka> bcotton, free as in beer?
17:30:29 <mhroncok> join us and free the exceptions
17:30:40 <bcotton> #agreed 1750575 - RejectedBlocker (Beta) AcceptedFreezeException (Beta) - Updates are installed so it is functional, but the error message needs to be fixed
17:31:14 <bcotton> and lastly....
17:31:17 <bcotton> #topic (1747408) Cannot upgrade to Fedora 31: package exa-0.9.0-2.module_f31+5365+04413d87.x86_64 requires libgit2.so.28()(64bit), but none of the providers can be installed
17:31:19 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1747408
17:31:20 <bcotton> #info Proposed Blocker, libgit2, NEW
17:31:51 <adamw> so, this is the libgit2 default module stream issue
17:32:17 * mhroncok is seriously afraid that if this isn't a blocker, nobody will fix this
17:32:27 <satellit_> soas live foes
17:32:39 * satellit_ sorry
17:32:48 <nirik> I thought it was fixed for upgrades
17:32:49 <frantisekz> .hello2
17:32:50 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
17:32:54 <adamw> it's not, obviously
17:33:05 <adamw> but the rule here is: we only block on upgrades of the default release-blocking package sets
17:33:07 <nirik> nope
17:33:10 <nirik> it might be.
17:33:16 <nirik> distro-sync != system-upgrade
17:33:29 <adamw> well...system-upgrade does distro-sync, i think
17:33:36 <adamw> but yeah, that's a point worth considering
17:33:46 <mhroncok> + extra magic to workaround broken modularity design
17:34:04 <mhroncok> (so it might as well does extra magic to workaround this)
17:34:05 <nirik> I thought they fixed it in system--upgrade, but not anything else, but I could be mistaken
17:34:20 <adamw> we can ask in the bug
17:34:37 <adamw> but regardless...by the criteria, i think this is -1, because i don't see any indication this affects any package in the default blocking sets
17:34:39 <siddharthvipul> tflink: sorry I was away, I saw your ping re: centos CI openshift version upgrade.. right now we can't provide you a date. Soon we will have a ticket where we can update our progress. Once we have that handy, I will be sure to pass on the link :)
17:34:41 <lruzicka> I think that we are going to hit more such bugs when people start installing more modules
17:34:41 <adamw> and the openQA upgrade tests are passing
17:34:45 <siddharthvipul> cverna: thank you for the ping
17:34:59 <adamw> lruzicka: it seems likely!
17:35:08 <lruzicka> siddharthvipul, wrong channel?
17:35:18 <tflink> lruzicka: left over from a previous meeting
17:35:21 <nirik> lruzicka: well, except people aren't supposed to have default modules do this moving forward (for now at least)
17:35:35 <siddharthvipul> lruzicka: sorry to speak out in between, was away during the last meeting
17:35:35 <tflink> siddharthvipul: we should take that to another channel, not during another meeting
17:35:57 <bcotton> "things will probably be bad in the future" is not a release criterion
17:36:04 <lruzicka> the problem is that if modules have default streams and get installed before non.modular content, there must be a clear policy on howto upgrade those streams
17:36:15 <mhroncok> "lot's of confused users who are unable to upgrade" is not a criterion ether
17:36:17 <bcotton> but i agree with mhroncok that we do need to apply some kind of pressure on this (maybe the Prioritized Bugs process?)
17:36:46 <mhroncok> consider that now we get confused contributors unbale to upgrade to pre-beta
17:36:59 <adamw> yeah, i'm worried about this issue in general
17:37:02 <mhroncok> this will be a "shit in the fan" situation if we release with this
17:37:04 <adamw> but not sure blocking beta for it is the answer exactly
17:37:16 <adamw> mhroncok: did you test what actually happens with system-upgrade yet?
17:37:19 * mhroncok proposed it for final blocker actually
17:37:25 <nirik> yeah, I don't think so... final perhaps
17:37:27 <mhroncok> adamw: downloading some F30 to do it
17:37:30 <mhroncok> as we speak
17:37:37 <adamw> pwalter proposed for beta
17:37:40 <mboddu> This is a serious bug that I want to solve before Beta, but not a blocker as per criterion
17:37:42 <nirik> sorry I didn't note that in the bug before now. ;(
17:37:52 <mboddu> I want to see solved*
17:38:05 <lruzicka> I tried to upgrade with some modular content using system-upgrade ... that was fine, but I have not tested libgit2 or exa
17:39:05 <adamw> so, i'm -1 beta blocker, not sure about FE it would depend what the fix looks like.
17:39:24 <lruzicka> I will be -1 beta blocker, but +1 final blocker definitely
17:39:31 <nirik> yeah... -1 beta blocker, I think I am ok with a FE, we can always decide it's too invasive...
17:39:46 <mhroncok> blocker doesn't change the fact that there will be nobody fixing this
17:39:55 <mhroncok> soory
17:40:00 <mhroncok> a FE doesn't change...
17:40:13 <bcotton> the other question is "is this something we could fix in a week"? i kinda feel like the Rules™ compel us to be -1 on blocker, but i'd be more inclined to throw away the rule book if it were readily fixable
17:40:33 <lruzicka> mhroncok, but how do you want to make sure someone is going to fix it, when they say that it is a matter of "design" ?
17:40:39 <nirik> well, it might be whatever they did in system-update to fix it could also be used in distro-sync... but I am just speculating.
17:40:49 <mhroncok> lruzicka: you block on it
17:41:15 <lruzicka> mhroncok, "blocker doesn't change the fact that there will be nobody fixing this" .... maybe I did not get it?
17:41:35 <mhroncok> lruzicka: I've made  a mistake, corrected after. "a FE doesnẗ..."
17:41:50 <lruzicka> mhroncok, oh... now I see, sorry.
17:41:58 <mhroncok> np, my mistake
17:42:26 <bcotton> so i count +1, -4 for beta blocker
17:43:13 <lruzicka> So ... I believe we should stop considering modularity a "technology preview" and we should start requiring quality
17:43:20 <mboddu> If the fix is as simple as nirik say's, then based on the other reasons why I would like to see a delay in the release, I can +1B this bug.
17:43:43 <nirik> I have no idea, I was just hoping. ;) Thats probibly the best case
17:43:46 <mhroncok> lruzicka: too late for that sadly
17:43:57 <mboddu> nirik: Sure :)
17:44:00 <adamw> lruzicka: i mean, we are holding it to the same release criteria as everything else
17:44:13 <adamw> the reason this isn't a blocker has nothing to do with modularity, it's simply because it happens not to affect any packages in the default set
17:44:29 <adamw> if something in a default blocking install happened to depend on libgit2...this *would* be a blocker
17:44:35 * Pharaoh_Atem waves
17:44:51 <lruzicka> adamw, I am not sure about it ... we cannot block on malformed modules (we do not block on packages), we cannot block on upgrade processes because with clean system, you can upgrade
17:44:51 <mboddu> nirik: But we can get a response from dnf by then, and if they say it takes a gazillion days to fix it, then we will not block on it
17:45:10 <mhroncok> gnome-builder is not default?
17:45:22 <Pharaoh_Atem> mboddu: what about dnf right now?
17:45:26 <lruzicka> adamw, until now, modularity was just a part of the system, but I believe it must have its own criteria
17:45:35 <adamw> mhroncok: nope. see https://openqa.fedoraproject.org/tests/449358/file/upgrade_run-dnf.log
17:45:36 <mboddu> Pharaoh_Atem: https://bugzilla.redhat.com/show_bug.cgi?id=1747408
17:45:44 <mhroncok> kate is not default?
17:45:47 <adamw> that's the log of a workstation f30 -> f31 upgrade test. you can see all packages it upgrades there, and that it doesn't remove any
17:45:58 <adamw> hmm, let me see the kde upgrade test log
17:46:08 <Pharaoh_Atem> wtf
17:46:08 <nirik> why would it remove anything?
17:46:15 <Pharaoh_Atem> why are the libgit modules still a thing?
17:46:18 <adamw> https://openqa.fedoraproject.org/tests/449362/file/upgrade_run-dnf.log <-- no mention of kate
17:46:19 <Pharaoh_Atem> I thought ignatenkobrain removed them?
17:46:47 <adamw> nirik: the test re-tries with --allowerasing if it fails without it (though in fact it doesn't need to do that in either case at present)
17:47:07 <adamw> and for the record, GNOME upgrades do the equivalent of --allowerasing *by default and without notification* (which I'm quite unhappy with)
17:47:26 <adamw> that is, graphical upgrades with gnome-software.
17:47:30 <lruzicka> Pharaoh_Atem, what I have seen in some previous composes it was there and it had a default stream which means that anything that pulls libgit2 pull modular libgit first
17:48:04 <Pharaoh_Atem> lruzicka: ignatenkobrain demodularized the libgit2 package, I'm pretty sure he has asked for all the libgit2 modules to be removed from the distribution
17:48:18 <ignatenkobrain> You should call dnf module reset libgit2
17:48:34 <adamw> okay, we don't need to litigate this whole bug here
17:48:37 <adamw> only decide whether it's a blocker
17:48:43 <lruzicka> I wonder, mboddu, how does it take to remove or change the module defaults, when there is a change in fedora-module-defaults?
17:48:50 <nirik> ignatenkobrain: yeah, that would work around it too... but people would have to know to do it.
17:48:55 <lruzicka> how long does it take
17:49:01 <adamw> mhroncok: looking at comps, kate is in the kde-software-development group, but that's not in the kde environment group.
17:49:05 <bcotton> mboddu: are you still +1 blocker or was that conditional on nirik's hope being reality
17:49:35 <lruzicka> If we do -1B now, we definitely need to document it. I can do it, if needs be.
17:49:39 <nirik> In any kind of cool nice timeline, you would expect distro-sync to also sync default streams...
17:50:08 <lruzicka> nirik, but the design is, when you are on a particular stream, it is not changed into a new one.
17:50:30 <adamw> lruzicka: i'd like to know if it affects system-upgrade, though. if it doesn't, it's much less of a problem.
17:50:32 <lruzicka> nirik, so if the default stream changes you run into some weird behaviour
17:50:34 <nirik> yes, but when you upgrade major versions it needs to let you
17:50:45 <mboddu> bcotton: Conditional blocker
17:50:48 <nirik> otherwise defaults could never change
17:50:48 <adamw> again, we're not deciding how modules work here
17:50:56 <lruzicka> adamw, with some modules it does not, but I have not tested libgit
17:51:00 <ignatenkobrain> Let's put it in release notes
17:51:01 <bcotton> mboddu: i'll call that +0.5 then :-)
17:51:07 <lruzicka> adamw, I guess I could try tomorrow
17:51:15 <adamw> mhroncok said he was trying now.
17:51:15 <nirik> for beta it could be a common bug...
17:51:23 <mboddu> bcotton: Okay :)
17:51:30 <lruzicka> adamw, so lets wait until mhroncok tells us
17:51:51 <mhroncok> I cannot try, becasue installing exa on F30 now gives the proper noncrippled libgit package
17:51:57 <bcotton> okay, so i have +1.5 (mhroncok, mboddu), -4 (bcotton adamw nirik lruzicka). does anyone else want to express an opinion?
17:52:04 <adamw> that's only for commonbugs purposes, for me. i'm -1 either way. this is clearly not a blocker per the criteria.
17:52:08 <frantisekz> -1 B
17:52:19 <mhroncok> BTW I don't think we should block beta on this
17:52:21 <lruzicka> frantisekz, I thought so
17:52:25 <bcotton> oh
17:52:28 <bcotton> well heck
17:52:28 <mhroncok> I've propsoed it as final blocker
17:52:43 <lruzicka> so, yeah I agree ... final blocker definitely
17:52:47 <bcotton> okay, so we're near unanimous for beta blocker then
17:52:48 <lruzicka> for beta, common bugs
17:53:08 <mhroncok> ignatenkobrain: any way how to get my systsem to that beoken state so i can test system-upgrade?
17:53:16 <nirik> well, or a fix would be great... but...
17:53:35 <lruzicka> mhroncok, enable modular libgit before you install exa?
17:53:47 <bcotton> proposed #agreed 1747408 - RejectedBlocker (Beta) - No packages in the default sets require libgit, so this is not a blocker
17:54:02 <mboddu> lruzicka: To answer your question on change default streams, yes, a change in fedora-module-defaults and the rules around that are listed in https://docs.fedoraproject.org/en-US/modularity/making-modules/managing-defaults/
17:54:04 <frantisekz> ack
17:54:05 <bcotton> (i'm intentionally ignoring final for now, we can leave that to the next blocker review meeting)
17:54:09 <lbrabec> so no final blocker?
17:54:11 <adamw> (i guess one thing we don't test is xfce. hrm. should probably test that.)
17:54:17 <adamw> we don't need to review final blocker status here.
17:54:22 <adamw> ack
17:54:29 <lruzicka> mboddu, thanks ... but how long does it take to see the change in the compose?
17:54:47 <mboddu> lruzicka: Next run of the compose after the PR gets merged
17:55:02 <lruzicka> mboddu, ok ... thanks.
17:55:02 <nirik> ack
17:55:05 <mboddu> ack
17:55:09 <lruzicka> ack
17:55:17 <bcotton> #agreed 1747408 - RejectedBlocker (Beta) - No packages in the default sets require libgit, so this is not a blocker
17:56:19 <bcotton> okay, do we want to revisit the workstation bug now that frantisekz is here?
17:56:36 <frantisekz> (me wondering which bug you mean.... :) )
17:56:50 <bcotton> you're about to fine out!
17:56:52 <bcotton> find, too
17:56:56 <frantisekz> :O
17:57:01 <cmurf> we're talking about the size bit in #fedora-workstation
17:57:04 <cmurf> what are the options?
17:57:06 <bcotton> #topic (1751438 revisited) Workstation x86_64 live image is over size target
17:57:21 <cmurf> we don't know off hand why it's bigger, is there a way to figure this out easily?
17:57:26 <adamw> why are there two channels sigh
17:57:39 <bcotton> so our options are to adjust the target size, to keep it as a blocker, or to invoke the late blocker policy and ignore it
17:57:40 <cmurf> there's only one that i know of
17:57:58 <adamw> cmurf: not *that* easily, since the images have been garbage collected. you can look at the compose changelog for the compose they started being too big
17:58:18 <frantisekz> honestly, for Beta, I'd rather not block on this, especially since we found out so late
17:58:24 <adamw> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/65Q4CM4EX5MXYYDD36TBCHGJACGA5BDT/
17:58:28 <adamw> uh
17:58:32 <adamw> can we not revisit this yet?
17:58:35 <Pharaoh_Atem> frantisekz: if we didn't have the blocker notice, I don't think we'd have found out until final
17:58:45 <adamw> we still didn't do matrix completion
17:58:51 <cmurf> my gut instinct is this shouldn't be a beta blocker, I can see why we wouldn't want it to be bigger than 4GiB sticks
17:59:07 <cmurf> that'd limit testing - but I don't see how being unable to image 2GiB sticks is limiting...
17:59:23 <Pharaoh_Atem> I'm still of the mindset that given how little we're over, we should try to keep below the 2GB limit
17:59:39 <cmurf> Pharaoh_Atem:the problem is it means blocking beta and slipping
17:59:40 <Pharaoh_Atem> it's useful especially for having persistence on 4GB usb sticks
17:59:45 <lruzicka> I do not like this bending the criteria ... I think if somebody wanted that size, they knew why
17:59:46 * nirik waits for matrix with adamw
18:00:01 <bcotton> adamw: are you expecting anything to change in the interim?
18:00:15 <Pharaoh_Atem> I'm pretty sure the reason we keep the 2GB limit is to support running the live environment on a USB stick with persistence
18:00:17 <frantisekz> for Beta, it's not that big deal, having it oversized imo
18:00:32 <bcotton> adamw: i brought us back since we have Workstation represented now, but i'm happy to unrevist if there's a reason
18:00:34 <frantisekz> for Final, we can discuss that, but slipping for a week just because of this...
18:00:38 <adamw> lruzicka: honestly, the sizes only get set when we poke people about them.
18:01:12 <lruzicka> adamw, it seems so ... which means we must start poking them sooner next time
18:01:14 <adamw> i wish i had the notes handy but my best recollection is when workstation got bigger than a CD we just said 'meh' and bumped it to 1GB then when it got bigger than 1GB we said 'meh' and bumped it to 2GB
18:01:39 <Pharaoh_Atem> adamw: we also used to ship LibreOffice on the CD/DVD
18:01:41 <pwhalen> so.. meh?
18:01:45 <lruzicka> adamw, we can do it, but we need to bump first and then dismiss the criteria
18:01:57 <Pharaoh_Atem> I think when we switched to 1GB, we also dropped LibreOffice
18:02:04 <cmurf> Pharaoh_Atem: with persistence I think livecd-tools uses ext4 by default? oh no for UEFI it has to be FAT...
18:02:06 <cmurf> shit
18:02:12 <Pharaoh_Atem> cmurf: yep
18:02:12 <cmurf> and FAT has a 2GiB file size limit doesn't it?
18:02:15 <Pharaoh_Atem> bingo
18:02:22 <cmurf> ok so here's the thing
18:02:22 <nirik> I think few people bother with persistence these days...
18:02:34 <Southern_Gentlem> nirik,  you would be surprised
18:02:39 <Pharaoh_Atem> nirik: I get enough patches and bug reports that I don't think that's true
18:02:52 <Pharaoh_Atem> hell, the bulk of the PRs for livecd-tools are related to that functionality
18:02:53 <cmurf> the ext4 file system baked into the squashfs image? that's what sets the size, regardless of the size of the persistence backing file
18:03:05 <cmurf> such as it's designed now - which i'm trying to get us away from with the overlayfs work
18:03:14 <nirik> but we don't use livecd-tools. ;)
18:03:20 <cmurf> and there's maybe 500MiB of float right now
18:03:24 <Pharaoh_Atem> nirik: livecd-iso-to-disk is part of livecd-tools
18:03:30 <Pharaoh_Atem> and it's compatible with lmc-produced media
18:03:34 <Southern_Gentlem> i still have an older gent that sends me a usb for the newest fedora release on a usb with persistance
18:03:36 <cmurf> s/float/free space
18:03:37 <frantisekz> cmurf: yep, I've seen some of your tickets and work, thanks for that
18:03:38 <nirik> right... but we don't point people at that much...
18:03:48 <nirik> anyhow
18:03:49 <adamw> so the image is like 47MiB over size right?
18:03:54 <Pharaoh_Atem> adamw: yep
18:04:40 <adamw> hmm ok
18:04:48 <cmurf> i wish there were a way to have different size limits for beta and final -
18:04:50 <adamw> i'm looking for stuff that got a lot bigger in 0625.n.0 but didn't really find anything yet./
18:04:55 <Pharaoh_Atem> cmurf: there'd be no point for that
18:05:15 <Pharaoh_Atem> the blocker criteria is there for us to be able to figure out what to do
18:05:21 <Pharaoh_Atem> not necessarily to say we mandate the slippage
18:06:11 <Pharaoh_Atem> adamw: if I had to guess, I think the 4% rise is because of the payload change
18:06:21 <Pharaoh_Atem> I don't see a significant package set change anywhere
18:06:25 <adamw> bcm283x-firmware got 11MiB bigger
18:06:27 <Pharaoh_Atem> so I think we rose because we compress less
18:06:35 <adamw> Pharaoh_Atem: ah. when did that happen?
18:06:45 <Pharaoh_Atem> we switched from xz to zstd for F31 ;)
18:06:48 <adamw> yes
18:06:51 <adamw> but i mean specifically what date
18:06:55 <cmurf> lives don't have RPMs on them
18:06:57 <nirik> but thats just the rpms... we unpack them when making the image?
18:07:02 <nirik> right
18:07:03 <cmurf> so zstd compression for rpms doesn't matter
18:07:10 <Pharaoh_Atem> welp, there goes my theory :P
18:07:14 <adamw> sigh
18:07:17 <nirik> it was a good one. ;)
18:07:17 <cmurf> and the squashfs image is still xz
18:07:30 <Pharaoh_Atem> adamw: but it was completed just before Flock
18:07:36 <Pharaoh_Atem> just to answer your question
18:07:45 <Pharaoh_Atem> the mass rebuild converted everything to zstd
18:08:13 <nirik> we don't have a debug kernel do we? hum, no I guess not.
18:08:27 <cmurf> RPM xz to zstd could affect server DVD because it has RPMs as its payload
18:08:33 <Pharaoh_Atem> that does occasionally accidentally slip in there, but it didn't this time, I think
18:08:52 <cmurf> someone check the initramfs...quick
18:08:54 <frantisekz> no, it's not debug kernel in F31
18:09:07 <nirik> anyhow, I would prefer changing the size bigger so it's not a blocker... but I guess thats up to WS...
18:09:14 <bcotton> okay, so in the interests of time, let's decide if we care about the overage. +1 if we continue to treat this as a blocker, -1 if we invoke the late blocker policy and move on
18:09:18 <adamw> ah
18:09:18 <adamw> Date:   Mon Jun 24 20:34:44 2019 +0000
18:09:18 <adamw> Merge #527 `Workstation: include podman`
18:09:22 <Pharaoh_Atem> welp there we go
18:09:27 <adamw> i'm gonna say that looks like a gun wot is smoking
18:09:41 <Pharaoh_Atem> I was actually about to ask about go-based software too ;)
18:09:42 <bcotton> changing the limit is something that workstation should do with more deliberation
18:09:55 <bcotton> -1, fwiw
18:09:59 <frantisekz> -1
18:09:59 <Pharaoh_Atem> becuase we upgraded the go compiler and that increased the size of some binaries :/
18:10:02 <nirik> ok, fair. so, -1 (invoke late blocker)
18:10:15 <pwhalen> -1
18:10:16 <lruzicka> +1 blocker, get criteria sorted first
18:10:28 <adamw> there's nothing wrong with the criteria, fight me :P
18:10:30 <adamw> +/-0
18:10:39 <Pharaoh_Atem> I agree with adamw
18:10:41 <lbrabec> -1
18:10:41 <adamw> i don't really mind waiving this as a late blocker, but i also secretly want to slip, so. :P
18:10:44 <lruzicka> now it says that it is blocking
18:10:58 <adamw> and there's nothing wrong with that!
18:11:00 <adamw> glad we agree ;)
18:11:00 <lruzicka> if we do not want it to be blocking, we must change size first
18:11:18 <adamw> the late blocker policy covers exactly this situation, though.
18:11:21 <lruzicka> therefore I am +1, because this not a bug that jumped at us from nowhere
18:11:22 <frantisekz> yep
18:11:24 <adamw> we only found it super late, and it's not a super critical bug.
18:11:37 <adamw> lruzicka: it jumped at the release process from nowhere.
18:11:39 * mboddu agrees with adamw with the slip :P
18:11:46 <bcotton> okay, so i count +1, 0x2, -5
18:11:51 <adamw> that's *specifically* why the policy says "proposed as a blocker", not "discovered" or "reported" or anything like that.
18:11:59 <lruzicka> adamw, yes, but was it not a bit our fault?
18:12:01 <cmurf> i'm -1 also, fwiw
18:12:04 <adamw> sure it was. does that matter?
18:12:07 <adamw> the policy isn't about fault
18:12:16 <adamw> it's about achieving a good release process
18:12:25 <adamw> everything is *someone's* fault, that's rarely the important point :P
18:13:01 <lruzicka> so, if I know about a bug and I do not propose it until the gonogo meeting, we will release. Thats dangerous.
18:13:13 <bcotton> proposed #agreed 1751438 - We will invoke the late blocker policy and not block the beta release for this. Workstation WG will revisit the size limit to see if it is still appropriate
18:13:14 <mboddu> I am -1 Blocker, but I also secretly want to slip :D
18:13:15 <Pharaoh_Atem> lruzicka: we've always relied a bit on the honor system here
18:13:21 <nirik> well, no, we will discuss and vote on it. ;)
18:13:37 <bcotton> lruzicka: we're not obligated to ignore late blockers, but we have the ability to use our best judgment
18:13:43 <adamw> lruzicka: no, the policy is not that simple.
18:14:18 <mboddu> ack to the proposal
18:14:28 <cmurf> secretly want to slip
18:14:30 <cmurf> why?
18:14:35 <lruzicka> ack, because you have outvoted me
18:14:36 <frantisekz> bcotton: ack
18:14:41 <adamw> and yes, in general fedora processes expect people to act in good faith, there are lots of things in our processes that can easily be subverted by someone who wants to be malicious. i mean, if you want to hide a bug, you can just *not propose it at all*, right?
18:14:48 <cmurf> plus it's not a secret anymore, might as well say why
18:14:49 <adamw> cmurf: to fix the juicy FEs
18:14:55 <adamw> we went over this earlier
18:14:55 <lruzicka> and I cherish democracy and the power of free vote
18:14:57 <cmurf> haha
18:15:19 <adamw> lruzicka: i believe in the "one man, one vote" system. so long as i'm the man.
18:15:31 <bcotton> #agreed 1751438 - We will invoke the late blocker policy and not block the beta release for this. Workstation WG will revisit the size limit to see if it is still appropriate
18:15:31 <Pharaoh_Atem> well, you've always been the man to me ;)
18:15:39 <bcotton> okay, so that's it for our blockers
18:15:59 * nirik has a thing to bring up if we have time/energy
18:16:06 <bcotton> #topic Current status ­release candidate compose is available
18:16:07 <lruzicka> fire away, nirik
18:16:13 <mboddu> nirik: May be after test matrices
18:16:35 <bcotton> mboddu: we have compose, yes?
18:16:38 <nirik> sure.
18:16:38 <adamw> yes, there is a release candidate
18:16:44 <adamw> just the one, but it's all candidate...y
18:16:52 <bcotton> #info RC is available
18:16:53 <mboddu> Haha :D
18:17:00 <cmurf> USS Ship It
18:17:01 <bcotton> anything else, or should we let adamw get to his matrices finally
18:17:14 <bcotton> nirik: ack on your thing, btw
18:17:20 <nirik> basically: I tried to install rc1 on our ancient RHOSP5 and... it doesn't finish booting. It gets to userspace, but fails to get to a login/etc.
18:17:38 <nirik> so, we might want to check more modern clouds and make sure they work... or aws or the like
18:17:49 <adamw> that's gonna come up in matrix coverage in fact
18:17:55 <bcotton> great, let's do that then
18:18:00 <frantisekz> nirik: testcloud, the newest cloud of all, works just fine... :)
18:18:08 <bcotton> #topic Current status — test matrices
18:18:13 <bcotton> #link https://fedoraproject.org/wiki/Category:Fedora_31_Test_Results
18:18:17 <bcotton> adamw: the floor is yours
18:18:32 <adamw> muahahahahahahahaha
18:18:33 <adamw> *ahem*
18:18:45 * Pharaoh_Atem is ready with a sword if adamw becomes evil
18:18:49 <bcotton> becomes?
18:18:50 <adamw> so, matrix coverage is mostly good, but there are two notable exceptions:
18:18:52 <nirik> frantisekz: great!
18:18:52 <adamw> oy
18:18:56 <adamw> .fire bcotton for cheek
18:18:56 <zodbot> adamw fires bcotton for cheek
18:19:06 <adamw> #info matrix coverage is mostly good with two exceptions:
18:19:25 <bcotton> #chair adamw
18:19:25 <zodbot> Current chairs: adamw bcotton
18:19:32 <adamw> #info matrix coverage is mostly good with two exceptions:
18:19:37 <bcotton> i'm pretty sure you can #info without chair, but just in case
18:19:41 <adamw> #info two of three Active Directory tests for Server have not been done
18:20:00 <adamw> #info Cloud tests have not been run in any actual cloud (only with local testcloud)
18:20:31 <coremodule> adamw, I can run those cloud tests right now...
18:20:35 <coremodule> on a real cloud...
18:20:46 <nirik> coremodule++
18:20:47 <zodbot> nirik: Karma for coremodule changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:21:07 <adamw> #info also worth noting RC has only been around for ~22 hours
18:21:08 <mboddu> coremodule++
18:21:08 <zodbot> mboddu: Karma for coremodule changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:21:11 <nirik> [[0;32m  OK  [0m] Started [0;1;39mLogin Service[0m.
18:21:12 <nirik> [[0;1;31mFAILED[0m] Failed to start [0;1;39mLoad/Save Random Seed[0m.
18:21:12 <nirik> See 'systemctl status systemd-random-seed.service' for details.
18:21:12 <nirik> Starting [0;1;39mCleanup of Temporary Directories[0m...
18:21:12 <nirik> [[0;32m  OK  [0m] Started [0;1;39mCleanup of Temporary Directories[0m.
18:21:13 <lruzicka> seems coremodule is the cloud guy from now on
18:21:14 <adamw> coremodule: please do!
18:21:16 <nirik> oops. sorry...
18:21:21 <coremodule> running... standby
18:21:24 <adamw> volunteering, a rookie mistake
18:21:28 <coremodule> well, carry on, but standby for me
18:22:06 <coremodule> Pvt. /me runs tests
18:22:09 <mboddu> " #info also worth noting RC has only been around for ~22 hours" is one of the reason for me secretly wishing for a slip :D
18:22:27 <adamw> so, alciregi ran one AD join test at least
18:22:52 <frantisekz> mboddu: careful what you wish for...
18:22:58 <bcotton> i seem to recall a very smart and handsome FPgM suggesting we should have a minimium time between RC and Go/No-go and being told "nahhhhh, it's fiiiiiine"
18:23:01 <adamw> we could, reasonably, hold that the combination of that test and the other two tests passing for FreeIPA gives us fairly high certainty that the same two tests would pass for AD
18:23:13 <adamw> bcotton: doesn't ring a bell!
18:23:36 <adamw> (in fact i think we might have a rule like that somewhere but just be cheerfully ignoring it)
18:24:02 <pwhalen> bcotton, we once said if there was no RC by Tuesday, auto-slip.
18:24:16 <mboddu> frantisekz: I know what I am getting into, as I have to run the compose :D (but adamw has to test it again)
18:24:20 <lruzicka> bcotton, I would support the minimum-time-in-between thingie
18:24:26 <adamw> pwhalen: yeah, that's what i remember, but i don't remember where it is.
18:24:46 <mhroncok> (BTW I've finally beaten the F30 system to get to the broken state with libgit and distrosync, system-upgrade does the same)
18:24:50 <pwhalen> nor I, I think tribal knowledge
18:25:08 <bcotton> while there may be no such thing as a free exception, there is such thing as a FreeIPA. i wouldn't object if you made the argument that it's good enough, adamw
18:25:33 <lruzicka> bcotton, free beer again :D
18:25:36 <mboddu> adamw: Yeah, I remember there was a rule about RelEng should get a request by EOD of Tue before go/no-go which gives couple of days of testing for QA
18:25:38 * nirik needs to wander to another meeting in 5m... but can try and keep paying attention here
18:25:44 <adamw> mhroncok: how much 'beating up' is necessary?
18:26:08 <mhroncok> I'll document my steps
18:26:44 <bcotton> while we wait for the weather report from coremodule, are there any other questions or comments about test coverage?
18:26:47 <mhroncok> adamw: but basically I needed to dnf module enable libgit2:0.27, dnf install libgit2, dnf install exa bat
18:26:59 <coremodule> the weather man is always wrong...
18:27:04 <adamw> mhroncok: okay. but some existing systems will have got into this position by just installing exa or bat or whatever?
18:27:26 <mhroncok> adamw: yes, this has been "fixed" for people who dnf install exa or bat now
18:27:39 <mhroncok> it's the users who did that before
18:27:50 <adamw> okay.
18:28:51 <lruzicka> mhroncok, how do you install modular libgit2 ... it cannot be installed since it does not have any profile ?
18:29:25 <mhroncok> lruzicka: dnf module enable libgit2:0.27 && dnf install libgit2
18:29:30 <mboddu> lruzicka: He is enabling a stream "dnf module enable libgit2:0.27"
18:29:31 <lruzicka> mhroncok, I was told that that module is for dependency purposes only - the content cant be installed per se, but gets pulled by other modules.
18:29:50 <mkolman> yeah, yo don't really need a profile in many cases to use RPMs provided by a module
18:29:52 <adamw> yes. but in order to reproduce the problem some existing installs have, you have to do that.
18:30:25 <lruzicka> mboddu, enable ... you can do it, but it will not install anything ... which also is a weird behaviour I do not like about modules.
18:31:09 <coremodule> so far 4/5 tests have passed on ec2, running the last service test now...
18:31:32 <adamw> 🎉
18:32:08 <nirik> libgit2:0.27 should be default in f30.
18:32:18 <lruzicka> ok ...
18:32:23 * Pharaoh_Atem has to go now
18:32:27 <mboddu> lruzicka: Right, but thats another fight
18:32:32 <Pharaoh_Atem> hopefully I shouldn't be needed anymore in here
18:32:39 * Pharaoh_Atem puts away his sword and walks out
18:33:04 <mkolman> lruzicka: it can get even better - you can have module:stream enabled, having nothing installed from it & still have it block your upgrades :)
18:33:12 <mkolman> lruzicka: have seen that case today
18:33:41 <mboddu> mkolman: Okay, that is new to me, never seen that before but I can see why its doing that
18:34:15 <lruzicka> mkolman, I believe you
18:34:36 <lruzicka> nirik, check this and show me what profile does libgit install when they are empty? https://dpaste.de/9svh/raw
18:35:01 <lruzicka> nirik, that from my F30 ?)
18:35:06 <nirik> if you don't do anything you get 0.27 as it's default...
18:35:08 <mkolman> IIRC it was the jmc module depending on the eclipse module, that has not yet been rebuilt for F31 correctly - as far as we could tell nothing was installed from the jmc module
18:35:35 <lruzicka> nirik, but doing "dnf module install libgit2:0.27" will not install it, just enable
18:36:34 <mhroncok> anyway, since all the rust modules will be retired from f31, this will bite in a completelly different way
18:37:08 <nirik> ah, I see what you're saying. Yeah... but 'dnf install libgit2' will install it.
18:37:13 * mhroncok wonders whether we can even obsolete modular packages / modules from fedora-obsolete-packages
18:37:16 <bcotton> coremodule: almost there?
18:37:26 <coremodule> bcotton, 1 min or less
18:37:32 * bcotton waits anxiously
18:37:48 <coremodule> 45
18:37:49 <coremodule> 44
18:37:50 <coremodule> 43
18:37:51 <coremodule> 42
18:37:56 <mboddu> 0
18:38:00 <mboddu> :P
18:38:06 * bcotton waits for coremodule to get kicked for spamming
18:38:18 <coremodule> lol
18:38:24 <coremodule> then I guess YOULL NEVER KNOW!!!
18:38:34 <adamw> mhroncok: we need a module called fedora-obsolete-modules, obvs
18:38:43 <coremodule> yeah we're good
18:38:47 <adamw> okay
18:38:49 <coremodule> they all pass
18:38:55 <mhroncok> adamw: can one module obsolete others?
18:39:05 <adamw> mhroncok: i have absolutely no idea!
18:39:13 <bcotton> #info cloud tests pass on ec2
18:39:18 <mhroncok> we need to add special obsoleting packages into the default streams
18:39:19 <bcotton> anything else before we get to the decision?
18:39:29 <adamw> so if everyone's so keen to ship this hunk of junk, i think we can reasonably say that matrix coverage is sufficient inferring that the two missing AD tests should be fine based on the other AD test and the FreeIPA tests
18:39:41 <adamw> if anyone disagrees, please speak up
18:40:02 <nirik> what about the sas drives and fakeraid? </runs>
18:40:27 <frantisekz> ... </runs after nirik with some mace>
18:40:37 <cmurf> bear spray
18:41:02 <cmurf> has the sas drive test ever failed?
18:41:07 <cmurf> not really sure why it would
18:41:15 <adamw> nirik: i thought we had fakeraid?
18:41:25 <frantisekz> fw raid was done by me today
18:41:30 <adamw> yeah, we have fakeraid
18:41:31 <frantisekz> but I don't have hw for hw raid
18:41:31 <nirik> I was just joking about the ones we often don't have. ;)
18:41:38 <adamw> sas was run on 20190722.n.1, which is recent enough for me!
18:41:40 <bcotton> okay, so it sounds like nobody disagrees
18:41:45 <bcotton> #topic Go/No-Go decision
18:41:46 <bcotton> I will poll each team. Please reply “go” or “no-go”
18:41:50 <bcotton> FESCo?
18:42:02 <nirik> ship this ship. go.
18:42:08 <mhroncok> go
18:42:08 <bcotton> #info FESCo is go
18:42:12 <bcotton> Releng?
18:42:57 <bcotton> mboddu, nirik: the releng perspective, if you please
18:43:00 <mboddu> Go...
18:43:00 <nirik> go (or can wait for mboddu )
18:43:08 <bcotton> #info Releng is go
18:43:11 <bcotton> QA?
18:43:20 <adamw> grudgingly go :P
18:43:21 <frantisekz> go
18:43:25 <lruzicka> I pass
18:43:30 <coremodule> yo
18:43:38 <coremodule> i mean go
18:43:42 <bcotton> #info QA is go
18:43:44 <mhroncok> yolo
18:43:45 <adamw> #info QA is go based on lack of outstanding blockers and sufficient matrix coverage
18:44:05 <bcotton> mhroncok: brb, renaming this the Go/YOLO meeting
18:44:12 <bcotton> #agreed Fedora 31 Beta is GO
18:44:13 <bcotton> #info Fedora 31 Beta will release on 2019-09-17
18:44:35 <bcotton> well gee, look at us
18:44:36 <mboddu> bcotton: Dont we check infra as well?
18:44:55 <nirik> infra is ready whenever we have bits. :)
18:45:13 * mkolman recommends "this is fine meeting"
18:45:18 <bcotton> #action bcotton to announce decision
18:45:24 <bcotton> #topic Open floor
18:45:31 <nirik> beta: this is fine!
18:45:37 <bcotton> nirik: did you still have a thing, or was the thing you brought up earlier the thing?
18:45:56 <nirik> yeah, the cloud thing was it. I just wanted to make sure more reasonable clouds were tested
18:46:09 <bcotton> anyone else?
18:46:17 <nirik> as a side note I tested on a macbook and everything was fine.
18:46:48 <frantisekz> thanks for the meeting bcotton !!!
18:46:57 <adamw> nothing really
18:47:01 <bcotton> thanks everyone!
18:47:10 <mboddu> Not related, but anyone has testing Fedora on MS Surface pro 6?
18:47:17 <mboddu> Thanks bcotton
18:47:22 <bcotton> don't forget to tune in for the release readiness meeting in this room in 13 minutes
18:47:25 <lruzicka> mboddu, what is it, a tablet?
18:47:26 <bcotton> mboddu: if you buyme one, i'll test it
18:47:46 <nirik> bcotton: exciting action adventure thrill!
18:48:06 <bcotton> #endmeeting