15:00:22 <contyk> #startmeeting FESCO (2019-09-23)
15:00:22 <zodbot> Meeting started Mon Sep 23 15:00:22 2019 UTC.
15:00:22 <zodbot> This meeting is logged and archived in a public location.
15:00:22 <zodbot> The chair is contyk. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:22 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:22 <zodbot> The meeting name has been set to 'fesco_(2019-09-23)'
15:00:25 <contyk> #meetingname fesco
15:00:25 <zodbot> The meeting name has been set to 'fesco'
15:00:27 <contyk> #chair nirik, ignatenkobrain, jforbes, zbyszek, bookwar, sgallagh, contyk, mhroncok, otaylor
15:00:27 <zodbot> Current chairs: bookwar contyk ignatenkobrain jforbes mhroncok nirik otaylor sgallagh zbyszek
15:00:29 <contyk> #topic init process
15:00:30 <mhroncok> hey
15:00:31 <bcotton> .hello2
15:00:31 <contyk> .hello psabata
15:00:31 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
15:00:34 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:01:07 <nirik> .hello kevin
15:01:09 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
15:01:13 <sgallagh> .hello2
15:01:15 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:01:55 <jforbes> .hello2
15:01:56 <zodbot> jforbes: jforbes 'Justin M. Forbes' <jforbes@redhat.com>
15:02:07 <contyk> okay, we have a quorum
15:02:18 <bookwar> .hello2
15:02:19 <zodbot> bookwar: bookwar 'Aleksandra Fedorova' <alpha@bookwar.info>
15:02:54 <contyk> #topic #2149 Proposal to change non-responsive maintainer policy
15:02:57 <contyk> https://pagure.io/fesco/issue/2149
15:03:10 <sgallagh> Is there something left to do here?
15:03:12 <contyk> so this is an old one and I just wanted to bring it up again to see if there's anything else that needs to happen
15:03:16 <contyk> exactly my question
15:03:33 <mhroncok> zbyszek to send the announcment
15:04:15 <contyk> okay, so that's still on; I'll just ping him in the ticket then
15:04:49 <contyk> #topic #2003 Modules in buildroot enablement
15:04:51 <contyk> https://pagure.io/fesco/issue/2003
15:04:54 <contyk> another ancient thing
15:05:20 <contyk> here I wanted to inform you it's actively being worked on and I think a few minor pungi changes are what's left to test that in staging
15:05:34 <contyk> I saw nirik was asking a question about the repo on #fedora-releng on Friday
15:05:57 <nirik> yeah, I started a discussion also on koji-devel about integrating repo regens into koji...
15:06:07 <zbyszek> .hello2
15:06:08 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:06:49 <bookwar> contyk: i'd like to add dependency on https://pagure.io/modularity/issue/146 for this item
15:06:57 <nirik> I don't think this is too likely in the short term, so we will have to do some kind of cron or script. ;(
15:07:00 <contyk> if I remember correctly, the reasons for a separate repo was that we can access the non-modular pile separately (from MBS), so that users can point their mocks and other buildsystems to it, and the general tracking
15:08:03 <contyk> bookwar: I'm not super opposed to that idea but I don't want to block Ursa Prime on that decision
15:08:28 <nirik> and we likely need it faster than daily composes modular repo...
15:08:54 * mhroncok would still prefer if we stop modularizing stuff that nonmodular stuff requires
15:09:09 <bookwar> contyk: i disagree, because if we enable ursa prime we start channeling in non-api packages into non-modular buildroot
15:09:25 <contyk> bookwar: yes, I know
15:09:32 <bookwar> and reverting the damage done by this is going to be hard
15:09:35 <sgallagh> contyk: I think I’m with bookwar here, honestly.
15:10:49 <contyk> but you're asking for stricter rules than we even have nowadays
15:11:39 <jforbes> I don't know that stricter rules is a bad thing in this case
15:11:45 <mhroncok> I'm confused. what are we discussing now and why?
15:11:48 <sgallagh> contyk: Yes, but I think that’s correct. What we are allowing now is proving unacceptable
15:12:00 <bookwar> contyk: yes, i am asking for strict rules to start with, relaxing rules later would be easy, while tightening them back will be impossible
15:12:09 <sgallagh> mhroncok: see the link bookwar posted
15:12:36 <mhroncok> sgallagh: ah, thanks
15:12:46 <sgallagh> Essentially, require that any package in the default stream is treated identically (in terms of support) as if it was part of the non modular repo
15:13:02 <contyk> which is not actually what it is
15:13:12 <contyk> because non-modular repos are less strict than module api
15:13:15 <sgallagh> contyk: too many pronouns
15:13:45 <contyk> you can rebase and change non-modular packages as long as you deal with everything that depends on it in a single update
15:14:12 <contyk> it's up to the maintainer; if you do such things with packages listed as the api, you break the api
15:14:15 <mhroncok> well if I can install a package wihtout knowing anything about modules (I can) how would I know that this libffo tat just got installed is not supported for X?
15:14:15 <contyk> so you can't
15:14:58 <contyk> mhroncok: dnf module info, I believe
15:15:19 <bookwar> contyk: i don't say that modularity#146 should be adopted exactly in the form it is written now, i am open to discuss the alternatives, but i don't think we can move forward with Ursa Prime until we have the problem stated in #146 resolved one way or the other
15:15:27 <sgallagh> contyk: I don’t know if that’s actually supported anywhere but the —raw argument
15:16:27 <mhroncok> contyk: I don't do module info if I don't know modules
15:16:37 <contyk> I'm worried we won't be able to land the modular content we want as the default and/or in the buildroots if we mandate it
15:16:46 <contyk> and I'm not sure about the potential damage
15:17:03 <mhroncok> if we just abandon the idea of default modules ank keep the stuff that is supposed to be the default in nomnodular repo, everyhting would be less hostile towards the users
15:17:07 <contyk> but we can vote if #146 should be blocking Ursa Prime deployment
15:17:43 <contyk> mhroncok: that's double the maintanance and exactly the thing we're trying to get away from
15:18:10 <sgallagh> contyk: I think he means “don’t have default streams at all, only allow alternatives to be in modules”
15:18:10 <mhroncok> contyk: that's the other side of the problem
15:18:21 <bookwar> contyk: i am worried that we land non-api content into default repo, anything which user or maintainer of other component is going to build on top of the non-api package it is a direct damage
15:18:27 <mhroncok> contyk: it can be soved by providing the modular content in the normal repos, for example
15:19:12 <mhroncok> but for the user, the "magical module enablement" feature just breaks stuff, as we see with the libgit/exa bug
15:19:19 <contyk> bookwar: yes; but that's the entire point of providing the api -- so that people know what they can build on
15:20:02 <contyk> anyway
15:20:02 <bookwar> contyk: yes, that's why i am suggesting, everything which default module exposes is the api
15:20:33 <contyk> turns out I'm running the modularity meeting tomorrow so I can put #146 on the agenda
15:20:39 <sgallagh> contyk: Right, so if the stream wants to be default, it has to make that assertion. If it cannot, then it should not be default.
15:20:44 <contyk> perhaps we can discuss it there?
15:22:02 <sgallagh> contyk: We do at least need to vote on whether FESCo wants to block on 146
15:22:21 <mhroncok> could we have a ticket about that?
15:22:35 <contyk> mhroncok: about what?
15:22:35 <mhroncok> this came in out of a blue
15:22:45 <sgallagh> FTR, I’m -1 to block deploying Ursa Prime for this, but I think we really do need it answered.
15:22:51 <bookwar> i added comment to #2003
15:23:01 <mhroncok> contyk: about whether fesco wants to block modular content in the buildroot on #146
15:23:30 <contyk> we could make that a ticket instead of voting today, yes
15:23:46 <bookwar> mhroncok: this is a follow-up from a discussion at flock, but i guess, i should have bring it earlier
15:23:48 <mhroncok> ot we can vote in #2003 if bookwar post an actual proposal there
15:23:51 <nirik> perhaps we wait until after the modularity meeting discusses it?
15:24:37 <bookwar> i've added comment to 2003, let contyk have a discussion on it, and we can have a follow-up on next steps there
15:24:47 <mhroncok> works for me
15:25:08 <contyk> proposal: let's reuse #2003 to discuss this potential dependency; the modularity team will focus tomorrow's meeting on the topic, too
15:25:20 <sgallagh> +1
15:25:25 <mhroncok> +1
15:25:29 <jforbes> +1
15:25:30 <bookwar> +1
15:25:35 <nirik> +1
15:25:48 <contyk> #info Let's reuse #2003 to discuss this potential dependency; the modularity team will focus tomorrow's meeting on the topic, too
15:25:50 <zbyszek> +1
15:26:08 <contyk> okay, new business
15:26:16 <contyk> #topic #2227 Nonresponsive maintainer: Henrik Nordström hno
15:26:18 <contyk> https://pagure.io/fesco/issue/2227
15:26:33 <contyk> this seems to be stuck; anything that needs to happen?
15:27:25 <mhroncok> well the package is still owned by hno and I'd rather sen it orphaned
15:27:49 <contyk> I'd agree
15:28:15 <sgallagh> +1
15:28:19 <mhroncok> hno sent an e-mail to devel (undelivered) that they plan to orphan it in 2 weeks (that was on the 15th)
15:28:32 <mhroncok> I've asked to orphan right away, no reply
15:29:26 <mhroncok> given that 2 weeks is in a week I kept the ticket open to speed it up if it doesn't happen
15:29:47 <sgallagh> So, defer to next meeting, orphan it then?
15:30:11 <mhroncok> works for me
15:30:25 <nirik> +1
15:30:38 <mhroncok> I'm working on packaging a bzr replacement, called breezy, but it unfortunatelly is totally broken on Python 3.8, so i won't be able to deliver yet anyway
15:30:42 <jforbes> Thats fine
15:30:46 <contyk> proposed #agreed Orphan bzr next week unless the maintainer does it before then
15:30:56 <mhroncok> +1
15:31:04 <bookwar> +1
15:31:25 <zbyszek> +1
15:31:28 <sgallagh> +1
15:31:52 <nirik> +1
15:31:52 <otaylor> +1
15:32:15 <jforbes> +1
15:32:28 <contyk> #agreed Orphan bzr next week unless the maintainer does it before then (+8, 0, -0)
15:32:34 <bookwar> bzr has no python3 support, so not orphaning it would mean going through fesco exception policy and so ?
15:32:59 <mhroncok> bookwar: somebody would have to request it.
15:33:21 <contyk> #topic #2225 F32 Self-Contained Change: Switch mingw32 toolchain to dwarf-2 exceptions
15:33:23 <contyk> https://pagure.io/fesco/issue/2225
15:33:42 <mhroncok> this will be approved tmrw automatically
15:34:08 <zbyszek> Sorry, I have to run.
15:34:15 <mhroncok> bcotton: why was it tagged with meeting? because everybody seemed to ignore it?
15:34:19 <mhroncok> zbyszek: see you next time
15:34:29 <contyk> zbyszek: see you, thanks
15:34:53 <bcotton> mhroncok: yep, it was at a week and had no votes except your abstention
15:35:21 <contyk> I think I can give +1 here
15:35:39 <mhroncok> we can vote here if you want
15:35:44 <mhroncok> my vote is still 0
15:35:48 <bcotton> doesn'
15:35:49 <sgallagh> I’m comfortable with this change, I think. I somehow missed it in my email. +1
15:35:59 <bcotton> doesn't matter to me, i just wanted to flag it :-)
15:36:09 <nirik> yeah, +1 here I guess as well.
15:36:18 <jforbes> +1 here
15:36:48 <contyk> otaylor, bookwar: ?
15:36:49 <bookwar> +1
15:37:10 <otaylor> +1 - basically in "defer to the maintainer mode" :-)
15:37:33 <contyk> #agreed F32 Self-Contained Change: Switch mingw32 toolchain to dwarf-2 exceptions is approved (+8, 1, -0)
15:37:47 <contyk> #topic #2230 FESCo blocker bug: Broken upgrades via libgit2
15:37:49 <contyk> https://pagure.io/fesco/issue/2230
15:38:03 <contyk> so it's new but I put it on the agenda for, hopefully, obvious reasons
15:38:33 <mhroncok> that bug was closed during this meeting, but I've reopened it
15:39:08 <mhroncok> it kinda seems like everybody just wants to wash their hands of it :(
15:39:26 <mhroncok> I'm deeply worried that if this is nto a blocker, it won't get fixed
15:40:41 <sgallagh> I know jmracek dislikes the idea, but I'm on board with ignatenkobrain's suggestion of just doing a stream reset as a short-term workaround.
15:40:43 <otaylor> mhroncok: I'd worry about making it a blocker because there seems to be *no* generally accepted theory about how to fix it
15:41:02 <sgallagh> Because it doesn't seem realistic that the DNF team is going to have the correct fix done in time for F31 Final Freeze.
15:41:03 <mhroncok> well I'm sure there will be some, if it is a blocker
15:41:06 <bcotton> so i brought this up with the DNF team at their regular meeting last week and they basically said "we can't fix it for F31"
15:41:15 <sgallagh> otaylor: You are incorrect there
15:41:24 <mhroncok> they can fix this
15:41:27 <jforbes> mhroncok: you are more optimistic than I am
15:41:28 <contyk> yeah, I don't think this can be truly fixed in time for f31
15:41:32 <sgallagh> We do have an agreed-upon solution, but it's not going to happen in time
15:41:44 <mhroncok> they just don't want to break the (arguably wrong) spec
15:41:46 <sgallagh> So we *do* need a stopgap solution. Igor's is one; I'm open to others.
15:42:37 <bookwar> it depends on what you call "fix", and for a blocker bug it might be "workaround in this release and a peoper fix in the later"
15:42:53 <bookwar> it is still a fix of an issue
15:43:00 <nirik> so to be clear, this is distro-sync/upgrade type things, not system-update?
15:43:04 <sgallagh> Right, a band-aid is completely viable
15:43:21 <contyk> nirik: yes
15:43:24 <otaylor> sgallagh: How would resetting all module streams be implemented?
15:43:49 <contyk> otaylor: comment 26
15:43:51 <mhroncok> nirik: both
15:44:04 <bookwar> mhroncok: btw, when we say "it doesn't affect our release but it is still important", feels like we are missing important release criteria to cover such issues, can you think about some generic item which we can propose as such?
15:44:24 <mhroncok> bookwar: yes, but that is unrealistic
15:44:41 <otaylor> contyk: that wasn't clear to me - but maybe I'm not familiar enough with fedora-upgrade
15:44:59 <bookwar> mhroncok: ok, let's postpone this conversation for later
15:45:01 <nirik> if it's affecting system-upgrade also I would think it would be a blocker...
15:45:10 <mhroncok> bookwar: "modules installed via the dnf install pkgname command" must not block upgrade to newer Fedora
15:45:18 <mhroncok> nirik: it is
15:45:30 <sgallagh> The blocking criteria only applies to software that's part of a standard install for blocking media
15:45:36 <sgallagh> That'
15:45:41 <sgallagh> s why it was kicked to FESCo
15:46:00 <sgallagh> Because as of right now, we're only hitting this issue with packages that are not part of a standard install.
15:46:11 <otaylor> If this only happens for people installing and bat, and the upgrade fails cleanly pre-reboot, I don't think it's impossible to just release note this
15:46:14 <sgallagh> Such packages would not be *immune* to this problem, but none have thus far encountered it
15:46:14 <nirik> mhroncok: it's just a FE as far as I can see...
15:46:16 * mhroncok hates that criteria. it means when used dnf install anything, immediately they lost a gurantee of a safe upghrade
15:46:20 <sgallagh> So it's not a blocker by the current criteria
15:46:30 <mhroncok> nirik: it is just an FE, that's why I've opened the fesco ticket
15:46:50 <sgallagh> mhroncok: That's realistic, though. We can't possibly validate every possible package combination.
15:46:52 <jforbes> mhroncok: Well, it's a balance.
15:46:52 <mhroncok> the current criteria doesn't acount the fact that some users install additional packages
15:46:58 <sgallagh> So the line has to be drawn somewhere.
15:47:15 <mhroncok> sgallagh: I agree, but for regular packages, we are bale to solve such bugs by obsoleting them
15:47:17 <mhroncok> *able
15:47:21 <mhroncok> or modules, we are doomed
15:47:29 <mhroncok> *for
15:47:53 <mhroncok> anyway, we can discuss the criteria for hours
15:47:56 <sgallagh> Well, we *can* still obsolete them as long as the package name changes.
15:48:01 <sgallagh> But that's a side-topic
15:48:08 <bookwar> mhroncok: if there will be workaround documented in release notes, is it enough for current issue?
15:48:20 <mhroncok> bookwar: not for me
15:48:27 <nirik> I think when it was made a FE it wasn't noted that it affected system-upgrade.
15:48:32 <mhroncok> bookwar: if we document it in the upgrade guide, maybe
15:48:42 <bookwar> like if you have X installed, before the upgrade do A and B, after upgrade do C
15:48:50 <mhroncok> nirik: it was noted n final beta go nogo
15:49:10 <mhroncok> nirik: it is noted in the bugzilla before the decision was made
15:49:20 <mhroncok> it doesn't violate any current criteria
15:49:27 <mhroncok> hence I proposed ti as a fesco blocker
15:49:37 <sgallagh> mhroncok: I'm +1 for us to treat it thusly.
15:49:44 <mhroncok> sgallagh: thanks
15:49:57 <nirik> ah, I see... ok.
15:50:09 <bookwar> i would say the bug _is_ a blocked, but "solving" it through detailed description in release notes/update doc is a possible solution, if nothing else works
15:50:16 <sgallagh> mhroncok: I thought I'd included that in my comment on the ticket, but I seem to have missed it.
15:50:51 <jforbes> I am okay with a FESCo blocker as long as we can consider a workaround to satisfy that blocker for F31
15:50:53 <sgallagh> bookwar: Yeah, I could see that being an acceptable solution as well. Let me try to restate the problem
15:51:09 <nirik> how would igors workaround work?
15:51:34 <contyk> so while we have somewhat agreed-upon technical solution with the dnf team, it's not detailed and not every case is addressed, not properly spec'd; it would also not be applicable to existing installations
15:51:44 * nirik sees otaylor asked, but I can't see an answer. might need more coffee.
15:51:57 <contyk> switching contexts is also not designed yet; I can only see workarounds and docs here
15:52:03 <contyk> as options
15:52:15 <contyk> bookwar says that would be enough; mhroncok says the opposite
15:52:18 <sgallagh> Right now, there is a common case where upgrades are blocked from occurring by a limitation of the modularity implementation if users follow the same upgrade steps as in previous releases. We need for upgrades to be possible for a non-expert user. A documentation or simple script workaround may be acceptable to satisfy this, with FESCo approval.
15:52:22 <sgallagh> ^^ ?
15:52:55 <mhroncok> the dnf system upgrade can do the same fix as msuchy's tool
15:53:12 <mhroncok> for msuchy tool, it was probbaly a oneliner doen in a couple of minutes
15:53:13 <sgallagh> yes, that could be hacked in there.
15:53:22 <mhroncok> for dnf system-upgrade, it's impossible
15:53:36 <sgallagh> We are not responsible for deciding the solution
15:53:39 <mhroncok> obviously, becasue dnf needs to follow the spec
15:53:43 <sgallagh> (in this meeting, at any rate)
15:53:55 <mhroncok> so, we can make it a blocker
15:54:02 <mhroncok> and amend the spec, so the dnf team can solve this
15:54:08 <sgallagh> We need to set the constraints on what will constitute a sufficient fix for F31.
15:55:01 <sgallagh> I was attempting to do so with the long paragraph I typed above.
15:55:05 <sgallagh> Does anyone want to amend it?
15:55:17 <mhroncok> "when users click the usual buttons or type the usual commands to upgrde to Fedora 31, they must not be blocked by this problem without an actionable error message"
15:55:20 <nirik> I'm happy to make it a blocker if we think that will help it actuall get some solution... but I am not sure thats really the case.
15:55:55 * nirik is ok with sgallagh's proposal.
15:56:01 <mhroncok> I'm fine if the system-upgrade fails and says: Oh sorry, thsi is all borken, type: dnf moduel reset libgit2 to fix it
15:56:24 <mhroncok> but simply putting a note in the release notes will IMHO not work
15:56:36 <sgallagh> mhroncok: I tried to capture that with "We need for upgrades to be possible for a non-expert user."
15:56:49 <otaylor> mhroncok: Is the scope of the breakage actually "people who installed exa or bat" or is  it wider?
15:56:50 <sgallagh> To avoid being *too* specific about the eventual solution
15:56:54 <contyk> I'm also fine with sgallagh's proposal
15:57:04 <mhroncok> otaylor: wider. kile or gnome.builder are affected
15:57:25 <mhroncok> sgallagh: well they are possible for nonexpert users already
15:57:50 <sgallagh> mhroncok: If I add "without extraordinary measures" to the end of that sentence will it suffice?
15:57:50 <mhroncok> sgallagh: they just need to google the solution
15:58:22 <nirik> we can always revist close to release and decide if current efforts are enough or not.
15:58:45 <sgallagh> nirik: Yes, that's why I noted that FESCo vote is required to determine if the provided solution(s) are sufficient
15:58:48 <mhroncok> sgallagh: I don't agree that documenting this problem is a viable workaround. I worry that your proposal makes it so
15:59:18 <sgallagh> mhroncok: Depends on the documentation. What if we extended the text in system-upgrade that reminds you to be fully updated before running?
15:59:33 <contyk> note that DNF automatically switching streams for you is *not* desired, throwing an error is the correct thing to do
15:59:45 <mhroncok> contyk: an actinable error
15:59:46 <contyk> I agree the error needs to be human readable and actionable
15:59:48 <sgallagh> As I said, we (FESCo) have to approve the eventual solution
15:59:56 <otaylor> sgallagh: I *don't* think the fully-updatated before upgrading happens if you go throug hthe gnome software upgrade path
16:00:02 <mhroncok> sgallagh: ok, that wasn't entirely clear to me
16:00:17 <mhroncok> and, also, the gnome software thing
16:00:46 <sgallagh> otaylor: Yes, we'll have to consider that case as well.
16:01:04 <sgallagh> Let me try to write a complete proposal on which to vote. One moment.
16:01:10 <contyk> thanks
16:02:25 <nirik> does this also affect upgrade via gnome-software?
16:02:54 <mhroncok> nirik: I'm not sure that it was reproduced there, but I'm confident it does
16:02:55 <sgallagh> Proposal: The upgrade issue identified here is significant enough for FESCo to declare it a blocker. FESCo will vote to determine if a proposed solution or workaround is sufficient to unblock the release. At minimum, we require that a non-expert user is provided sufficient information to accomplish the upgrade without resorting to Google.
16:03:13 <nirik> then solutions may have to take that into account too.
16:03:21 <jforbes> sgallagh: +1
16:03:31 <sgallagh> mhroncok: Well, if G-S uses --allowerasing by default, it might "work"
16:03:54 <mhroncok> sgallagh: well, by removing your packages
16:04:14 <sgallagh> mhroncok: I put it in quotes for a reason, yes
16:04:28 <mhroncok> I wonder, is reading the release notes considered a stuff nonexpert user does without restoring to google?
16:04:49 <mhroncok> I would say it isn't and hence I'm +1 to the sgallagh's proposal
16:05:21 <sgallagh> mhroncok: I'd tend to agree and we still have the final vote to ensure that.
16:05:22 <mhroncok> sgallagh: oh, sorry, must have missed the quotes.
16:05:32 <mhroncok> sgallagh++
16:05:33 <sgallagh> No worries
16:05:37 <otaylor> I'm +1 to sgallagh's proposal, though I wouldn't be absolutely horrified if a user had to resort to google as long as we made the resorting to google process nice enough :-)
16:06:04 <nirik> +1 (but someone should test the gnome-software path and we should make sure it's addressed too)
16:06:34 <contyk> +1
16:06:39 <contyk> so DuckDuckGo is fine?
16:06:46 <sgallagh> .fire contyk
16:06:46 <zodbot> adamw fires contyk
16:06:51 <mhroncok> :D
16:07:24 <contyk> bookwar: ?
16:07:27 <bookwar> +1, it is a bit weak statement, but I don't think we can do more as a FESCo vote
16:08:01 <contyk> #agreed The upgrade issue identified here is significant enough for FESCo to declare it a blocker. FESCo will vote to determine if a proposed solution or workaround is sufficient to unblock the release. At minimum, we require that a non-expert user is provided sufficient information to accomplish the upgrade without resorting to Google (+7, 0, -0)
16:08:21 <contyk> okay
16:08:25 <contyk> #topic Next week's chair
16:08:33 <bookwar> jfyi "(06:05:37 PM) adamw: blocker review meeting starting in #fedora-blocker-review now"
16:08:34 <contyk> I'm most likely out next week
16:08:46 <adamw> so stop this meeting now :P
16:09:08 <sgallagh> I haven't done it in a while. I suppose I'm due.
16:09:19 * sgallagh double-checks that it's not a holiday first
16:10:17 <sgallagh> All set
16:10:23 <contyk> ack
16:10:32 <contyk> #action sgallagh will chair the next meeting
16:10:35 <contyk> #topic Open floor
16:10:49 * sgallagh falls to his death
16:11:18 <contyk> closing in a minute unless there's something
16:11:20 <nirik> watch out for the open floor!
16:12:08 <contyk> #endmeeting