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

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]

Hello, everyone.

Here's the third bugs.g.o redesign RFC.

This time it's about closed bugs. Right now we have two states for
them: RESOLVED and VERIFIED.

RESOLVED is the usual state that the developers use when they close
a bug. It's also the only state that could be directly transferred from
other states.

VERIFIED is used scarcely, and not really consistently. It can only be
used on RESOLVED bugs, and sometimes users use it to confirm that
the bug is resolved.

To be honest, I don't really see the need for VERIFIED state. Since
it's used scarcely, it can't be really relied upon. Some users use it
completely incorrectly (e.g. when the bug should be reopened instead).

What I'd like to introduce instead is a new STABILIZED state. It would
-- like VERIFIED now -- be only available for bugs already RESOLVED,
and it could be used to signify that the fix has made it into stable.

While this wouldn't be really obligatory, it would be meaningful for
trackers that need to ensure that fixes in packages have made it to
stable -- like the functions.sh use tracker.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

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

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

[Kristian Fiskerstrand]

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

On 06/16/2016 03:02 PM, Michał Górny wrote:
> Hello, everyone.
> 



> 
> What I'd like to introduce instead is a new STABILIZED state. It would
> -- like VERIFIED now -- be only available for bugs already RESOLVED,
> and it could be used to signify that the fix has made it into stable.
> 
> While this wouldn't be really obligatory, it would be meaningful for
> trackers that need to ensure that fixes in packages have made it to
> stable -- like the functions.sh use tracker.
> 

The description of InVCS keyword in bugzilla is:
InVCS 	Fix has been added to a VCS(either CVS, SVN, Git, ...)
repository. Will be closed when fixes are applied to a stable level package.

A bug isn't resolved until it is fixed in a stable package (for packages
ever in stable to begin with), but InVCS keyword can be used by
developers to filter out the bugs for issues to work with. I oppose a
change to that behavior, although I would like to see it being used more
consistently as it seems quite a few developers are neglecting the
stable tree.

-- 
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 --]

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

[James Le Cuirot]

On Thu, 16 Jun 2016 15:14:44 +0200
Kristian Fiskerstrand <k_f@gentoo.org> wrote:

> > What I'd like to introduce instead is a new STABILIZED state. It
> > would -- like VERIFIED now -- be only available for bugs already
> > RESOLVED, and it could be used to signify that the fix has made it
> > into stable.
> > 
> > While this wouldn't be really obligatory, it would be meaningful for
> > trackers that need to ensure that fixes in packages have made it to
> > stable -- like the functions.sh use tracker.
> 
> The description of InVCS keyword in bugzilla is:
> InVCS 	Fix has been added to a VCS(either CVS, SVN, Git, ...)
> repository. Will be closed when fixes are applied to a stable level
> package.
> 
> A bug isn't resolved until it is fixed in a stable package (for
> packages ever in stable to begin with), but InVCS keyword can be used
> by developers to filter out the bugs for issues to work with. I
> oppose a change to that behavior, although I would like to see it
> being used more consistently as it seems quite a few developers are
> neglecting the stable tree.

I currently set InVCS for pending-stable fixes in conjunction with the
IN_PROGRESS state. I would like to keep InVCS at least.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

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

[Kristian Fiskerstrand]

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

On 06/16/2016 03:19 PM, James Le Cuirot wrote:
> I currently set InVCS for pending-stable fixes in conjunction with the
> IN_PROGRESS state. I would like to keep InVCS at least.

Exactly

-- 
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 --]

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

[M. J. Everitt]

[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]

On 16/06/16 14:19, James Le Cuirot wrote:
> On Thu, 16 Jun 2016 15:14:44 +0200
> Kristian Fiskerstrand <k_f@gentoo.org> wrote:
>
>>> What I'd like to introduce instead is a new STABILIZED state. It
>>> would -- like VERIFIED now -- be only available for bugs already
>>> RESOLVED, and it could be used to signify that the fix has made it
>>> into stable.
>>>
>>> While this wouldn't be really obligatory, it would be meaningful for
>>> trackers that need to ensure that fixes in packages have made it to
>>> stable -- like the functions.sh use tracker.
>> The description of InVCS keyword in bugzilla is:
>> InVCS 	Fix has been added to a VCS(either CVS, SVN, Git, ...)
>> repository. Will be closed when fixes are applied to a stable level
>> package.
>>
>> A bug isn't resolved until it is fixed in a stable package (for
>> packages ever in stable to begin with), but InVCS keyword can be used
>> by developers to filter out the bugs for issues to work with. I
>> oppose a change to that behavior, although I would like to see it
>> being used more consistently as it seems quite a few developers are
>> neglecting the stable tree.
> I currently set InVCS for pending-stable fixes in conjunction with the
> IN_PROGRESS state. I would like to keep InVCS at least.
>
Possibly a 'COMMITTED' tag would fit this slightly better? There is room
for some QA 'VERIFIED' tag too, but don't know whether this is
absolutely necessary for Gentoo .. thoughts welcomed, though.

I prefer this Lifecycle diagram to that published in the latest docs:
https://www.bugzilla.org/docs/3.6/en/html/lifecycle.html .


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

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1400 bytes --]

On Thu, 16 Jun 2016 15:14:44 +0200
Kristian Fiskerstrand <k_f@gentoo.org> wrote:

> On 06/16/2016 03:02 PM, Michał Górny wrote:
> > Hello, everyone.
> >   
> 
> 
> 
> > 
> > What I'd like to introduce instead is a new STABILIZED state. It would
> > -- like VERIFIED now -- be only available for bugs already RESOLVED,
> > and it could be used to signify that the fix has made it into stable.
> > 
> > While this wouldn't be really obligatory, it would be meaningful for
> > trackers that need to ensure that fixes in packages have made it to
> > stable -- like the functions.sh use tracker.
> >   
> 
> The description of InVCS keyword in bugzilla is:
> InVCS 	Fix has been added to a VCS(either CVS, SVN, Git, ...)
> repository. Will be closed when fixes are applied to a stable level package.
> 
> A bug isn't resolved until it is fixed in a stable package (for packages
> ever in stable to begin with), but InVCS keyword can be used by
> developers to filter out the bugs for issues to work with. I oppose a
> change to that behavior, although I would like to see it being used more
> consistently as it seems quite a few developers are neglecting the
> stable tree.

How would that work for Portage? There 'InVCS' indicates that the fix
has landed in git (i.e. in -9999, not yet released).

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

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

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

[Rich Freeman]

On Fri, Jun 17, 2016 at 9:52 AM, Michał Górny <mgorny@gentoo.org> wrote:
> On Thu, 16 Jun 2016 15:14:44 +0200
> Kristian Fiskerstrand <k_f@gentoo.org> wrote:
>
>> On 06/16/2016 03:02 PM, Michał Górny wrote:
>> > Hello, everyone.
>> >
>>
>>
>>
>> >
>> > What I'd like to introduce instead is a new STABILIZED state. It would
>> > -- like VERIFIED now -- be only available for bugs already RESOLVED,
>> > and it could be used to signify that the fix has made it into stable.
>> >
>> > While this wouldn't be really obligatory, it would be meaningful for
>> > trackers that need to ensure that fixes in packages have made it to
>> > stable -- like the functions.sh use tracker.
>> >
>>
>> The description of InVCS keyword in bugzilla is:
>> InVCS         Fix has been added to a VCS(either CVS, SVN, Git, ...)
>> repository. Will be closed when fixes are applied to a stable level package.
>>
>> A bug isn't resolved until it is fixed in a stable package (for packages
>> ever in stable to begin with), but InVCS keyword can be used by
>> developers to filter out the bugs for issues to work with. I oppose a
>> change to that behavior, although I would like to see it being used more
>> consistently as it seems quite a few developers are neglecting the
>> stable tree.
>
> How would that work for Portage? There 'InVCS' indicates that the fix
> has landed in git (i.e. in -9999, not yet released).
>

That could actually be generalized.  I could see many types of bugs
where the issue is with upstream, and we might want to track the
progress as upstream implements a fix, releases it, and then it is
stabilized on Gentoo.  So, maybe we need another state to track in
upstream's VCS vs the Gentoo repo.

Another approach would be to distinguish between portage as a
Gentoo-hosted upstream, and portage as a package in the Gentoo repo.
The same could apply to any Gentoo-hosted project.


-- 
Rich

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

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 17/06/16 15:58, Rich Freeman wrote:
> That could actually be generalized.  I could see many types of
> bugs where the issue is with upstream, and we might want to track
> the progress as upstream implements a fix, releases it, and then it
> is stabilized on Gentoo.  So, maybe we need another state to track
> in upstream's VCS vs the Gentoo repo.
> 
> Another approach would be to distinguish between portage as a 
> Gentoo-hosted upstream, and portage as a package in the Gentoo
> repo. The same could apply to any Gentoo-hosted project.
I would be fine with either, but honestly this whole thing seems like
bikeshedding for the sake of bikeshedding. It's working fine as-is,
and I don't recall any complaints that we've been doing it differently
to the tree.
- -- 
Alexander
bernalex@gentoo.org
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJXZAJ5AAoJENQqWdRUGk8BXdsQAIvWgBxy/43BFRfVYk5Ah6ke
u0yosJvHJe+PWTPQj6YQNJDgmLwohNeyyrDkV4y6PCrObZWkiJgT34LATmJLThCY
C+/ZGuxxSjhYJkO3dU51rc6KCXdQ+Uw7Mvc/jxXzB27nuSA1nfKsw2MRfH6Snhdz
hGNYiXe8xry+G1t6BBC2BENrZyRdn/KL6T+0bmc0it6iCvfEWjjKSMmS1GUTPK6G
6cD7IOmWVJTl1o9fjM0Em78UlqU8LsyeZLSq+W63crRVhhv1ZzbXHWMG+jRq64dO
jmI/qnScC0EnhMg2GYxaiHlo/CRcfFQxvSdqCZC5Ll7bnE0ygYaeA1huhXKg2Qgq
ibwN8+1s7j/O50lOqFcVYb6GFvUrObA0Db/k1YcVNENsgr5krBQLRrWOiq5pBJ1g
ubFP1G6G5xT1wHmf9j3Cd4DKv2IdVP6u//x+TMhP4utcCbszNyH5tQ6mlPE6Z7i0
YRHXODCiRrdHDr6+TZRTq1/nH0wnhSi7yrlU8lbyMsTAXRsWEDPvc4Y+rvVk70Xn
OzGHJcMJzCleNcPd3j+9Oqcb2m/hJY0I+70/OnQwcVVUnEzqyM6FAsca0PlIPA8T
lEBZyMYtxewB2znMY4cbiLalVVeDBOYvQcS37ygjdxfChJTnZfMgPMM9ffGcXxZ9
7p2rOSvWrDR9i4RqCY6d
=vcMe
-----END PGP SIGNATURE-----

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2355 bytes --]

On Fri, 17 Jun 2016 09:58:52 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Fri, Jun 17, 2016 at 9:52 AM, Michał Górny <mgorny@gentoo.org> wrote:
> > On Thu, 16 Jun 2016 15:14:44 +0200
> > Kristian Fiskerstrand <k_f@gentoo.org> wrote:
> >  
> >> On 06/16/2016 03:02 PM, Michał Górny wrote:  
> >> > Hello, everyone.
> >> >  
> >>
> >>
> >>  
> >> >
> >> > What I'd like to introduce instead is a new STABILIZED state. It would
> >> > -- like VERIFIED now -- be only available for bugs already RESOLVED,
> >> > and it could be used to signify that the fix has made it into stable.
> >> >
> >> > While this wouldn't be really obligatory, it would be meaningful for
> >> > trackers that need to ensure that fixes in packages have made it to
> >> > stable -- like the functions.sh use tracker.
> >> >  
> >>
> >> The description of InVCS keyword in bugzilla is:
> >> InVCS         Fix has been added to a VCS(either CVS, SVN, Git, ...)
> >> repository. Will be closed when fixes are applied to a stable level package.
> >>
> >> A bug isn't resolved until it is fixed in a stable package (for packages
> >> ever in stable to begin with), but InVCS keyword can be used by
> >> developers to filter out the bugs for issues to work with. I oppose a
> >> change to that behavior, although I would like to see it being used more
> >> consistently as it seems quite a few developers are neglecting the
> >> stable tree.  
> >
> > How would that work for Portage? There 'InVCS' indicates that the fix
> > has landed in git (i.e. in -9999, not yet released).
> >  
> 
> That could actually be generalized.  I could see many types of bugs
> where the issue is with upstream, and we might want to track the
> progress as upstream implements a fix, releases it, and then it is
> stabilized on Gentoo.  So, maybe we need another state to track in
> upstream's VCS vs the Gentoo repo.
> 
> Another approach would be to distinguish between portage as a
> Gentoo-hosted upstream, and portage as a package in the Gentoo repo.
> The same could apply to any Gentoo-hosted project.

We also have the 'STABLE' keyword. However, we're getting to the point
where bug lists are already twice as wide as my monitor (since I had to
include keywords...).

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

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

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

[Kristian Fiskerstrand]

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

On 06/17/2016 03:58 PM, Rich Freeman wrote:
> On Fri, Jun 17, 2016 at 9:52 AM, Michał Górny <mgorny@gentoo.org> wrote:
>> On Thu, 16 Jun 2016 15:14:44 +0200
>> Kristian Fiskerstrand <k_f@gentoo.org> wrote:
>>
>>> On 06/16/2016 03:02 PM, Michał Górny wrote:
>>>> Hello, everyone.
>>>>
>>>
>>>
>>>
>>>>
>>>> What I'd like to introduce instead is a new STABILIZED state. It would
>>>> -- like VERIFIED now -- be only available for bugs already RESOLVED,
>>>> and it could be used to signify that the fix has made it into stable.
>>>>
>>>> While this wouldn't be really obligatory, it would be meaningful for
>>>> trackers that need to ensure that fixes in packages have made it to
>>>> stable -- like the functions.sh use tracker.
>>>>
>>>
>>> The description of InVCS keyword in bugzilla is:
>>> InVCS         Fix has been added to a VCS(either CVS, SVN, Git, ...)
>>> repository. Will be closed when fixes are applied to a stable level package.
>>>
>>> A bug isn't resolved until it is fixed in a stable package (for packages
>>> ever in stable to begin with), but InVCS keyword can be used by
>>> developers to filter out the bugs for issues to work with. I oppose a
>>> change to that behavior, although I would like to see it being used more
>>> consistently as it seems quite a few developers are neglecting the
>>> stable tree.
>>
>> How would that work for Portage? There 'InVCS' indicates that the fix
>> has landed in git (i.e. in -9999, not yet released).
>>
> 
> That could actually be generalized.  I could see many types of bugs
> where the issue is with upstream, and we might want to track the
> progress as upstream implements a fix, releases it, and then it is
> stabilized on Gentoo.  So, maybe we need another state to track in
> upstream's VCS vs the Gentoo repo.

For a great deal of this we have UPSTREAM keyword, and also combination
with PATCH keyword if we've submitted an own patch.

> 
> Another approach would be to distinguish between portage as a
> Gentoo-hosted upstream, and portage as a package in the Gentoo repo.
> The same could apply to any Gentoo-hosted project.

Makes sense

-- 
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 --]

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

[Rich Freeman]

On Fri, Jun 17, 2016 at 12:00 PM, Kristian Fiskerstrand <k_f@gentoo.org> wrote:
> On 06/17/2016 03:58 PM, Rich Freeman wrote:
>>
>> That could actually be generalized.  I could see many types of bugs
>> where the issue is with upstream, and we might want to track the
>> progress as upstream implements a fix, releases it, and then it is
>> stabilized on Gentoo.  So, maybe we need another state to track in
>> upstream's VCS vs the Gentoo repo.
>
> For a great deal of this we have UPSTREAM keyword, and also combination
> with PATCH keyword if we've submitted an own patch.

Usually we mean UPSTEAM to mean that the issue is an upstream issue,
and should be pursued there.  Usually we don't use it to mean that the
issue IS resolved upstream but we're waiting for a release/etc.  I'm
not sure how important the distinction is in practice.  The portage
team could of course use it differently.


-- 
Rich

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

[Kristian Fiskerstrand]

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

On 06/17/2016 06:41 PM, Rich Freeman wrote:
> On Fri, Jun 17, 2016 at 12:00 PM, Kristian Fiskerstrand <k_f@gentoo.org> wrote:
>> On 06/17/2016 03:58 PM, Rich Freeman wrote:
>>>
>>> That could actually be generalized.  I could see many types of bugs
>>> where the issue is with upstream, and we might want to track the
>>> progress as upstream implements a fix, releases it, and then it is
>>> stabilized on Gentoo.  So, maybe we need another state to track in
>>> upstream's VCS vs the Gentoo repo.
>>
>> For a great deal of this we have UPSTREAM keyword, and also combination
>> with PATCH keyword if we've submitted an own patch.
> 
> Usually we mean UPSTEAM to mean that the issue is an upstream issue,
> and should be pursued there.  Usually we don't use it to mean that the
> issue IS resolved upstream but we're waiting for a release/etc.  I'm

Well, the issue is still upstream in that case, so I don't see that
necessarily being different, we're still waiting for a release upstream
to make a new downstream ebuild and stabilize it, so it fits with UPSTREAM

> not sure how important the distinction is in practice.  The portage
> team could of course use it differently.

Yeah, I'm talking ebuilds here, not portage and similar bugs, I think
your point of having own keyword for portage and the likes makes sense
to distinguish it.


-- 
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 --]

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

[Brian Dolbec]

[-- Attachment #1: Type: text/plain, Size: 2382 bytes --]

On Fri, 17 Jun 2016 18:46:16 +0200
Kristian Fiskerstrand <k_f@gentoo.org> wrote:

> On 06/17/2016 06:41 PM, Rich Freeman wrote:
> > On Fri, Jun 17, 2016 at 12:00 PM, Kristian Fiskerstrand
> > <k_f@gentoo.org> wrote:  
> >> On 06/17/2016 03:58 PM, Rich Freeman wrote:  
> >>>
> >>> That could actually be generalized.  I could see many types of
> >>> bugs where the issue is with upstream, and we might want to track
> >>> the progress as upstream implements a fix, releases it, and then
> >>> it is stabilized on Gentoo.  So, maybe we need another state to
> >>> track in upstream's VCS vs the Gentoo repo.  
> >>
> >> For a great deal of this we have UPSTREAM keyword, and also
> >> combination with PATCH keyword if we've submitted an own patch.  
> > 
> > Usually we mean UPSTEAM to mean that the issue is an upstream issue,
> > and should be pursued there.  Usually we don't use it to mean that
> > the issue IS resolved upstream but we're waiting for a
> > release/etc.  I'm  
> 
> Well, the issue is still upstream in that case, so I don't see that
> necessarily being different, we're still waiting for a release
> upstream to make a new downstream ebuild and stabilize it, so it fits
> with UPSTREAM
> 
> > not sure how important the distinction is in practice.  The portage
> > team could of course use it differently.  
> 
> Yeah, I'm talking ebuilds here, not portage and similar bugs, I think
> your point of having own keyword for portage and the likes makes sense
> to distinguish it.
> 
> 

Then everyone PLEASE stop referring to the Gentoo ebuild tree as
portage.  Reserve portage for the upstream PACKAGE MANAGER.


Further, I have always treated bugs about portage code like any
other upstream.  Only difference being that the portage upstream bug
system is the same bugzilla used for the Gentoo ebuild tree.
So, there will be some differences in how bugs are treated.
When we as upstream commit patches for bugs we tag them as InVCS and
close them when they are in a release.  We have not kept them open
until that release has been stabilized unless we've missed closing it
or been distracted and forgotten to clean them up.

If you want to track that at the ebuild level, you could do that, but
would need to identify it's tracker in a clear way to distinguish it
from code bugs.
-- 
Brian Dolbec <dolsen>


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

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

[Kristian Fiskerstrand]

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

On 06/17/2016 07:05 PM, Brian Dolbec wrote:
> On Fri, 17 Jun 2016 18:46:16 +0200
> Kristian Fiskerstrand <k_f@gentoo.org> wrote:
> 
>> On 06/17/2016 06:41 PM, Rich Freeman wrote:
>>> On Fri, Jun 17, 2016 at 12:00 PM, Kristian Fiskerstrand
>>> <k_f@gentoo.org> wrote:  
>>>> On 06/17/2016 03:58 PM, Rich Freeman wrote:  
>>>>>
>>>>> That could actually be generalized.  I could see many types of
>>>>> bugs where the issue is with upstream, and we might want to track
>>>>> the progress as upstream implements a fix, releases it, and then
>>>>> it is stabilized on Gentoo.  So, maybe we need another state to
>>>>> track in upstream's VCS vs the Gentoo repo.  
>>>>
>>>> For a great deal of this we have UPSTREAM keyword, and also
>>>> combination with PATCH keyword if we've submitted an own patch.  
>>>
>>> Usually we mean UPSTEAM to mean that the issue is an upstream issue,
>>> and should be pursued there.  Usually we don't use it to mean that
>>> the issue IS resolved upstream but we're waiting for a
>>> release/etc.  I'm  
>>
>> Well, the issue is still upstream in that case, so I don't see that
>> necessarily being different, we're still waiting for a release
>> upstream to make a new downstream ebuild and stabilize it, so it fits
>> with UPSTREAM
>>
>>> not sure how important the distinction is in practice.  The portage
>>> team could of course use it differently.  
>>
>> Yeah, I'm talking ebuilds here, not portage and similar bugs, I think
>> your point of having own keyword for portage and the likes makes sense
>> to distinguish it.
>>
>>
> 
> Then everyone PLEASE stop referring to the Gentoo ebuild tree as
> portage.  Reserve portage for the upstream PACKAGE MANAGER.

indeed

> 
> 
> Further, I have always treated bugs about portage code like any
> other upstream.  Only difference being that the portage upstream bug
> system is the same bugzilla used for the Gentoo ebuild tree.
> So, there will be some differences in how bugs are treated.
> When we as upstream commit patches for bugs we tag them as InVCS and
> close them when they are in a release.  We have not kept them open
> until that release has been stabilized unless we've missed closing it
> or been distracted and forgotten to clean them up.
> 
> If you want to track that at the ebuild level, you could do that, but
> would need to identify it's tracker in a clear way to distinguish it
> from code bugs.
> 

It might not be much of an issue as long as we use proper categories for
own hosted repos, then InVCS function is overloaded and means different
things for the ebuild bugs and the upstream package bugs without any
conflict. Would potentially result in some duplication of material bugs
though hence that might be easier by adding a new keyword with explicit
separate meaning for things.

-- 
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 --]

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

[Rich Freeman]

On Fri, Jun 17, 2016 at 1:26 PM, Kristian Fiskerstrand <k_f@gentoo.org> wrote:
> On 06/17/2016 07:05 PM, Brian Dolbec wrote:
>>
>> Then everyone PLEASE stop referring to the Gentoo ebuild tree as
>> portage.  Reserve portage for the upstream PACKAGE MANAGER.
>
> indeed
>

Agree, though this wasn't the sense I meant it in (in case there was
any confusion).

1. There is the Gentoo Repo (which I always try to describe using those words).

2. Then there is the sys-apps/portage package in the Gentoo repo.

3.  And then there is the portage upstream that occasionally makes
releases that end up as #2.

It is between 2-3 that we need to distinguish here.

I agree with the suggestion that context is sufficient already.

-- 
Rich

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

[Raymond Jennings]

[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]

I'd like to chime in if I may.  I've found "VERIFIED" to be needless.
Especially in cases where I have logs or whatnot, having to prove the bug
is there is tedious.

Shouldn't the existence of the report be evidence enough?

On Fri, Jun 17, 2016 at 10:39 AM, Rich Freeman <rich0@gentoo.org> wrote:

> On Fri, Jun 17, 2016 at 1:26 PM, Kristian Fiskerstrand <k_f@gentoo.org>
> wrote:
> > On 06/17/2016 07:05 PM, Brian Dolbec wrote:
> >>
> >> Then everyone PLEASE stop referring to the Gentoo ebuild tree as
> >> portage.  Reserve portage for the upstream PACKAGE MANAGER.
> >
> > indeed
> >
>
> Agree, though this wasn't the sense I meant it in (in case there was
> any confusion).
>
> 1. There is the Gentoo Repo (which I always try to describe using those
> words).
>
> 2. Then there is the sys-apps/portage package in the Gentoo repo.
>
> 3.  And then there is the portage upstream that occasionally makes
> releases that end up as #2.
>
> It is between 2-3 that we need to distinguish here.
>
> I agree with the suggestion that context is sufficient already.
>
> --
> Rich
>
>

[-- Attachment #2: Type: text/html, Size: 1678 bytes --]

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

[Davide Pesavento]

On Thu, Jun 16, 2016 at 3:02 PM, Michał Górny <mgorny@gentoo.org> wrote:
> Hello, everyone.
>
> Here's the third bugs.g.o redesign RFC.
>
> This time it's about closed bugs. Right now we have two states for
> them: RESOLVED and VERIFIED.
>
> RESOLVED is the usual state that the developers use when they close
> a bug. It's also the only state that could be directly transferred from
> other states.
>
> VERIFIED is used scarcely, and not really consistently. It can only be
> used on RESOLVED bugs, and sometimes users use it to confirm that
> the bug is resolved.
>
> To be honest, I don't really see the need for VERIFIED state. Since
> it's used scarcely, it can't be really relied upon. Some users use it
> completely incorrectly (e.g. when the bug should be reopened instead).

Agreed. However I don't see a strong reason to remove it, unless its
removal simplifies the introduction of STABILIZED. If it's useful to
some people, let them use it.

>
> What I'd like to introduce instead is a new STABILIZED state. It would
> -- like VERIFIED now -- be only available for bugs already RESOLVED,
> and it could be used to signify that the fix has made it into stable.
>
> While this wouldn't be really obligatory, it would be meaningful for
> trackers that need to ensure that fixes in packages have made it to
> stable -- like the functions.sh use tracker.

Makes sense, although, as you said yourself, if it's not used
consistently it cannot be relied upon. Besides, we already have a
mechanism for expressing this, we make the stable request bug block
the tracker.

Thanks,
Davide

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

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1424 bytes --]

On Thu, 16 Jun 2016 15:02:13 +0200 Michał Górny wrote:
> Hello, everyone.
> 
> Here's the third bugs.g.o redesign RFC.
> 
> This time it's about closed bugs. Right now we have two states for
> them: RESOLVED and VERIFIED.
> 
> RESOLVED is the usual state that the developers use when they close
> a bug. It's also the only state that could be directly transferred from
> other states.
> 
> VERIFIED is used scarcely, and not really consistently. It can only be
> used on RESOLVED bugs, and sometimes users use it to confirm that
> the bug is resolved.
> 
> To be honest, I don't really see the need for VERIFIED state. Since
> it's used scarcely, it can't be really relied upon. Some users use it
> completely incorrectly (e.g. when the bug should be reopened instead).

+1 Burn it with fire :)
 
> What I'd like to introduce instead is a new STABILIZED state. It would
> -- like VERIFIED now -- be only available for bugs already RESOLVED,
> and it could be used to signify that the fix has made it into stable.
> 
> While this wouldn't be really obligatory, it would be meaningful for
> trackers that need to ensure that fixes in packages have made it to
> stable -- like the functions.sh use tracker.

Wouldn't this bug create even more burden for stabilization process?
Each fix will eventually go into stable when newer version will get
stabilized.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

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

[Kent Fredric]

On 17 June 2016 at 01:02, Michał Górny <mgorny@gentoo.org> wrote:
> VERIFIED is used scarcely, and not really consistently. It can only be
> used on RESOLVED bugs, and sometimes users use it to confirm that
> the bug is resolved.


Its also worth pointing out VERIFIED status annoyingly restricts a
package, and so any incorrect usage makes things worse.

Because you can't move an issue from VERIFIED back to CONFIRMED.

You instead have to move it to either RESOLVED or UNCONFIRMED, despite
neither of those being what you want.

( And that of course produces more bugspam )



-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

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

[Andreas K. Huettel]

> 
> What I'd like to introduce instead is a new STABILIZED state. It would
> -- like VERIFIED now -- be only available for bugs already RESOLVED,
> and it could be used to signify that the fix has made it into stable.
> 

Right now I dont think we agree what "RESOLVED" means. 

* Some people close bugs when there is an ~arch version that fixes them. 
* Some people wait until there is a stable version that fixes them. 

How about introducing a state that explicitly means "resolved but needs 
stabilization"? "NEEDSTABLE" or similar, with same resolutions as "RESOLVED"?

So, for a stable package a bug would go 
CONFIRMED -> NEEDSTABLE FIXED -> RESOLVED FIXED

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/

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

[Kristian Fiskerstrand]

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

On 06/16/2016 11:57 PM, Andreas K. Huettel wrote:
> How about introducing a state that explicitly means "resolved but needs 
> stabilization"? 

We already have InVCS keyword for this

-- 
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 --]

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

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

What we have been doing in Portage so far is that when we fix it in
git, we put IN_PROGRESS + InVCS, and write a comment that links to the
commit on gitweb. Then when we actually release Portage, we consider
it to be fixed, and make it RESOLVED.

I would not want to tie our choosing RESOLVED to be tied to whether
there is a stabilised package in the tree or not, because there are
other Portage users than Gentoo. But I would not oppose such an
enforcement too strongly at this time.

We don't really need anything presently in Bugzilla beyond
UNCONFIRMED/CONFIRMED/IN_PROGRESS/RESOLVED, as well as the keywords
InVCS, PATCH, STABLE, STABLEREQ, and Tracker.


Unrelated to your trimming, Michał, a field for the relevant gitweb
link would be very useful to us. Is there any chance we could get that
as a result of this redesign?
- -- 
Alexander
bernalex@gentoo.org
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJXY6iyAAoJENQqWdRUGk8BUTkP/2b2CNd1NjK3LeD7CJis192F
uDgR1zb4RGnOzgwF7ngSnkELrTioiUcTpshkhKQvocNjwgqCRJNeM8W5LWwc3AaR
KfR1LEw0Sj/XoTLW9xkm00tPnecFqDOvOiA+Qo89CYIFn3C/xQFGfddGHFj99sLO
JXSiZ7ujEgojOwv1HKJzHQDQEtGmZMXiyPdm37VW16QhacbhlwWA8pKCgdibDUKN
iT308W4H1zFQwTS9T14BDQQwFd2gQbyFf6afN3mQGrT21uJ7hM3gwHpSrT/Otwa0
3MKvkYFzPmny47Vj6s2nLpsm+usOzE0JCflUPzC07Mm0TPnoM1ts6hBZlAg/w3KK
kRCRIZEEvuHNYhxmGdeqGOAsWSR/M7287PHpYSIN5TMdjijskf7I06cIZ/OCEb4m
cTSO/9GyZSXLlxp0BS4VHVvEVKyvbhVP0ENxBU75BhKCkF9O9ygVGXCnwWFMQQpx
m/TSYq7hd1fU3pqvi3CSY0ps6jQCcJ9LqvBZ5negD466wWYpKgkTvbaX/tJD56rV
/ROG4CA3SCqolHpi/oDZka94gl5QhHNEs7fk430jKYsuXeMxVutyJcPdBldhL5GP
DVbCOdoS4LSJvMZLRGP/wdkz716DvzMyLn4joGVO9yESBFgyr2fsLUa3Ah+zir48
8bPXgPRu+XV6OSjXCEfu
=hDfl
-----END PGP SIGNATURE-----

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1292 bytes --]

On Fri, 17 Jun 2016 09:37:22 +0200
Alexander Berntsen <bernalex@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> What we have been doing in Portage so far is that when we fix it in
> git, we put IN_PROGRESS + InVCS, and write a comment that links to the
> commit on gitweb. Then when we actually release Portage, we consider
> it to be fixed, and make it RESOLVED.
> 
> I would not want to tie our choosing RESOLVED to be tied to whether
> there is a stabilised package in the tree or not, because there are
> other Portage users than Gentoo. But I would not oppose such an
> enforcement too strongly at this time.
> 
> We don't really need anything presently in Bugzilla beyond
> UNCONFIRMED/CONFIRMED/IN_PROGRESS/RESOLVED, as well as the keywords
> InVCS, PATCH, STABLE, STABLEREQ, and Tracker.
> 
> 
> Unrelated to your trimming, Michał, a field for the relevant gitweb
> link would be very useful to us. Is there any chance we could get that
> as a result of this redesign?

Bugzilla supports adding any number of extra fields. However, isn't
the URL field sufficient for this? I'd rather not increase the size of
the form if there's not a big need for that.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

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

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

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 17/06/16 09:50, Michał Górny wrote:
> However, isn't the URL field sufficient for this?
This is useful in many cases for describing the bug and similar things
when the bug is being reported. Is it possible to have multiple URLs
sensibly in this field? If not, then I would be reluctant to overwrite
it.

Ideally a gitweb field would take a repository (*ideally* ideally it
would even default to Portage on Portage bugs) and a commit (a hash,
or a reference like HEAD), and optionally a branch. That way I would
not even have to deal with gitweb.
- -- 
Alexander
bernalex@gentoo.org
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJXY6z0AAoJENQqWdRUGk8BZeEQAKmieGHzdSLm8R1RILhKwSVR
FAxe1svyB2Ed69WgOj+XYB5/aI1TZOV1WtOmrQ9GJVSjvyxHiLqDG8leYNr2wkwX
Q5Z3W/BpXLB2kUPVx6gab4873bpyFF95KmUhakgTEDd4oR9i5tuyZajORev77J4Z
3MX4bvMovRFva9a4sKIhGBCdO6X0fT3Y3NTH+qwwycLH58eKJS4hFbU0pbd90agO
hLrptzt+7h365Lu2A71nk4xR0AG/5W4f/N9PodvMgu33vKYmE54DEBGji3/rDp/d
+ftjo41t8eSQknuJnJhr7LTylfBpPhE/zyjtkzYRvsS8Y9PtQ3I1PTXBZ7+S3jBd
TVThD//urxyLJi80ZoSOslrDMa5Aq/Uct4dlv9bD6QaO15piCf1ia0Fs+FIU77po
y+eBeNYMiLakWq5oBrNYBXdoOsgGA69sUxz/XmEIfJ7Jxoy5ODjLsIdr/lokXRBG
B0H664+ZVr+H1r0FlE0rgT7HBTUWTwBa+aPlup/HxxyJa9U0/Hnk6K8Jrj0j6QmX
bm6A1Ec8m0SPo0T+x4IlCgHPex4YrYsxy9eYhUZKDmSyGMggggEYeKO9g3DhH/SN
/ej/grmsNDsh4RprKiFhWR77IT7iFWz9dbBcrnlzNk4BrwVZxdB0f1DzwcN6kffz
h4PE2O9tLGZ8dpBoGc1y
=9XVn
-----END PGP SIGNATURE-----

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

[Kristian Fiskerstrand]

[No OpenPGP signature atm, smartcard not cooperating, this is really bad
form :|]

On 06/17/2016 09:50 AM, Michał Górny wrote:
> 
> Bugzilla supports adding any number of extra fields. However, isn't
> the URL field sufficient for this? I'd rather not increase the size of
> the form if there's not a big need for that.
> 

I can imagine situations where URL field is used for bug description
itself, and as such isn't available for use for commit message. I'd
imagine this to be more a "see also" style field

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

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

[Rich Freeman]

On Fri, Jun 17, 2016 at 3:37 AM, Alexander Berntsen <bernalex@gentoo.org> wrote:
>
> I would not want to tie our choosing RESOLVED to be tied to whether
> there is a stabilised package in the tree or not, because there are
> other Portage users than Gentoo. But I would not oppose such an
> enforcement too strongly at this time.
>

There is clearly more than one way to approach this.  I think the key
is to get everybody to do it the same way.

I do agree that it is overkill to track EVERY bug through to stable.
However, I can see the value in tracking some bugs through to stable.
The question is how do we tell which are which, and ensure the ones
that need to be tracked are actually updated when the package is
stabilized?

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.


-- 
Rich

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

[Kristian Fiskerstrand]

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

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.

-- 
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 --]

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

[Rich Freeman]

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?

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

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

[Kristian Fiskerstrand]

[-- 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 --]

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

[Kristian Fiskerstrand]

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

On 06/17/2016 03:02 PM, Kristian Fiskerstrand wrote:

>> 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

Ehrm, weird brain/keyboard connectivity there; those that are resolved
fixed...




-- 
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 --]

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

[Rich Freeman]

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

That would of course work.  The question is whether we're willing to
live with that.  It would mean that most bugs would stay open a lot
longer than they do today.

Also, in the case of STABLEREQs would we treat them more like security
bugs - the last arch would just post a comment that all archs are
stable and un-CC themselves, but leave the bug open to remind the
maintainer to go check all open bugs to see if any should be marked
fixed?


-- 
Rich

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

[Kristian Fiskerstrand]

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

On 06/17/2016 03:48 PM, Rich Freeman wrote:
> On Fri, Jun 17, 2016 at 9:02 AM, Kristian Fiskerstrand <k_f@gentoo.org> wrote:
>> On 06/17/2016 02:18 PM, Rich Freeman wrote:
>>
>>> 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
>>
> 
> That would of course work.  The question is whether we're willing to
> live with that.  It would mean that most bugs would stay open a lot
> longer than they do today.

They would stay open, but can be filtered out by developers in the saved
searches based on keywords so doesn't show up in the worklist/assigned
search etc

> 
> Also, in the case of STABLEREQs would we treat them more like security
> bugs - the last arch would just post a comment that all archs are
> stable and un-CC themselves, but leave the bug open to remind the
> maintainer to go check all open bugs to see if any should be marked
> fixed?
> 

Sounds sensible



-- 
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 --]

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

[Rich Freeman]

On Fri, Jun 17, 2016 at 11:33 AM, Kristian Fiskerstrand <k_f@gentoo.org> wrote:
> On 06/17/2016 03:48 PM, Rich Freeman wrote:
>>
>> Also, in the case of STABLEREQs would we treat them more like security
>> bugs - the last arch would just post a comment that all archs are
>> stable and un-CC themselves, but leave the bug open to remind the
>> maintainer to go check all open bugs to see if any should be marked
>> fixed?
>>
>
> Sounds sensible
>

If we had a field to track a fixed-in version I wonder how hard it
would be to detect all bugs that are fixed in a given stabilization.
Maybe list them as Blocks dependencies if that could be automated on a
stablereq?  That might make it easy for the last arch or the
maintainer to just close them all out.

-- 
Rich

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

[Andreas K. Huettel]

> 
> To be honest, I don't really see the need for VERIFIED state. Since
> it's used scarcely, it can't be really relied upon. Some users use it
> completely incorrectly (e.g. when the bug should be reopened instead).
> 

Indeed. Kill VERIFIED with fire.


-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1108 bytes --]

On Thu, 16 Jun 2016 15:02:13 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> Hello, everyone.
> 
> Here's the third bugs.g.o redesign RFC.
> 
> This time it's about closed bugs. Right now we have two states for
> them: RESOLVED and VERIFIED.
> 
> RESOLVED is the usual state that the developers use when they close
> a bug. It's also the only state that could be directly transferred from
> other states.
> 
> VERIFIED is used scarcely, and not really consistently. It can only be
> used on RESOLVED bugs, and sometimes users use it to confirm that
> the bug is resolved.
> 
> To be honest, I don't really see the need for VERIFIED state. Since
> it's used scarcely, it can't be really relied upon. Some users use it
> completely incorrectly (e.g. when the bug should be reopened instead).

Since nobody seemed to mind, I've disabled VERIFIED now. I've also
loosened the workflow so that all (old) VERIFIED bugs can be reopened
directly.

For stabilization thing, I'm going to wait for more replies/ideas.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

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

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

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I *seriously* object to a RFC that affects so many people lasting
*less than 24h*.

- -- 
Alexander
bernalex@gentoo.org
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJXY77iAAoJENQqWdRUGk8BCKIP/3ZGVOQXU3Jfcn1lOd19zC/3
657F3jFI1nNI+jiouKymMFE5vI0tLKw1a/oSq2h4Q+eH8hW/Lf0hIpYsonmUNKRg
2WKHiQS/N0Ykp0N3xJJkQ8f3DVaDbDwBPnHtXBgcHUIfN4hI/rlDc9jFhV8CZVO2
JzAsi/bInemThXCYpy7+ldAKBJ4e3V8nEFy/GTsEKvhn8rm63P9rarNHr3bnkpUh
JXm6FEVVkn3nDiXxmRQfVALFYwIqkcwhx46uta/Dsjss31yGtluXtjKWq9Vjrkto
zL6SLXzonIcDbFRQRsg5uJ23kycSKqzM/HFGAfZL32oaNsbfh7TXUntnFBy72Hug
yxoeygGRJGasqmw/9a0oxLNhwu7D+b/cTE4OYADyt4iH5X/maoOnWlI35F95cG0A
FjSfuUR/i+tvr3+MveMniLsqafO2P/xBrH+J+9NH8uVqtYBoEJYQVwbZcJfyUEQd
P1ke4kNncT4GBCCEniphcIeK+/QjqvDRieTvWa1+ySqlC5eLRhSTsj7gyCxqTvXG
4ojoy06oO/CVms7mTPbyy8h8B2ut6OWpOaLyMBZNVy1pWiteGv3KewsTSE70itbU
siAylQ17erouzUI2QmiXGYoIoxoVqQHbN2Nu3ZeqzvK62KrufbBA2alOv1dQ96PT
FWC9R8F2yEtjzIMKAkxI
=H61A
-----END PGP SIGNATURE-----