Description of problem: kernel-3.9.1-301.fc19 which is being used in F18 Beta is unstable on Calxeda Highbank systems. Version-Release number of selected component (if applicable): kernel-3.9.1-301.fc19 How reproducible: Most of the time. Steps to Reproduce: 1. Boot to kernel-3.9.1-301.fc19 2. 'dmesg | fpaste' Actual results: System will crash. Expected results: Url for the fpaste. Additional info: This is resolved in kernel-3.9.2-301.fc19.
(In reply to comment #0) > Description of problem: > kernel-3.9.1-301.fc19 which is being used in F18 Beta is unstable on Calxeda > Highbank systems. > > Version-Release number of selected component (if applicable): > kernel-3.9.1-301.fc19 > > How reproducible: > Most of the time. > > Steps to Reproduce: > 1. Boot to kernel-3.9.1-301.fc19 > 2. 'dmesg | fpaste' > > Actual results: > System will crash. > > > Expected results: > Url for the fpaste. > > Additional info: > This is resolved in kernel-3.9.2-301.fc19. Then why did you file a bug against the kernel?
*** Bug 956831 has been marked as a duplicate of this bug. ***
"Then why did you file a bug against the kernel?" To mark it as a Freeze Exception issue for Beta. The FE / blocker tracking process relies on bugs.
https://admin.fedoraproject.org/updates/FEDORA-2013-8162/kernel-3.9.2-301.fc19 is the update for this. +1 FE as a major issue on a secondary arch (ARM).
(In reply to comment #3) > "Then why did you file a bug against the kernel?" > > To mark it as a Freeze Exception issue for Beta. The FE / blocker tracking > process relies on bugs. Great. I'm going to just guess that it doesn't rely on bugs being in a non-closed state, and that kernel is already headed to stable.
You could ask me, rather than just guessing, so we don't have to play this game of ping pong. It does rely on the bugs being in a non-closed state, because otherwise how do we distinguish between a bug that's not a blocker, a bug that's a blocker that we've dealt with, and a bug that's a blocker that we haven't dealt with? And F19 is in freeze for Beta, so nothing goes to stable automatically. What I'm trying to do here, and you're trying as hard as possible to stop me doing, is _to get your kernel into stable_. It won't go there for Beta unless you leave this bug open.
im +1 to including this in Beta
+1 FE
(In reply to comment #6) > You could ask me, rather than just guessing, so we don't have to play this > game of ping pong. > > It does rely on the bugs being in a non-closed state, because otherwise how > do we distinguish between a bug that's not a blocker, a bug that's a blocker > that we've dealt with, and a bug that's a blocker that we haven't dealt > with? And F19 is in freeze for Beta, so nothing goes to stable > automatically. What I'm trying to do here, and you're trying as hard as > possible to stop me doing, is _to get your kernel into stable_. It won't go > there for Beta unless you leave this bug open. No, what I'm trying to do is avoid having a second (yes second) pointless bug open in the kernel for an issue that is already fixed. I realize you have no other tool at the moment other than bugzilla to use for your process, but if you can't read the contents of the bug to determine the answer to your 3 possible states then I would be disappointed. Now, had people just gone with the original bug I marked as duplicate in comment #2, then maybe that would have made sense. But opening another identical bug against an already stale kernel when there's already a kernel that is known to be fixed is just pointless. MORE BUGS is not better.
Well, you marked the old bug as a dupe of this one. If you'd marked this bug as a dupe of the old one, I would've used that one as the blocker/FE bug. I figured closing the old one as a dupe of this one meant you preferred us to use this one. "if you can't read the contents of the bug to determine the answer to your 3 possible states then I would be disappointed" that doesn't scale to dozens of proposed/accepted blockers/FEs. We have a page that gives us an overview of the blocker/FE bug set: http://qa.fedoraproject.org/blockerbugs/current which we use extensively. If a bug is CLOSED, it does not appear on that list. And note that the Fedora policy is that bugs in Branched/Stable releases are closed *when the fix goes to stable*, not before. So per policy, this bug should be open until the kernel actually goes into stable anyway.
+1 FE Josh, I can agree that Bugzilla is probably not a best fit for this process, especially voting there is pretty nasty and we are aware of it (it really helps speed up spinning composes closer to the release) but it's what we have now. I'd expect QA would be happy to hear any ideas how to improve it or tools proposals.
Tim has a plan for pulling all the nomination / voting stuff into the blocker bug app, he just needs time to do it. But even if we do that, I don't see that we can stop relying on the actual open/closed state of the bug in Bugzilla. Really, I don't see that there's a problem here at all: it is correct that we CLOSE bugs when the fix is actually pushed stable, and not before. I don't think you can really argue with that.
(In reply to comment #10) > Well, you marked the old bug as a dupe of this one. If you'd marked this bug > as a dupe of the old one, I would've used that one as the blocker/FE bug. I > figured closing the old one as a dupe of this one meant you preferred us to > use this one. There was no clue this bug was being used for some kind of blocker process until after I'd made my comment and closed it originally. Nothing in the comments, etc. > > And note that the Fedora policy is that bugs in Branched/Stable releases are > closed *when the fix goes to stable*, not before. So per policy, this bug > should be open until the kernel actually goes into stable anyway. We have no insight into whether a secondary arch includes a particular build in their version of stable. Anyway, let's do this. Let's assign it to the people that are actually responsible for this bug, and they can close it whenever they think is appropriate. Nobody on kernel-maint is looking at this at all.
(In reply to comment #12) > Really, I don't see that there's a problem here at all: it > is correct that we CLOSE bugs when the fix is actually pushed stable, and > not before. I don't think you can really argue with that. I can, because it's a secondary arch. The tooling _we_ have (bodhi) does not mean that when the primary build gets pushed to stable, it's in ARM stable too. They are completely decoupled by the very nature of it being a secondary arch. Anyway, I'm done arguing. My request for the future would be: 1) Don't file pointless duplicate bugs for the sake of process. Use the original ones. 2) Assign secondary arch stuff to people that care about the secondary arches.
Josh: I wasn't talking about ARM stable, I was talking about primary arch stable. The update is not yet in primary arch stable and will not go there until we are unfrozen unless it is explicitly pushed through the freeze.
That's 4 +1s, setting acceptedFE.
Update has now been pushed stable, closing.