AGREED: 696278 tracks
down to a dupe of 678553, which was indeed a blocker bug but was
fixed; we see no reports of anyone doing an upgrade with an NM
package fixed wrt 678553 and still having problems. closing it as a
dupe.(adamw,
17:09:58)
AGREED: 702261
rejectedblocker, rejectednth: this is not a behavior change and does
not impact any criteria, we have shipped this way for a while,
impact is not horrible(adamw,
17:13:35)
AGREED: 702003
rejectedblocker rejectednth: only affects services with both systemd
and sysv definitions, does not clearly hit any criteria, and doesn't
seem to have a significant enough impact for nth. there are
workarounds for scripts that use this functionality.(adamw,
17:33:04)
AGREED: 698654 for
now rejectedblocker rejectednth on the basis that it only affects
yum upgrades, which are not supported - also, this can be fixed with
a post-release update for the yum case, as yum implies the use of an
up-to-date repo. we will ask reporter / jlaska to re-test with
preupgrade or dvd upgrade and confirm whether this affects those
cases(adamw,
17:44:50)
AGREED: need more
info on exact impact of 690873 to determine blocker status, we will
ask for more info in the bug report, and follow up with evaluation
via the report(adamw,
17:57:45)
AGREED: 688277
rejectedblocker, acceptednth - inaccurate mount output doesn't hit
any criteria, but it's obviously something we should do right(adamw,
18:02:31)
AGREED: 701999
rejectedblocker, does not hit any criteria. for now, rejectednth as
there's no clear path to fixing this in a minimum-impact way in time
for f15; we will ask bastien to re-propose if he has a workable
proposal(adamw,
18:19:39)
AGREED: 701622
rejectedblocker as no practical impact demonstrated, acceptednth to
fix the error message and as fix is safe and simple(adamw,
18:26:03)
AGREED: 702650 unable
to determine status with current data: impact is bad, but only one
specific and quite odd layout is known to be affected, others using
encrypted partitions do not report seeing the same problem. also
need to know if booting without plymouth or without rhgb quiet acts
as a workaround. if halfline can figure out the bug that may help
assess impact(adamw,
18:45:13)
AGREED: 702633
rejectednth for now as there's no clear rationale, if simo doesn't
manage to push the fix before the freeze and has a real reason it
needs to break freeze, he can re-propose(adamw,
19:16:31)
AGREED: 699027 -1
nth; it's clearly a bug that should get fixed but no clear rationale
for why we should break the freeze (i.e. no scenario has been
described in which it can affect something for which a post-release
update wouldn't be an acceptable fix). can be re-proposed with a
more specific rationale for nth status. freeze is not till 9th, fix
can still go in before that.(adamw,
19:39:44)
AGREED: 699027 final
vote: rejectednth as there's still no known scenario of breakage on
dvd, live images, or otherwise affecting the frozen package
set(adamw,
19:54:57)
AGREED: 701704
rejectednth as it seems all parties agreed fixing in f15 timeframe
isn't practical, but change should be documented somehow(adamw,
20:06:02)
AGREED: 702740
rejectedblocker as it doesn't cause any major breakage, only 'wrong'
interface names if biosdevname is disabled. acceptednth as the if
names are fixed during install and can't be fixed with post-release
updates(adamw,
20:45:22)