6:20 a.m.
Hi folks, and welcome to the Fedora 20 Beta blocker bug news...
The bad news is that we're still some way from a viable Beta RC. We need
work on several blockers, all of which is outlined below. I'll start
with bugs that need work from developers; QA folks, there are tasks for
us listed later on.
Accepted blockers - anaconda and python-blivet
----------------------------------------------
* https://bugzilla.redhat.com/show_bug.cgi?id=986575 - "installer fails
to apply lower bound to resize requests in custom spoke" - this bug has
been open for a while and needs a fix from anaconda team, when they have
time.
* https://bugzilla.redhat.com/show_bug.cgi?id=1010495 - "Apple Mac EFI:
you have not created a bootloader stage1 target device" - this bug
breaks the most common installation scenarios for Apple systems (guided
install alongside an existing OS X install). bcl has been working on
fixing it: back in September he posted an initial patch, then decided
that it was not sufficient -
https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-September/... .
There is no information since then that I can find.
* https://bugzilla.redhat.com/show_bug.cgi?id=1016959 - "ValueError:
Cannot remove non-leaf device 'btrfs.14'" - this is a crasher with
certain existing btrfs volumes. dlehman posted a plan on how to fix it,
but there is no proposed patch that I can find.
Accepted blockers - other
-------------------------
* https://bugzilla.redhat.com/show_bug.cgi?id=1000891 - "DVD is
oversized (larger than 4.7 GB)" (spin-kickstarts, comps, pungi) - a fix
for this was scheduled for TC3, but it caused the DVD compose to break,
and was backed out to produce a testable TC4. TC5 continued without the
problematic fix (and hence is still over-size). AIUI, dgilmore was
supposed to be looking into the compose issue, but I believe he is now
on vacation, so we may need someone else to step in: CCing nirik and
notting.
* https://bugzilla.redhat.com/show_bug.cgi?id=1013767 - "rootfs on thinp
not found, startup failure" (dracut) - an update containing a fix for
this has been submitted -
https://admin.fedoraproject.org/updates/dracut-034-18.git20131018.fc20 -
but one reliable tester has reported that it breaks boot on their
system, so further developer work may be required here, harald:
https://bugzilla.redhat.com/show_bug.cgi?id=1021083
* https://bugzilla.redhat.com/show_bug.cgi?id=1015234 - "F20 Beta TC1
ARM disk images unable to find root filesystem" (dracut) - this bug is
marked as an unresolved blocker but has in fact been worked around
since, I believe, TC2. We can probably ship Beta with the workaround,
and this may just need some Bugzilla Bureaucracy rather than developer
attention at this point.
Proposed blockers
-----------------
* https://bugzilla.redhat.com/show_bug.cgi?id=1020974 - "incorrectly
treats a disk with partially corrupt GPT as having no partition at
all" (anaconda) - this looks like it could well be accepted as a
blocker, so developer attention would be appreciated.
* https://bugzilla.redhat.com/show_bug.cgi?id=1005895 - "Upgrade to f20
fails because of deltarpms" (fedup) - Will posted a proposed fix for
informal testing; Will, one of the reporters has confirmed the fix is
good, so can you please submit an update? Thanks!
Bugs requiring QA attention
---------------------------
* https://bugzilla.redhat.com/show_bug.cgi?id=1017435 - "Anaconda uses
LVM when Standard Partition is selected in text mode" (anaconda) - this
bug has been verified fixed by the update
https://admin.fedoraproject.org/updates/python-blivet-0.23.1-1.fc20,anaco...
, but that update needs more karma to go stable. That is the build that is in TC5, so
anyone who's tested TC5 and found it generally OK (no worse than previous builds) can
+1 the update: please do!
* https://bugzilla.redhat.com/show_bug.cgi?id=1013800 -
"devicetree.py:1293:handleVgLvs:DeviceTreeError: failed to look up thin
pool" (python-blivet) - this is believed to be fixed by the
https://admin.fedoraproject.org/updates/python-blivet-0.23.1-1.fc20,anaco...
update (and hence in TC5). We need to verify the fix and add karma to the update so it can
be pushed stable and the bug closed.
* https://bugzilla.redhat.com/show_bug.cgi?id=1019500 - "device
factories need to set a default name if empty name given for defined
device" - exactly the same as 1013800: this should be fixed in TC5,
please confirm the fix and up-karma the update.
This has been your blocker bug news, folks - if everyone can help out
with fixing the remaining issues and testing the anaconda/blivet update,
that'd be a great help. Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin DOT net
http://www.happyassassin.net
8:45 a.m.
On 10/19/2013 07:20 AM, Adam Williamson wrote:
Hi folks, and welcome to the Fedora 20 Beta blocker bug news...
The bad news is that we're still some way from a viable Beta RC. We need
work on several blockers, all of which is outlined below. I'll start
with bugs that need work from developers; QA folks, there are tasks for
us listed later on.
Accepted blockers - anaconda and python-blivet
----------------------------------------------
* https://bugzilla.redhat.com/show_bug.cgi?id=986575 - "installer fails
to apply lower bound to resize requests in custom spoke" - this bug has
been open for a while and needs a fix from anaconda team, when they have
time.
* https://bugzilla.redhat.com/show_bug.cgi?id=1010495 - "Apple Mac EFI:
you have not created a bootloader stage1 target device" - this bug
breaks the most common installation scenarios for Apple systems (guided
install alongside an existing OS X install). bcl has been working on
fixing it: back in September he posted an initial patch, then decided
that it was not sufficient -
https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-September/... .
There is no information since then that I can find.
* https://bugzilla.redhat.com/show_bug.cgi?id=1016959 - "ValueError:
Cannot remove non-leaf device 'btrfs.14'" - this is a crasher with
certain existing btrfs volumes. dlehman posted a plan on how to fix it,
but there is no proposed patch that I can find.
Accepted blockers - other
-------------------------
* https://bugzilla.redhat.com/show_bug.cgi?id=1000891 - "DVD is
oversized (larger than 4.7 GB)" (spin-kickstarts, comps, pungi) - a fix
for this was scheduled for TC3, but it caused the DVD compose to break,
and was backed out to produce a testable TC4. TC5 continued without the
problematic fix (and hence is still over-size). AIUI, dgilmore was
supposed to be looking into the compose issue, but I believe he is now
on vacation, so we may need someone else to step in: CCing nirik and
notting.
* https://bugzilla.redhat.com/show_bug.cgi?id=1013767 - "rootfs on thinp
not found, startup failure" (dracut) - an update containing a fix for
this has been submitted -
https://admin.fedoraproject.org/updates/dracut-034-18.git20131018.fc20 -
but one reliable tester has reported that it breaks boot on their
system, so further developer work may be required here, harald:
https://bugzilla.redhat.com/show_bug.cgi?id=1021083
* https://bugzilla.redhat.com/show_bug.cgi?id=1015234 - "F20 Beta TC1
ARM disk images unable to find root filesystem" (dracut) - this bug is
marked as an unresolved blocker but has in fact been worked around
since, I believe, TC2. We can probably ship Beta with the workaround,
and this may just need some Bugzilla Bureaucracy rather than developer
attention at this point.
Proposed blockers
-----------------
* https://bugzilla.redhat.com/show_bug.cgi?id=1020974 - "incorrectly
treats a disk with partially corrupt GPT as having no partition at
all" (anaconda) - this looks like it could well be accepted as a
blocker, so developer attention would be appreciated.
* https://bugzilla.redhat.com/show_bug.cgi?id=1005895 - "Upgrade to f20
fails because of deltarpms" (fedup) - Will posted a proposed fix for
informal testing; Will, one of the reporters has confirmed the fix is
good, so can you please submit an update? Thanks!
Bugs requiring QA attention
---------------------------
* https://bugzilla.redhat.com/show_bug.cgi?id=1017435 - "Anaconda uses
LVM when Standard Partition is selected in text mode" (anaconda) - this
bug has been verified fixed by the update
https://admin.fedoraproject.org/updates/python-blivet-0.23.1-1.fc20,anaco...
, but that update needs more karma to go stable. That is the build that is in TC5, so
anyone who's tested TC5 and found it generally OK (no worse than previous builds) can
+1 the update: please do!
There are two problems with this update and I have
submitted patches for
both:
1. The fix for handling existing btrfs subvolumes does not work (yet),
small fix needed.
2. The change in the way swap definitions are handled for additions to
fstab omits handling the case for existing noformat swap definitions on
both regular partitions and logical volumes.
Without these patches or equivalent, this is definitely a blocker.
Gene
* https://bugzilla.redhat.com/show_bug.cgi?id=1013800 -
"devicetree.py:1293:handleVgLvs:DeviceTreeError: failed to look up thin
pool" (python-blivet) - this is believed to be fixed by the
https://admin.fedoraproject.org/updates/python-blivet-0.23.1-1.fc20,anaco...
update (and hence in TC5). We need to verify the fix and add karma to the update so it can
be pushed stable and the bug closed.
* https://bugzilla.redhat.com/show_bug.cgi?id=1019500 - "device
factories need to set a default name if empty name given for defined
device" - exactly the same as 1013800: this should be fixed in TC5,
please confirm the fix and up-karma the update.
This has been your blocker bug news, folks - if everyone can help out
with fixing the remaining issues and testing the anaconda/blivet update,
that'd be a great help. Thanks!
5:36 p.m.
On Sat, 2013-10-19 at 09:45 -0400, Gene Czarcinski wrote:
> * https://bugzilla.redhat.com/show_bug.cgi?id=1017435 -
"Anaconda uses
> LVM when Standard Partition is selected in text mode" (anaconda) - this
> bug has been verified fixed by the update
>
https://admin.fedoraproject.org/updates/python-blivet-0.23.1-1.fc20,anaco...
, but that update needs more karma to go stable. That is the build that is in TC5, so
anyone who's tested TC5 and found it generally OK (no worse than previous builds) can
+1 the update: please do!
There are two problems with this update and I have submitted patches for
both:
1. The fix for handling existing btrfs subvolumes does not work (yet),
small fix needed.
2. The change in the way swap definitions are handled for additions to
fstab omits handling the case for existing noformat swap definitions on
both regular partitions and logical volumes.
Without these patches or equivalent, this is definitely a blocker.
It's not a blocker unless someone files a bug and proposes it as a
blocker: that's how the process works. Is there a bug report? And are
these *new* problems compared to 20.24/20.25?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
5:38 a.m.
On 10/19/2013 06:36 PM, Adam Williamson wrote:
On Sat, 2013-10-19 at 09:45 -0400, Gene Czarcinski wrote:
>> * https://bugzilla.redhat.com/show_bug.cgi?id=1017435 - "Anaconda uses
>> LVM when Standard Partition is selected in text mode" (anaconda) - this
>> bug has been verified fixed by the update
>>
https://admin.fedoraproject.org/updates/python-blivet-0.23.1-1.fc20,anaco...
, but that update needs more karma to go stable. That is the build that is in TC5, so
anyone who's tested TC5 and found it generally OK (no worse than previous builds) can
+1 the update: please do!
> There are two problems with this update and I have submitted patches for
> both:
>
> 1. The fix for handling existing btrfs subvolumes does not work (yet),
> small fix needed.
>
> 2. The change in the way swap definitions are handled for additions to
> fstab omits handling the case for existing noformat swap definitions on
> both regular partitions and logical volumes.
>
> Without these patches or equivalent, this is definitely a blocker.
It's not a blocker unless someone files a bug and proposes it as a
blocker: that's how the process works. Is there a bug report? And are
these *new* problems compared to 20.24/20.25?
That depends on how you define
"new"
With 20.25.1, there is a claim that it fixes the problem identified in:
https://bugzilla.redhat.com/show_bug.cgi?id=892747
where an existing btrfs subvolume with --noformat specified is ignored
rather than being added to fstab. The problem is that it is not fixed.
I have attached a tested patch to correct this to the bugzilla report.
Before 20.25.1, if you had an existing swap on a regular partition or a
logical volume and you specified --noformat, that swap specification was
added to fstab. With 20.25.1, this is no longer the case and you wind
up with no swap at all. You might want to not reformat that swap
because you are using UUID and you have another system (multiboot) also
using that swap and refering to it also by UUID. This problem is
reported by:
https://bugzilla.redhat.com/show_bug.cgi?id=1020867
Again, I have attached a tested patch to correct the problem to the
bugzilla report.
This swap problem was introduced by changes made in 20.25.1.
Gene
12:11 p.m.
On Oct 20, 2013, at 4:38 AM, Gene Czarcinski <gene(a)czarc.net> wrote:
Before 20.25.1, if you had an existing swap on a regular partition or a logical volume
and you specified --noformat, that swap specification was added to fstab. With 20.25.1,
this is no longer the case and you wind up with no swap at all. You might want to not
reformat that swap because you are using UUID and you have another system (multiboot) also
using that swap and refering to it also by UUID. This problem is reported by:
https://bugzilla.redhat.com/show_bug.cgi?id=1020867
Again, I have attached a tested patch to correct the problem to the bugzilla report.
This swap problem was introduced by changes made in 20.25.1.
It might be related to this:
http://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generato...
Since systemd is auto mounting certain partitiontypeguids, they don't need to be in
fstab. There are few bugs filed as a result of the ensuing confusion. So it might be new
behavior in anaconda 20.25.1 to ignore the request to reuse existing swap by adding it to
fstab since it knows systemd is going to use it in any case.
Chris Murphy
8:58 a.m.
On 10/20/2013 01:11 PM, Chris Murphy wrote:
On Oct 20, 2013, at 4:38 AM, Gene Czarcinski <gene(a)czarc.net>
wrote:
>
> Before 20.25.1, if you had an existing swap on a regular partition or a logical
volume and you specified --noformat, that swap specification was added to fstab. With
20.25.1, this is no longer the case and you wind up with no swap at all. You might want
to not reformat that swap because you are using UUID and you have another system
(multiboot) also using that swap and refering to it also by UUID. This problem is
reported by:
> https://bugzilla.redhat.com/show_bug.cgi?id=1020867
> Again, I have attached a tested patch to correct the problem to the bugzilla report.
>
> This swap problem was introduced by changes made in 20.25.1.
It might be related to this:
http://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generato...
Since systemd is auto mounting certain partitiontypeguids, they don't need to be in
fstab. There are few bugs filed as a result of the ensuing confusion. So it might be new
behavior in anaconda 20.25.1 to ignore the request to reuse existing swap by adding it to
fstab since it knows systemd is going to use it in any case.
If I specifically specify an existing regular partition or logical
volume as swap and specify "--noformat" in the kickstart file, then the
way it has been working is that such swap specifications are added to fstab.
Currently, a bigger aggravation to me is that if I am just doing a
install using the GUI, I cannot re-use an existing swap without
reclaiming the space and thus reformatting it and having it get a new
UUID. Of course if I have another system install into different
partitions and it is also using that swap by UUID, it now will be
screwed. Sometimes using UUID is not a good idea. This problem has
been bugzill'ed. I was hoping the "swap-fix" would help with that but I
believe it will not.
Gene
10 a.m.
On Oct 21, 2013, at 7:58 AM, Gene Czarcinski <gene(a)czarc.net> wrote:
If I specifically specify an existing regular partition or logical volume as swap and
specify "--noformat" in the kickstart file, then the way it has been working is
that such swap specifications are added to fstab.
Regression in kickstart? I can't do this in the GUI. I have to reformat swap for some
reason.
My speculation is wrong in any case with GUI install, swap is still put in the fstab with
anaconda 20.25.1-1 and RHBZ 1017509 still applies.
Of course if I have another system install into different partitions
and it is also using that swap by UUID, it now will be screwed.
I agree, not friendly.
Sometimes using UUID is not a good idea. This problem has been
bugzill'ed. I was hoping the "swap-fix" would help with that but I believe
it will not.
So then the question is, if the disk is GPT, can/should systemd use UniquePartitionGUID in
the GPT for swap partitions rather than the swap volume format UUID? The
UniquePartitionGUID is more stable.
Chris Murphy
2:01 p.m.
New subject: gtk3 broken/missing icons on kde
Adam Williamson wrote:
Hi folks, and welcome to the Fedora 20 Beta blocker bug news...
can't find any criteria currently that covers application icons (though do
mention it if such a thing exists)...
At issue here are gtk3 applications that use non-standard (e.g. symbolic)
icons look particularly bad on kde (or any desktop that doesn't use an icon
theme that has does not have a fallback to gnome icon theme). See:
https://bugzilla.redhat.com/show_bug.cgi?id=1018390 (*)
(includes screenshot), reported over a week ago without comment yet, so here
am, soliciting feedback.
If gtk applications need a gnome-icon-theme fallback to be fully functional,
then depending on the currently configured icon theme to do it feels like
the wrong approach to me.
Kevin (Kofler) and I provided what I think are constructive and not
unreasonable suggestions:
* restore Net/FallbackIconTheme support
* use a hard-coded gnome-icons fallback (instead of hicolor)
In particular, adding a hard-coded fallback to gnome-icons in kde is not a
particularly pleasing option (as mentioned in the bug already).
-- Rex
7:06 a.m.
New subject: gtk3 broken/missing icons on kde
On Sat, 2013-10-19 at 14:01 -0500, Rex Dieter wrote:
Adam Williamson wrote:
> Hi folks, and welcome to the Fedora 20 Beta blocker bug news...
can't find any criteria currently that covers application icons (though do
mention it if such a thing exists)...
At issue here are gtk3 applications that use non-standard (e.g. symbolic)
icons look particularly bad on kde (or any desktop that doesn't use an icon
theme that has does not have a fallback to gnome icon theme). See:
https://bugzilla.redhat.com/show_bug.cgi?id=1018390 (*)
(includes screenshot), reported over a week ago without comment yet, so here
am, soliciting feedback.
If gtk applications need a gnome-icon-theme fallback to be fully functional,
then depending on the currently configured icon theme to do it feels like
the wrong approach to me.
Kevin (Kofler) and I provided what I think are constructive and not
unreasonable suggestions:
* restore Net/FallbackIconTheme support
* use a hard-coded gnome-icons fallback (instead of hicolor)
In particular, adding a hard-coded fallback to gnome-icons in kde is not a
particularly pleasing option (as mentioned in the bug already).
Did you try with gtk 3.10.1 ? We've fixed the 'generic fallback' to drop
-symbolic after exhausting other possibilities. E.g. for
drive-harddisk-usb-symbolic we're now looking for
drive-harddisk-usb-symbolic
drive-harddisk-symbolic
drive-symbolic
drive-harddisk-usb
drive-harddisk
drive
in that order.
8 p.m.
New subject: gtk3 broken/missing icons on kde
On Sat, 2013-10-19 at 14:01 -0500, Rex Dieter wrote:
Adam Williamson wrote:
> Hi folks, and welcome to the Fedora 20 Beta blocker bug news...
can't find any criteria currently that covers application icons (though do
mention it if such a thing exists)...
At issue here are gtk3 applications that use non-standard (e.g. symbolic)
icons look particularly bad on kde (or any desktop that doesn't use an icon
theme that has does not have a fallback to gnome icon theme). See:
https://bugzilla.redhat.com/show_bug.cgi?id=1018390 (*)
(includes screenshot), reported over a week ago without comment yet, so here
am, soliciting feedback.
If gtk applications need a gnome-icon-theme fallback to be fully functional,
then depending on the currently configured icon theme to do it feels like
the wrong approach to me.
Kevin (Kofler) and I provided what I think are constructive and not
unreasonable suggestions:
* restore Net/FallbackIconTheme support
* use a hard-coded gnome-icons fallback (instead of hicolor)
In particular, adding a hard-coded fallback to gnome-icons in kde is not a
particularly pleasing option (as mentioned in the bug already).
I don't think we'd really be correct in blocking the release for such
issues - especially not Beta. We used to have 'polish' criteria for
Final which at least required the icons used in the system menus - i.e.
what's specified in the app's .desktop file - to be sane for all
installed applications, but we dropped that (and other polish criteria)
with the F19/F20 criteria re-write on the basis that they were really
stretching a bit too far and would be unlikely to hold up to a 'last
blocker before release' acid test. Stuff like this doesn't break
anyone's use of the system catastrophically and can reasonably be fixed
with updates.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
6:46 p.m.
New subject: gtk3 broken/missing icons on kde
Adam Williamson wrote:
I don't think we'd really be correct in blocking the release
for such
issues - especially not Beta. We used to have 'polish' criteria for
Final which at least required the icons used in the system menus - i.e.
what's specified in the app's .desktop file - to be sane for all
installed applications, but we dropped that (and other polish criteria)
with the F19/F20 criteria re-write on the basis that they were really
stretching a bit too far and would be unlikely to hold up to a 'last
blocker before release' acid test. Stuff like this doesn't break
anyone's use of the system catastrophically and can reasonably be fixed
with updates.
But it also affects the live images (making them look very unpolished) and
we don't respin those.
Kevin Kofler
8:03 p.m.
New subject: gtk3 broken/missing icons on kde
On Sun, 2013-10-27 at 01:46 +0200, Kevin Kofler wrote:
Adam Williamson wrote:
> I don't think we'd really be correct in blocking the release for such
> issues - especially not Beta. We used to have 'polish' criteria for
> Final which at least required the icons used in the system menus - i.e.
> what's specified in the app's .desktop file - to be sane for all
> installed applications, but we dropped that (and other polish criteria)
> with the F19/F20 criteria re-write on the basis that they were really
> stretching a bit too far and would be unlikely to hold up to a 'last
> blocker before release' acid test. Stuff like this doesn't break
> anyone's use of the system catastrophically and can reasonably be fixed
> with updates.
But it also affects the live images (making them look very unpolished) and
we don't respin those.
That's why I said 'reasonably' not 'perfectly' :) I can see an
argument
for blocking Final, though in practice, I don't think our current
standards are such that it really makes sense to claim our final
releases are so smooth as to be worth enforcing a high standard of
polish via the blocker mechanisms. But certainly for Beta it seems too
trivial.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
1:23 a.m.
New subject: gtk3 broken/missing icons on kde
On Tue, Nov 5, 2013 at 3:03 AM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Sun, 2013-10-27 at 01:46 +0200, Kevin Kofler wrote:
> Adam Williamson wrote:
> > I don't think we'd really be correct in blocking the release for such
> > issues - especially not Beta. We used to have 'polish' criteria for
> > Final which at least required the icons used in the system menus - i.e.
> > what's specified in the app's .desktop file - to be sane for all
> > installed applications, but we dropped that (and other polish criteria)
> > with the F19/F20 criteria re-write on the basis that they were really
> > stretching a bit too far and would be unlikely to hold up to a 'last
> > blocker before release' acid test. Stuff like this doesn't break
> > anyone's use of the system catastrophically and can reasonably be fixed
> > with updates.
>
> But it also affects the live images (making them look very unpolished) and
> we don't respin those.
That's why I said 'reasonably' not 'perfectly' :) I can see an
argument
for blocking Final, though in practice, I don't think our current
standards are such that it really makes sense to claim our final
releases are so smooth as to be worth enforcing a high standard of
polish via the blocker mechanisms
Then we should that. There is a difference between "perfect" and something that
looks obviously broken.
10:19 a.m.
New subject: gtk3 broken/missing icons on kde
On Tue, 2013-11-05 at 08:23 +0100, drago01 wrote:
On Tue, Nov 5, 2013 at 3:03 AM, Adam Williamson
<awilliam(a)redhat.com> wrote:
> On Sun, 2013-10-27 at 01:46 +0200, Kevin Kofler wrote:
>> Adam Williamson wrote:
>> > I don't think we'd really be correct in blocking the release for
such
>> > issues - especially not Beta. We used to have 'polish' criteria
for
>> > Final which at least required the icons used in the system menus - i.e.
>> > what's specified in the app's .desktop file - to be sane for all
>> > installed applications, but we dropped that (and other polish criteria)
>> > with the F19/F20 criteria re-write on the basis that they were really
>> > stretching a bit too far and would be unlikely to hold up to a 'last
>> > blocker before release' acid test. Stuff like this doesn't break
>> > anyone's use of the system catastrophically and can reasonably be
fixed
>> > with updates.
>>
>> But it also affects the live images (making them look very unpolished) and
>> we don't respin those.
>
> That's why I said 'reasonably' not 'perfectly' :) I can see an
argument
> for blocking Final, though in practice, I don't think our current
> standards are such that it really makes sense to claim our final
> releases are so smooth as to be worth enforcing a high standard of
> polish via the blocker mechanisms
Then we should that. There is a difference between "perfect" and something
that
looks obviously broken.
Are we really fighting about the classification of fixed bugs here, or
is there a new issue that I am not aware of ?
10:27 a.m.
New subject: gtk3 broken/missing icons on kde
On Tuesday, November 5, 2013, Matthias Clasen wrote:
On Tue, 2013-11-05 at 08:23 +0100, drago01 wrote:
> On Tue, Nov 5, 2013 at 3:03 AM, Adam Williamson
<awilliam@redhat.com<javascript:;>>
wrote:
> > On Sun, 2013-10-27 at 01:46 +0200, Kevin Kofler wrote:
> >> Adam Williamson wrote:
> >> > I don't think we'd really be correct in blocking the release
for
such
> >> > issues - especially not Beta. We used to have 'polish'
criteria for
> >> > Final which at least required the icons used in the system menus -
i.e.
> >> > what's specified in the app's .desktop file - to be sane for
all
> >> > installed applications, but we dropped that (and other polish
criteria)
> >> > with the F19/F20 criteria re-write on the basis that they were
really
> >> > stretching a bit too far and would be unlikely to hold up to a
'last
> >> > blocker before release' acid test. Stuff like this doesn't
break
> >> > anyone's use of the system catastrophically and can reasonably be
fixed
> >> > with updates.
> >>
> >> But it also affects the live images (making them look very
unpolished) and
> >> we don't respin those.
> >
> > That's why I said 'reasonably' not 'perfectly' :) I can see
an argument
> > for blocking Final, though in practice, I don't think our current
> > standards are such that it really makes sense to claim our final
> > releases are so smooth as to be worth enforcing a high standard of
> > polish via the blocker mechanisms
>
> Then we should that. There is a difference between "perfect" and
something that
> looks obviously broken.
Are we really fighting about the classification of fixed bugs here,
Yes ;)
8:20 p.m.
New subject: gtk3 broken/missing icons on kde
On Tue, 2013-11-05 at 11:19 -0500, Matthias Clasen wrote:
On Tue, 2013-11-05 at 08:23 +0100, drago01 wrote:
> On Tue, Nov 5, 2013 at 3:03 AM, Adam Williamson <awilliam(a)redhat.com> wrote:
> > On Sun, 2013-10-27 at 01:46 +0200, Kevin Kofler wrote:
> >> Adam Williamson wrote:
> >> > I don't think we'd really be correct in blocking the release
for such
> >> > issues - especially not Beta. We used to have 'polish'
criteria for
> >> > Final which at least required the icons used in the system menus -
i.e.
> >> > what's specified in the app's .desktop file - to be sane for
all
> >> > installed applications, but we dropped that (and other polish
criteria)
> >> > with the F19/F20 criteria re-write on the basis that they were really
> >> > stretching a bit too far and would be unlikely to hold up to a
'last
> >> > blocker before release' acid test. Stuff like this doesn't
break
> >> > anyone's use of the system catastrophically and can reasonably be
fixed
> >> > with updates.
> >>
> >> But it also affects the live images (making them look very unpolished) and
> >> we don't respin those.
> >
> > That's why I said 'reasonably' not 'perfectly' :) I can see
an argument
> > for blocking Final, though in practice, I don't think our current
> > standards are such that it really makes sense to claim our final
> > releases are so smooth as to be worth enforcing a high standard of
> > polish via the blocker mechanisms
>
> Then we should that. There is a difference between "perfect" and something
that
> looks obviously broken.
Are we really fighting about the classification of fixed bugs here, or
is there a new issue that I am not aware of ?
It's become a question of whether there should be a Beta or Final
requirement for icons to be present / "look good", I think.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
3821
days inactive
3839
days old
15 comments
7 participants
participants (7)
-
Adam Williamson -
Chris Murphy -
drago01 -
Gene Czarcinski -
Kevin Kofler -
Matthias Clasen -
Rex Dieter