7:48 a.m.
Hello,
I was trying to install i686 variant of F-13 to an Alix board (2D13 with
Geode LX) and got into troubles. The kernel boots fine, but when it
should start initramfs the kernel panics. Everything works well when
using complete F-12 environment and when using F-12 kernel+initramfs
with F-13 rootfs the initramfs stuff runs well, but when I try to
manually chroot into the F-13 from the dracut shell I get an "Invalid
instruction" exception. I though last change in x86 CPU support was in
F-12 (http://fedoraproject.org/wiki/Features/F12X86Support) and it
explicitly talks about Geode LX as still supported. So the question is
whether F-13 should still work on Geode LX?
Dan
1:31 p.m.
On Mon, Apr 05, 2010 at 02:48:03PM +0200, Dan Horák wrote:
Hello,
I was trying to install i686 variant of F-13 to an Alix board (2D13 with
Geode LX) and got into troubles. The kernel boots fine, but when it
should start initramfs the kernel panics. Everything works well when
using complete F-12 environment and when using F-12 kernel+initramfs
with F-13 rootfs the initramfs stuff runs well, but when I try to
manually chroot into the F-13 from the dracut shell I get an "Invalid
instruction" exception. I though last change in x86 CPU support was in
F-12 (http://fedoraproject.org/wiki/Features/F12X86Support) and it
explicitly talks about Geode LX as still supported. So the question is
whether F-13 should still work on Geode LX?
The 2D3/2D13 has only 256 MB of RAM which is a bit tight for
installing Fedora. TBH I didn't even expect Fedora would work, so I
put Debian on my 2D3 :-(
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://et.redhat.com/~rjones/libguestfs/
See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html
1:47 p.m.
Richard W.M. Jones píše v Po 05. 04. 2010 v 19:31 +0100:
On Mon, Apr 05, 2010 at 02:48:03PM +0200, Dan Horák wrote:
> Hello,
>
> I was trying to install i686 variant of F-13 to an Alix board (2D13 with
> Geode LX) and got into troubles. The kernel boots fine, but when it
> should start initramfs the kernel panics. Everything works well when
> using complete F-12 environment and when using F-12 kernel+initramfs
> with F-13 rootfs the initramfs stuff runs well, but when I try to
> manually chroot into the F-13 from the dracut shell I get an "Invalid
> instruction" exception. I though last change in x86 CPU support was in
> F-12 (http://fedoraproject.org/wiki/Features/F12X86Support) and it
> explicitly talks about Geode LX as still supported. So the question is
> whether F-13 should still work on Geode LX?
The 2D3/2D13 has only 256 MB of RAM which is a bit tight for
installing Fedora. TBH I didn't even expect Fedora would work, so I
put Debian on my 2D3 :-(
yes, installing Fedora with anaconda in 256MB could be a problem, but
it's sufficient for running minimalized Fedora. It will serve as a
router/firewall/vpn server on my Internet connection. Thus I prepared a
system with "yum --installroot=/mnt/compactflash install ...". I will
write a blog entry tomorrow with all the details.
Dan
1:38 p.m.
On Mon, Apr 5, 2010 at 1:48 PM, Dan Horák <dan(a)danny.cz> wrote:
Hello,
I was trying to install i686 variant of F-13 to an Alix board (2D13 with
Geode LX) and got into troubles. The kernel boots fine, but when it
should start initramfs the kernel panics. Everything works well when
using complete F-12 environment and when using F-12 kernel+initramfs
with F-13 rootfs the initramfs stuff runs well, but when I try to
manually chroot into the F-13 from the dracut shell I get an "Invalid
instruction" exception. I though last change in x86 CPU support was in
F-12 (http://fedoraproject.org/wiki/Features/F12X86Support) and it
explicitly talks about Geode LX as still supported. So the question is
whether F-13 should still work on Geode LX?
That is correct, it should still work and if it has changed it hasn't
been a published change and we rule out the 1.2 million odd OLPC XO-1s
that currently run a number of different versions of Fedora. Could
someone please verify the status of this?
Peter
1:47 p.m.
On 06/02/2010 12:09 PM, Peter Robinson wrote:
It does work in F-12, the response for the lack of support in F-13
was
'deal with it'. There is suppose to be a patch to emulate it in the
kernel but apparently it won't go upstream until its a generic infra
patch that can allow support of other emulated bits in other cpus in a
generic way. So its possible it will come back, but I don't hold up
hope of a quick resolution. Which leaves us in a big predicament as to
how we're going to support the 1.5 million odd XO-1s out there moving
forward.
Can you file a ticket with FESCo? Would be useful to track and resolve
this issue.
Rahul
3:43 p.m.
On 05.04.2010 14:48, Dan Horák wrote:
I was trying to install i686 variant of F-13 to an Alix board (2D13 with
Geode LX) and got into troubles. The kernel boots fine, but when it
should start initramfs the kernel panics. Everything works well when
using complete F-12 environment and when using F-12 kernel+initramfs
with F-13 rootfs the initramfs stuff runs well, but when I try to
manually chroot into the F-13 from the dracut shell I get an "Invalid
instruction" exception. I though last change in x86 CPU support was in
F-12 (http://fedoraproject.org/wiki/Features/F12X86Support) and it
explicitly talks about Geode LX as still supported. So the question is
whether F-13 should still work on Geode LX?
Sorry to reopen this old topic, but the conclusion is not obvious. The
F13 is out and it seems to have lost support for the Geode LX CPU
(cf.http://sharkcz.livejournal.com/5708.html), due to the use of the
NOPL instruction by GCC.
Will this CPU be supported during F13 and above or should I search for a
new distribution ?
Regards,
Glandvador
10:52 p.m.
On Tue, Jun 01, 2010 at 22:43:25 +0200,
Gland Vador <glandvador(a)yahoo.com> wrote:
On 05.04.2010 14:48, Dan Horák wrote:
>
> I was trying to install i686 variant of F-13 to an Alix board (2D13 with
> Geode LX) and got into troubles. The kernel boots fine, but when it
> should start initramfs the kernel panics. Everything works well when
> using complete F-12 environment and when using F-12 kernel+initramfs
> with F-13 rootfs the initramfs stuff runs well, but when I try to
> manually chroot into the F-13 from the dracut shell I get an "Invalid
> instruction" exception. I though last change in x86 CPU support was in
> F-12 (http://fedoraproject.org/wiki/Features/F12X86Support) and it
> explicitly talks about Geode LX as still supported. So the question is
> whether F-13 should still work on Geode LX?
>
Sorry to reopen this old topic, but the conclusion is not obvious. The
F13 is out and it seems to have lost support for the Geode LX CPU
(cf.http://sharkcz.livejournal.com/5708.html), due to the use of the
NOPL instruction by GCC.
Will this CPU be supported during F13 and above or should I search for a
new distribution ?
I don't believe there was any intentional change in supported CPUs for F13.
If it was supposed to work in F12, I think it is supposed to work in F13.
Did you file a bug against gcc?
1:39 a.m.
On Wed, Jun 2, 2010 at 4:52 AM, Bruno Wolff III <bruno(a)wolff.to> wrote:
On Tue, Jun 01, 2010 at 22:43:25 +0200,
Gland Vador <glandvador(a)yahoo.com> wrote:
> On 05.04.2010 14:48, Dan Horák wrote:
> >
> > I was trying to install i686 variant of F-13 to an Alix board (2D13 with
> > Geode LX) and got into troubles. The kernel boots fine, but when it
> > should start initramfs the kernel panics. Everything works well when
> > using complete F-12 environment and when using F-12 kernel+initramfs
> > with F-13 rootfs the initramfs stuff runs well, but when I try to
> > manually chroot into the F-13 from the dracut shell I get an "Invalid
> > instruction" exception. I though last change in x86 CPU support was in
> > F-12 (http://fedoraproject.org/wiki/Features/F12X86Support) and it
> > explicitly talks about Geode LX as still supported. So the question is
> > whether F-13 should still work on Geode LX?
> >
>
> Sorry to reopen this old topic, but the conclusion is not obvious. The
> F13 is out and it seems to have lost support for the Geode LX CPU
> (cf.http://sharkcz.livejournal.com/5708.html), due to the use of the
> NOPL instruction by GCC.
>
> Will this CPU be supported during F13 and above or should I search for a
> new distribution ?
I don't believe there was any intentional change in supported CPUs for F13.
If it was supposed to work in F12, I think it is supposed to work in F13.
Did you file a bug against gcc?
It does work in F-12, the response for the lack of support in F-13 was
'deal with it'. There is suppose to be a patch to emulate it in the
kernel but apparently it won't go upstream until its a generic infra
patch that can allow support of other emulated bits in other cpus in a
generic way. So its possible it will come back, but I don't hold up
hope of a quick resolution. Which leaves us in a big predicament as to
how we're going to support the 1.5 million odd XO-1s out there moving
forward.
Peter
2:19 a.m.
On Tue, Jun 1, 2010 at 7:47 PM, Rahul Sundaram <metherid(a)gmail.com> wrote:
On 06/02/2010 12:09 PM, Peter Robinson wrote:
> It does work in F-12, the response for the lack of support in F-13 was
> 'deal with it'. There is suppose to be a patch to emulate it in the
> kernel but apparently it won't go upstream until its a generic infra
> patch that can allow support of other emulated bits in other cpus in a
> generic way. So its possible it will come back, but I don't hold up
> hope of a quick resolution. Which leaves us in a big predicament as to
> how we're going to support the 1.5 million odd XO-1s out there moving
> forward.
>
Can you file a ticket with FESCo? Would be useful to track and resolve
this issue.
I will do. I'll gather up all the bits I have an add it to the ticket.
Thanks,
Peter
2:49 a.m.
On 02.06.2010 09:19, Peter Robinson wrote:
On Tue, Jun 1, 2010 at 7:47 PM, Rahul Sundaram wrote:
> On 06/02/2010 12:09 PM, Peter Robinson wrote:
>> It does work in F-12, the response for the lack of support in F-13 was
>> 'deal with it'. There is suppose to be a patch to emulate it in the
>> kernel but apparently it won't go upstream until its a generic infra
>> patch that can allow support of other emulated bits in other cpus in a
>> generic way. So its possible it will come back, but I don't hold up
>> hope of a quick resolution. Which leaves us in a big predicament as to
>> how we're going to support the 1.5 million odd XO-1s out there moving
>> forward.
>>
>
> Can you file a ticket with FESCo? Would be useful to track and resolve
> this issue.
I will do. I'll gather up all the bits I have an add it to the ticket.
Thank you Peter,
I hope a solution can be found before the obsolescence of F12. If
needed, I'm ready to help.
Regards,
Glandvador.
4:49 a.m.
On Wed, Jun 02, 2010 at 08:19:24AM +0100, Peter Robinson wrote:
On Tue, Jun 1, 2010 at 7:47 PM, Rahul Sundaram
<metherid(a)gmail.com> wrote:
> On 06/02/2010 12:09 PM, Peter Robinson wrote:
>> It does work in F-12, the response for the lack of support in F-13 was
>> 'deal with it'. There is suppose to be a patch to emulate it in the
>> kernel but apparently it won't go upstream until its a generic infra
>> patch that can allow support of other emulated bits in other cpus in a
>> generic way. So its possible it will come back, but I don't hold up
>> hope of a quick resolution. Which leaves us in a big predicament as to
>> how we're going to support the 1.5 million odd XO-1s out there moving
>> forward.
>>
>
> Can you file a ticket with FESCo? Would be useful to track and resolve
> this issue.
I will do. I'll gather up all the bits I have an add it to the ticket.
I just created a ticket:
https://fedorahosted.org/fesco/ticket/387
Regards
Till
9:13 a.m.
On Wed, Jun 02, 2010 at 08:19:24 +0100,
Peter Robinson <pbrobinson(a)gmail.com> wrote:
On Tue, Jun 1, 2010 at 7:47 PM, Rahul Sundaram
<metherid(a)gmail.com> wrote:
> On 06/02/2010 12:09 PM, Peter Robinson wrote:
>> It does work in F-12, the response for the lack of support in F-13 was
>> 'deal with it'. There is suppose to be a patch to emulate it in the
>> kernel but apparently it won't go upstream until its a generic infra
>> patch that can allow support of other emulated bits in other cpus in a
>> generic way. So its possible it will come back, but I don't hold up
>> hope of a quick resolution. Which leaves us in a big predicament as to
>> how we're going to support the 1.5 million odd XO-1s out there moving
>> forward.
>>
>
> Can you file a ticket with FESCo? Would be useful to track and resolve
> this issue.
I will do. I'll gather up all the bits I have an add it to the ticket.
Thanks.
This issue points out a gap in our QA testing.
Fixing it now could end up being painful (if we need to rebuild lots of
packages). Catching it earlier would have made that (lots of rebuilds)
a lot more palatible.
Also the process for changing which instructions gets used in generated
code should be looked at. The gcc people should not just be deciding this
in a vacuum. Even changing some instructions to emulation could potentially
have big performance impacts.
9:30 a.m.
On 06/02/2010 07:43 PM, Bruno Wolff III wrote:
This issue points out a gap in our QA testing.
Fixing it now could end up being painful (if we need to rebuild lots of
packages). Catching it earlier would have made that (lots of rebuilds)
a lot more palatible.
Fedora 14 will have a new GCC and a mass rebuild anyway. So in this
case, we can slip in a change if needed.
Rahul
10:23 a.m.
On Wed, Jun 2, 2010 at 2:39 AM, Peter Robinson <pbrobinson(a)gmail.com> wrote:
It does work in F-12, the response for the lack of support in F-13
was
'deal with it'. There is suppose to be a patch to emulate it in the
kernel but apparently it won't go upstream until its a generic infra
patch that can allow support of other emulated bits in other cpus in a
generic way. So its possible it will come back, but I don't hold up
hope of a quick resolution. Which leaves us in a big predicament as to
how we're going to support the 1.5 million odd XO-1s out there moving
forward.
I believe this was the latest post of the NOPL emulation patch:
http://lkml.org/lkml/2010/3/1/430 This is not the general instruction
emulator mentioned, but a fix intended just for getting the Geode LX
classed as i686.
I haven't used this patch myself yet; my Geode LX machine runs an
older Fedora, so it still works. I suppose I'll need to try the patch
during the next upgrade until things are settled.
10:42 a.m.
On Wed, Jun 02, 2010 at 11:23:37AM -0400, David Michael wrote:
On Wed, Jun 2, 2010 at 2:39 AM, Peter Robinson
<pbrobinson(a)gmail.com> wrote:
> It does work in F-12, the response for the lack of support in F-13 was
> 'deal with it'. There is suppose to be a patch to emulate it in the
> kernel but apparently it won't go upstream until its a generic infra
> patch that can allow support of other emulated bits in other cpus in a
> generic way. So its possible it will come back, but I don't hold up
> hope of a quick resolution. Which leaves us in a big predicament as to
> how we're going to support the 1.5 million odd XO-1s out there moving
> forward.
I believe this was the latest post of the NOPL emulation patch:
http://lkml.org/lkml/2010/3/1/430 This is not the general instruction
emulator mentioned, but a fix intended just for getting the Geode LX
classed as i686.
I haven't used this patch myself yet; my Geode LX machine runs an
older Fedora, so it still works. I suppose I'll need to try the patch
during the next upgrade until things are settled.
I wonder what the performance impact is. NOPL appears to be a
variable length NOP (no-op). Obviously a very useful instruction for
things like alignment, and gcc seems to stuff lots of them into the
code:
$ objdump -d /bin/ls | wc -l
16867
$ objdump -d /bin/ls | grep nopl | wc -l
369
369/16867 ~ 2%
This is not a very fair comparison because we'd want to know how
frequently NOPL is executed, but I hope it shows that these
instructions are not infrequent.
Having said that, AMD Geodes are slowwwwww anyway ...
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
10:56 a.m.
On Tue, 2010-06-01 at 22:43 +0200, Gland Vador wrote:
Sorry to reopen this old topic, but the conclusion is not obvious.
The
F13 is out and it seems to have lost support for the Geode LX CPU
(cf.http://sharkcz.livejournal.com/5708.html), due to the use of the
NOPL instruction by GCC.
Will this CPU be supported during F13 and above or should I search for a
new distribution ?
I really, really think primitive x86 support should be done as a
secondary arch.
- ajax
11:11 a.m.
Hi,
On Wed, Jun 2, 2010 at 11:42 AM, Richard W.M. Jones <rjones(a)redhat.com> wrote:
I wonder what the performance impact is. NOPL appears to be a
variable length NOP (no-op). Obviously a very useful instruction for
things like alignment, and gcc seems to stuff lots of them into the
code:
$ objdump -d /bin/ls | wc -l
16867
$ objdump -d /bin/ls | grep nopl | wc -l
369
369/16867 ~ 2%
This is not a very fair comparison because we'd want to know how
frequently NOPL is executed, but I hope it shows that these
instructions are not infrequent.
I recall checking this when F12 was declared to go i686 but retain
support for Geode LX CPUs. NOPLs were common in x86_64, but seemed to
be very infrequent in 32-bit land (which is what would run on a Geode
anyway).
To see if this is still the case, I downloaded and extracted F13's
32-bit coreutils, and no binary appears to contain a single NOPL.
(Though I get a similar result as your test with x86_64.)
objdump -d {,usr/}{,s}bin/* | grep -Fc nopl
0
Having said that, AMD Geodes are slowwwwww anyway ...
I wouldn't exactly use it as a gaming rig, but a silent wireless
computer on <5W power can always be used for something.
11:20 a.m.
On Wed, Jun 02, 2010 at 12:11:26PM -0400, David Michael wrote:
Hi,
On Wed, Jun 2, 2010 at 11:42 AM, Richard W.M. Jones <rjones(a)redhat.com> wrote:
> I wonder what the performance impact is. NOPL appears to be a
> variable length NOP (no-op). Obviously a very useful instruction for
> things like alignment, and gcc seems to stuff lots of them into the
> code:
>
> $ objdump -d /bin/ls | wc -l
> 16867
> $ objdump -d /bin/ls | grep nopl | wc -l
> 369
>
> 369/16867 ~ 2%
>
> This is not a very fair comparison because we'd want to know how
> frequently NOPL is executed, but I hope it shows that these
> instructions are not infrequent.
I recall checking this when F12 was declared to go i686 but retain
support for Geode LX CPUs. NOPLs were common in x86_64, but seemed to
be very infrequent in 32-bit land (which is what would run on a Geode
anyway).
To see if this is still the case, I downloaded and extracted F13's
32-bit coreutils, and no binary appears to contain a single NOPL.
(Though I get a similar result as your test with x86_64.)
objdump -d {,usr/}{,s}bin/* | grep -Fc nopl
0
Ah very true. I was forgetting that they were 32 bit.
(I even *have* one of them :-)
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
4:43 p.m.
On Wed, 2010-06-02 at 09:13 -0500, Bruno Wolff III wrote:
This issue points out a gap in our QA testing.
Indeed, although there are _many_ gaps in our QA testing, and this is
not news. =) We don't have the resources to test anywhere close to
everything. The extent of claimed CPU arch support is just one of the
things we're not equipped to test...
(It does kind of surprise me that _no-one_ at OLPC managed to notice
this before release, though. We do betas!)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
4:54 p.m.
On Wed, Jun 02, 2010 at 02:43:11PM -0700, Adam Williamson wrote:
On Wed, 2010-06-02 at 09:13 -0500, Bruno Wolff III wrote:
> This issue points out a gap in our QA testing.
Indeed, although there are _many_ gaps in our QA testing, and this is
not news. =) We don't have the resources to test anywhere close to
everything. The extent of claimed CPU arch support is just one of the
things we're not equipped to test...
(It does kind of surprise me that _no-one_ at OLPC managed to notice
this before release, though. We do betas!)
The bug report was there one week before the announcement of the beta:
https://bugzilla.redhat.com/show_bug.cgi?id=579838
Regards
Till
5:07 p.m.
On Wed, 2010-06-02 at 23:54 +0200, Till Maas wrote:
On Wed, Jun 02, 2010 at 02:43:11PM -0700, Adam Williamson wrote:
> On Wed, 2010-06-02 at 09:13 -0500, Bruno Wolff III wrote:
>
> > This issue points out a gap in our QA testing.
>
> Indeed, although there are _many_ gaps in our QA testing, and this is
> not news. =) We don't have the resources to test anywhere close to
> everything. The extent of claimed CPU arch support is just one of the
> things we're not equipped to test...
>
> (It does kind of surprise me that _no-one_ at OLPC managed to notice
> this before release, though. We do betas!)
The bug report was there one week before the announcement of the beta:
https://bugzilla.redhat.com/show_bug.cgi?id=579838
Ah. It's a shame it wasn't put up for consideration as a release
blocker. Obviously the rather peremptory response from Jakub didn't help
with that...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
6:31 p.m.
On Wed, Jun 2, 2010 at 2:07 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
Ah. It's a shame it wasn't put up for consideration as a
release
blocker. Obviously the rather peremptory response from Jakub didn't help
with that...
Would the flag concept for blocker status that Jesse was championing
recently have helped in this situation. If the bug is closed with a
non fixed resolution, but flagged with request from the reporter to be
a blocker would this have provided a mechanism to escalate this issue
into a release management discussion that would have revisited the
issue and overturned Jakub's assessment of the situation? Or would
resolution as notabug have nullified a blocker request flag mechanism?
-jef
6:45 p.m.
On Wed, 2010-06-02 at 15:31 -0800, Jeff Spaleta wrote:
On Wed, Jun 2, 2010 at 2:07 PM, Adam Williamson
<awilliam(a)redhat.com> wrote:
> Ah. It's a shame it wasn't put up for consideration as a release
> blocker. Obviously the rather peremptory response from Jakub didn't help
> with that...
Would the flag concept for blocker status that Jesse was championing
recently have helped in this situation. If the bug is closed with a
non fixed resolution, but flagged with request from the reporter to be
a blocker would this have provided a mechanism to escalate this issue
into a release management discussion that would have revisited the
issue and overturned Jakub's assessment of the situation? Or would
resolution as notabug have nullified a blocker request flag mechanism?
It's a bit intangible and not entirely predicated on whether we're using
the keyword or flag setup, I think. Currently when we're considering
bugs we use a search that excludes closed bugs, so even if you flag a
closed bug with F14Blocker or whatever, it won't get on the agenda for
the review meeting unless someone explicitly mentions it. I'm not sure
Jesse's proposed system necessarily makes any difference to that; even
if we're using flags, I don't think we'd automatically start doing
searches that included closed bugs. But of course, it might make sense
not to worry about the bug status with the more fine-grained info the
flag system would provide.
Now I've waffled a bit =) I think the ultimate answer is that it's
certainly _possible_ we could use the proposed flag system to consider
blocker status even for closed bugs, yeah.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
6:58 p.m.
On Wed, Jun 2, 2010 at 3:45 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
It's a bit intangible and not entirely predicated on whether
we're using
the keyword or flag setup, I think. Currently when we're considering
bugs we use a search that excludes closed bugs,
In either case, I would suggest that it may be best to just exclude
certain closed resolutions but review others. wontfix and notabug may
hide some potential blockers that are worthy of calm discussion with a
maintainer from a release management pov.
-jef
10:38 a.m.
On Wed, 2010-06-02 at 15:31 -0800, Jeff Spaleta wrote:
On Wed, Jun 2, 2010 at 2:07 PM, Adam Williamson
<awilliam(a)redhat.com> wrote:
> Ah. It's a shame it wasn't put up for consideration as a release
> blocker. Obviously the rather peremptory response from Jakub didn't help
> with that...
Would the flag concept for blocker status that Jesse was championing
recently have helped in this situation. If the bug is closed with a
non fixed resolution, but flagged with request from the reporter to be
a blocker would this have provided a mechanism to escalate this issue
into a release management discussion that would have revisited the
issue and overturned Jakub's assessment of the situation? Or would
resolution as notabug have nullified a blocker request flag mechanism?
I don't see why the means to overturn a NOTABUG resolution should be
coupled to the blocker status. If I were the reporter, I would first
reopen the bug. If the maintainer continues to close it with unhelpful
comments, I would raise the issue on the devel list to build support for
my position or find out if there's a better way to address the issue. I
assume the ultimate way to appeal a bad decision is to place the issue
on the FESCo agenda, though I have never done that myself.
Once it is established that the bug is valid and will be kept open, it
can be considered as a blocker like any other bug.
--
Matt
11:33 a.m.
On Wed, 2010-06-02 at 15:58 -0800, Jeff Spaleta wrote:
On Wed, Jun 2, 2010 at 3:45 PM, Adam Williamson
<awilliam(a)redhat.com> wrote:
> It's a bit intangible and not entirely predicated on whether we're using
> the keyword or flag setup, I think. Currently when we're considering
> bugs we use a search that excludes closed bugs,
In either case, I would suggest that it may be best to just exclude
certain closed resolutions but review others. wontfix and notabug may
hide some potential blockers that are worthy of calm discussion with a
maintainer from a release management pov.
That sounds like a good idea to me, thanks.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
5074
days inactive
5133
days old
25 comments
12 participants
participants (12)
-
Adam Jackson -
Adam Williamson -
Bruno Wolff III -
Dan Horák -
David Michael -
glandvador -
Jef Spaleta -
Matt McCutchen -
Peter Robinson -
Rahul Sundaram -
Richard W.M. Jones -
Till Maas