Re: [gentoo-dev] [RFC] bugs.g.o: Killing VERIFIED state, possibly introducing STABILIZED

[Kristian Fiskerstrand <k_f@gentoo.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2511 bytes --]

On 06/17/2016 02:18 PM, Rich Freeman wrote:
> On Fri, Jun 17, 2016 at 7:58 AM, Kristian Fiskerstrand <k_f@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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]