Today we celebrate another successful Fedora release (F12), congratulations to everyone.
Never one to sit still development has already begun on F13, and with it comes a new bug triage work flow.
For bugs filed against F13(rawhide) and beyond the keyword "Triaged" will now be used to indicate that a bug report has been triaged. BugZappers will no longer change the bug state to ASSIGNED, that will now be left in the hands of the package maintainers.
BugZappers will still be using the NEEDINFO flag and closing reports as duplicates.
The wiki will soon be updated to reflect these changes.
Steven
===================================================== Steven M. Parrish ------------------------------------------------------------------------------------------------- gpg fingerprint: 4B6C 8357 059E B7ED 8095 0FD6 1F4B EDA0 A9A6 13C0 http://tuxbrewr.fedorapeople.org/ IRC nick: SMParrish on irc.freenode.net Channels: #fedora-kde, #fedora-olpc, #sugar, #fedora-devel, and many more
On Tue, Nov 17, 2009 at 11:09:32AM -0500, Steven M. Parrish wrote:
For bugs filed against F13(rawhide) and beyond the keyword "Triaged" will now be used to indicate that a bug report has been triaged. BugZappers will no longer change the bug state to ASSIGNED, that will now be left in the hands of the package maintainers.
BugZappers will still be using the NEEDINFO flag and closing reports as duplicates.
The wiki will soon be updated to reflect these changes.
So what does this mean for automatic bug filing tools like the upstream-release-monitoring tool. Should it now create bugs as NEW with keyword Triaged and FutureFeature? Or does FutureFeature already imply Triaged? Or should it only be Triaged? Btw. is FutureFeature even documented? I cannot find it on the Bugstatus workflow wiki page: https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow
Regards Till
On Thu, 2009-11-19 at 22:36 +0100, Till Maas wrote:
On Tue, Nov 17, 2009 at 11:09:32AM -0500, Steven M. Parrish wrote:
For bugs filed against F13(rawhide) and beyond the keyword "Triaged" will now be used to indicate that a bug report has been triaged. BugZappers will no longer change the bug state to ASSIGNED, that will now be left in the hands of the package maintainers.
BugZappers will still be using the NEEDINFO flag and closing reports as duplicates.
The wiki will soon be updated to reflect these changes.
So what does this mean for automatic bug filing tools like the upstream-release-monitoring tool. Should it now create bugs as NEW with keyword Triaged and FutureFeature? Or does FutureFeature already imply Triaged? Or should it only be Triaged? Btw. is FutureFeature even documented? I cannot find it on the Bugstatus workflow wiki page: https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow
I don't know what to tell you about FutureFeature. Nothing regarding that has changed. AFAIK it's intended for feature requests, so wouldn't make any sense to automatically put on abrt reports.
The change here is quite simply that bugs that have been triaged should be marked with the Triaged keyword, not by switching to the ASSIGNED status. That's it.
I don't think abrt bugs should be filed as if they had been triaged, because there are cases where an abrt-filed bug will still need manual triage. The most obvious is dependency detection (many abrt-filed bugs are dupes and abrt itself doesn't catch this often enough at present), but there are others, like needing more specific information about exactly what a user _did_ that triggered a particular crash. Just because it was filed by abrt doesn't mean it doesn't need triage.
So, I would say the correct default behaviour for ABRT would just be to file bugs as NEW, and that was the case both before and after this policy change.
On Thu, Nov 19, 2009 at 02:14:59PM -0800, Adam Williamson wrote:
I don't know what to tell you about FutureFeature. Nothing regarding that has changed. AFAIK it's intended for feature requests, so wouldn't make any sense to automatically put on abrt reports.
FutureFeature is the keyword that is used to avoid getting the version of bugs changed from Rawhide to FXX, when FXX is released.
The change here is quite simply that bugs that have been triaged should be marked with the Triaged keyword, not by switching to the ASSIGNED status. That's it.
I don't think abrt bugs should be filed as if they had been triaged, because there are cases where an abrt-filed bug will still need manual
I was not asking about abrt, but about upstream release monitoring[0] (Formerly known as FEVer), which will file new bugs when a new upstream release is available. Currently new bugs are created agains Rawhide as ASSIGNED, FutureFeature. So I guess the workflow change should make this NEW, FutureFeature, Triaged?
Regards Till
[0] https://fedoraproject.org/wiki/Upstream_Release_Monitoring
On 11/20/2009 07:27 AM, Till Maas wrote:
On Thu, Nov 19, 2009 at 02:14:59PM -0800, Adam Williamson wrote:
I don't know what to tell you about FutureFeature. Nothing regarding that has changed. AFAIK it's intended for feature requests, so wouldn't make any sense to automatically put on abrt reports.
FutureFeature is the keyword that is used to avoid getting the version of bugs changed from Rawhide to FXX, when FXX is released.
The change here is quite simply that bugs that have been triaged should be marked with the Triaged keyword, not by switching to the ASSIGNED status. That's it.
I don't think abrt bugs should be filed as if they had been triaged, because there are cases where an abrt-filed bug will still need manual
I was not asking about abrt, but about upstream release monitoring[0] (Formerly known as FEVer), which will file new bugs when a new upstream release is available. Currently new bugs are created agains Rawhide as ASSIGNED, FutureFeature. So I guess the workflow change should make this NEW, FutureFeature, Triaged?
Regards Till
[0] https://fedoraproject.org/wiki/Upstream_Release_Monitoring
Till,
I don't have any experience with upstream release monitoring, NEW, FutureFeature, Triaged would be correct for continuity. However, if people are used to ASSIGNED would making this change be a benefit or cause confusion?
The bugzappers made the change because there was a benefit in terms of the bugzappers and maintainers/developers working relationship. Maybe I am thinking on this harder than it needs but without experience with upstream release monitoring I can't say this change brings any benefit other than continuity. You would probably know best the pros and cons this change would have and whether you should implement it for your project.
Maybe Adam will have a different take but those are my initial thoughts.
Edward (tk009)
On Fri, 2009-11-20 at 11:39 -0500, TK009 wrote:
Till,
I don't have any experience with upstream release monitoring, NEW, FutureFeature, Triaged would be correct for continuity. However, if people are used to ASSIGNED would making this change be a benefit or cause confusion?
The bugzappers made the change because there was a benefit in terms of the bugzappers and maintainers/developers working relationship. Maybe I am thinking on this harder than it needs but without experience with upstream release monitoring I can't say this change brings any benefit other than continuity. You would probably know best the pros and cons this change would have and whether you should implement it for your project.
Maybe Adam will have a different take but those are my initial thoughts.
Well, we've been referring to this as the 'semantics' change for a while. The semantics of the change are that ASSIGNED should be 'owned' by the package maintainer(s); they use it for whatever purpose is appropriate to them. That's how it's described on the updated lifecycle page. Following that logic, it doesn't make sense even for FEver to set ASSIGNED when reporting bugs, as that is usurping the privilege of the maintainer(s). Fr'instance, for a package with multiple maintainers, they may only want to set the bug to ASSIGNED after picking one particular maintainer to be responsible for the version update.
On Fri, 2009-11-20 at 13:27 +0100, Till Maas wrote:
I don't think abrt bugs should be filed as if they had been triaged, because there are cases where an abrt-filed bug will still need manual
I was not asking about abrt, but about upstream release monitoring[0] (Formerly known as FEVer), which will file new bugs when a new upstream release is available. Currently new bugs are created agains Rawhide as ASSIGNED, FutureFeature. So I guess the workflow change should make this NEW, FutureFeature, Triaged?
ahh, I misunderstood. Apologies. Indeed, yes, that would be appropriate.
-
Adam Williamson -
Steven M. Parrish -
Till Maas -
TK009