Bug Triage workflow for F13 and beyond

TK009 john.brown009 at gmail.com
Fri Nov 20 16:39:01 UTC 2009


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)





More information about the fedora-test-list mailing list