On Fri, Jun 17, 2016 at 7:58 AM, Kristian Fiskerstrand <k...@gentoo.org> wrote: > On 06/17/2016 01:50 PM, Rich Freeman wrote: >> It might be better to just close the original bug, and then open a new >> STABLEREQ bug on the tracker whenever we're interested in tracking >> stabilization. That also serves as a reminder to the maintainer that >> somebody actually wants it stabilized. > > This adds another layer of complexity and requires multiple > depend/blocks specifications for a single user. I also question whether > these stabilization requests would be created if the original devs > aren't willing to call for stabilization themselves or leave the bug > open so you have the history of the issue available for the > stabilization, filtering it out based on keyword is easy to do in saved > search. >
Can you clarify what you mean by that? If I have a tracker with 47 resolved blockers, how do I know which of those made it to stable? If I'm a maintainer and I resolve a bug, how do I know if I should mark it resolved or not before it is stable? If the bug is resolved but still needs to be tracked to stable, how does anybody realize that bug is still out there and needs to be marked as stable? The problem is that tracking bugs to stable is not the normal process, so if we want to do it we need to come up with some way to make it obvious that it needs to be done. Or have some way to automate this using data from the repository/etc. Apologies if this email is a bit confusing. There are a couple of proposals out there and I'm trying to address all of them - not all of those questions will make sense for every proposal. -- Rich
