On 06/17/2016 02:18 PM, Rich Freeman wrote: > 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? >
The once that are RESOLVED FIXED, before they are in stable they should be open with InVCS keyword > 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 package is in stable to begin with, I would certainly prefer it not to be marked fixed before it is in stable in all cases to avoid that ambiguity. keywords are useful for search and filtering > > 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? It shouldn't be closed before it is in stable to begin with, issue solved > > 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. Tracking bugs are a separate matter, in particular for feature development etc, I use this e.g for [gnupg] > > 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. > References: [gnupg] https://bugs.gentoo.org/show_bug.cgi?id=552936 -- Kristian Fiskerstrand OpenPGP certificate reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
signature.asc
Description: OpenPGP digital signature
