Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Michał Górny]

On Thu, 16 Jun 2016 10:23:39 -0400
Mike Gilbert  wrote:

> On Thu, Jun 16, 2016 at 9:52 AM, Joshua Kinard  wrote:
> > It'd be nice if, when replying in a comment, a flag
> > could be made available to automatically to state that "I've encountered 
> > this
> > issue, too", and once 2, 3, or 4 of those are logged, Bugzilla automatically
> > changes the state to CONFIRMED, but doesn't bugspam on this specific state 
> > change.  
> 
> That sounds like the Voting extension, which we already have enabled.
> Not sure what the threshold is set to, however.
> 
> https://www.bugzilla.org/docs/4.0/en/html/voting.html

It's set to 0 (i.e. disabled).

-- 
Best regards,
Michał Górny



pgp2Cpk3ZjnYc.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Kent Fredric]

On 17 June 2016 at 06:05, Marc Schiffbauer  wrote:
> How about "ON HOLD: Need Info" instead?


"STALLED" is better for me than "ON HOLD".

But I can't really see much value in such a breakdown unless we can
find at *least* 2 sub-categories of "STALLED"


-- 
Kent

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

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I would like to keep CONFIRMED as I use it and find it useful.

I also think that renaming UNCONFIRMED to OPEN is silly and
misleading, since any non-RESOLVED bug is indeed an open bug. I don't
have anything against renaming it to NEW, although I think that would
be changing things for the sake of changing things.

Lastly, I definitely think Michał should fix his email client
configuration. ;-)
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXY6r3AAoJENQqWdRUGk8BieYP/0GpjYcjSNQK33K1TgUqVQgw
8GHHCgyBBiYWn/mfGbn+mzSCeC7esf74R73g8nmfLtJV5KaaLS3J8h8q1IywJ2M9
XLbZGxjSlhjGaXMknm/XOhBpTdSD0ybMpmwLVesGiJ3cRHqhLoj3xN7xbb3LfngV
DA54ZiY4iO2A+n4YzDqkoMhKZFj16IW557bW4d2W7GJKhRur6vdoZPXOOd8yn7eF
mwbd65XKj4k9nePb79sGQ3bkP5DY73mGHv+vEpuAQQZ+q4WbZUxvobLXZqwUrjWY
XnmhdfI8oqPfkmJ2jXpKkQjXiF0wp/tPgfmoWM/yXSwx/+LjDqrCrMxWL0HYSlDF
2s348y9e+ioi1z8/ghkE2554pQ/hseoYcu11Tbpwmvoc9puhpt4pwaebDRRfOJd+
MDWaAq35zwlYcrh93TeBEglIfLIorFbM7uuDD+Q1DDeKukFtusQWWbdG3rKA4riA
cW6QJbWEI7Apk7R23x1+vKELxqAcUuUeZ1mPi/12g0qE9RuNpx5VLjC8JjZP2bEM
yFFtxzCq9VOpFlzLbaT4HLyiXAcKF3uxLffmZ35/GmpTfKYWBeNt/iiooHqNdMVn
jLXGK1i4/UdHlb9rBLIsRrtrg5vJaNTPdox5DVWKMf6ukNPbCbV8VFrkd7AnuAAl
x1ZDjd4tOPK7rkccGDSk
=0brl
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Marc Schiffbauer]

* Kent Fredric schrieb am 16.06.16 um 16:05 Uhr:
> On 17 June 2016 at 01:52, Joshua Kinard  wrote:
> > because
> > sometimes, issues can get reported that are really obscure and, for example,
> > tied to a particular hardware configuration, thus cannot be easily and
> > independently confirmed
> 
> 
> Isn't that why "RESOLVED: Need Info" exists?

For me "RESOLVED" and "Need Info" does not belong together, so I find 
this state superfluous...

How about "ON HOLD: Need Info" instead?


-- 
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
 6E9E CA3E 7BF6 7F97 9BE5


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Michał Górny]

On Thu, 16 Jun 2016 23:23:06 +0300
Andrew Savchenko  wrote:

> On Thu, 16 Jun 2016 22:10:40 +0200 Michał Górny wrote:
> > On Thu, 16 Jun 2016 20:40:39 +0200
> > Fabian Groffen  wrote:
> >   
> > > On 16-06-2016 19:37:55 +0200, Michał Górny wrote:  
> > > > On Thu, 16 Jun 2016 18:52:32 +0200
> > > > Fabian Groffen  wrote:
> > > > 
> > > > > On 16-06-2016 16:37:10 +0200, Michał Górny wrote:
> > > > > > > P.S. Please don't CC me when replying to my e-mails on the list,
> > > > > > > since I'm already subscribed to the list.  
> > > > > > 
> > > > > > Please don't expect others to keep blacklists of people who can't
> > > > > > handle their mail properly, or to generally harm others and ignore 
> > > > > > good
> > > > > > practices because you can't handle your mail.  
> > > > > 
> > > > > You mean ignoring the Reply-To header is "good practice"?
> > > > 
> > > > It's not being ignored, as you can see by the occurrence of the mailing
> > > > list in CC.
> > > 
> > > From RFC 5322:
> > > 
> > > When the "Reply-To:" field is present, it indicates the address(es) to
> > > which the author of the message suggests that replies be sent.  In the
> > > absence of the "Reply-To:" field, replies SHOULD by default be sent to
> > > the mailbox(es) specified in the "From:" field unless otherwise
> > > specified by the person composing the reply.
> > > 
> > > In other words, you sent it to me, while I requested you to send it to
> > > the list.  
> > 
> > 'Suggests'. But if you insist, file a bug and stop bothering me. I'm
> > not maintaining nor developing any mail client.  
> 
> Claws mail definitely allows proper replies; just grep for
> X-Mailer header containing "Claws Mail" in this list and see how
> replies are made.
> 
> It looks like that problem is in how client is configured. That's
> why we are borthering you :)

If by 'proper replies', you mean not using 'reply all', then it's
a serious problem with the people using them. Anyway, your offtopic is
over on my end. If you have any more problems, please bother comrel.

-- 
Best regards,
Michał Górny



pgpxfpieA7O1t.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Andrew Savchenko]

On Thu, 16 Jun 2016 22:10:40 +0200 Michał Górny wrote:
> On Thu, 16 Jun 2016 20:40:39 +0200
> Fabian Groffen  wrote:
> 
> > On 16-06-2016 19:37:55 +0200, Michał Górny wrote:
> > > On Thu, 16 Jun 2016 18:52:32 +0200
> > > Fabian Groffen  wrote:
> > >   
> > > > On 16-06-2016 16:37:10 +0200, Michał Górny wrote:  
> > > > > > P.S. Please don't CC me when replying to my e-mails on the list,
> > > > > > since I'm already subscribed to the list.
> > > > > 
> > > > > Please don't expect others to keep blacklists of people who can't
> > > > > handle their mail properly, or to generally harm others and ignore 
> > > > > good
> > > > > practices because you can't handle your mail.
> > > > 
> > > > You mean ignoring the Reply-To header is "good practice"?  
> > > 
> > > It's not being ignored, as you can see by the occurrence of the mailing
> > > list in CC.  
> > 
> > From RFC 5322:
> > 
> > When the "Reply-To:" field is present, it indicates the address(es) to
> > which the author of the message suggests that replies be sent.  In the
> > absence of the "Reply-To:" field, replies SHOULD by default be sent to
> > the mailbox(es) specified in the "From:" field unless otherwise
> > specified by the person composing the reply.
> > 
> > In other words, you sent it to me, while I requested you to send it to
> > the list.
> 
> 'Suggests'. But if you insist, file a bug and stop bothering me. I'm
> not maintaining nor developing any mail client.

Claws mail definitely allows proper replies; just grep for
X-Mailer header containing "Claws Mail" in this list and see how
replies are made.

It looks like that problem is in how client is configured. That's
why we are borthering you :)

Best regards,
Andrew Savchenko


pgpj6frn0Kxw9.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Michał Górny]

On Thu, 16 Jun 2016 20:40:39 +0200
Fabian Groffen  wrote:

> On 16-06-2016 19:37:55 +0200, Michał Górny wrote:
> > On Thu, 16 Jun 2016 18:52:32 +0200
> > Fabian Groffen  wrote:
> >   
> > > On 16-06-2016 16:37:10 +0200, Michał Górny wrote:  
> > > > > P.S. Please don't CC me when replying to my e-mails on the list,
> > > > > since I'm already subscribed to the list.
> > > > 
> > > > Please don't expect others to keep blacklists of people who can't
> > > > handle their mail properly, or to generally harm others and ignore good
> > > > practices because you can't handle your mail.
> > > 
> > > You mean ignoring the Reply-To header is "good practice"?  
> > 
> > It's not being ignored, as you can see by the occurrence of the mailing
> > list in CC.  
> 
> From RFC 5322:
> 
> When the "Reply-To:" field is present, it indicates the address(es) to
> which the author of the message suggests that replies be sent.  In the
> absence of the "Reply-To:" field, replies SHOULD by default be sent to
> the mailbox(es) specified in the "From:" field unless otherwise
> specified by the person composing the reply.
> 
> In other words, you sent it to me, while I requested you to send it to
> the list.

'Suggests'. But if you insist, file a bug and stop bothering me. I'm
not maintaining nor developing any mail client.

-- 
Best regards,
Michał Górny



pgpymVmqeQkMO.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Fabian Groffen]

On 16-06-2016 19:37:55 +0200, Michał Górny wrote:
> On Thu, 16 Jun 2016 18:52:32 +0200
> Fabian Groffen  wrote:
> 
> > On 16-06-2016 16:37:10 +0200, Michał Górny wrote:
> > > > P.S. Please don't CC me when replying to my e-mails on the list,
> > > > since I'm already subscribed to the list.  
> > > 
> > > Please don't expect others to keep blacklists of people who can't
> > > handle their mail properly, or to generally harm others and ignore good
> > > practices because you can't handle your mail.  
> > 
> > You mean ignoring the Reply-To header is "good practice"?
> 
> It's not being ignored, as you can see by the occurrence of the mailing
> list in CC.

From RFC 5322:

When the "Reply-To:" field is present, it indicates the address(es) to
which the author of the message suggests that replies be sent.  In the
absence of the "Reply-To:" field, replies SHOULD by default be sent to
the mailbox(es) specified in the "From:" field unless otherwise
specified by the person composing the reply.

In other words, you sent it to me, while I requested you to send it to
the list.


-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Michał Górny]

On Thu, 16 Jun 2016 18:52:32 +0200
Fabian Groffen  wrote:

> On 16-06-2016 16:37:10 +0200, Michał Górny wrote:
> > > P.S. Please don't CC me when replying to my e-mails on the list,
> > > since I'm already subscribed to the list.  
> > 
> > Please don't expect others to keep blacklists of people who can't
> > handle their mail properly, or to generally harm others and ignore good
> > practices because you can't handle your mail.  
> 
> You mean ignoring the Reply-To header is "good practice"?

It's not being ignored, as you can see by the occurrence of the mailing
list in CC.

-- 
Best regards,
Michał Górny



pgpj5AI7rLICI.pgp
Description: OpenPGP digital signature

OT: Mail handling (Was Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW)

[Andrew Savchenko]

On Thu, 16 Jun 2016 16:37:10 +0200 Michał Górny wrote:
> > P.S. Please don't CC me when replying to my e-mails on the list,
> > since I'm already subscribed to the list.
> 
> Please don't expect others to keep blacklists of people who can't
> handle their mail properly, or to generally harm others and ignore good
> practices because you can't handle your mail.

Why blacklisting? Just fix your mail client to honour Reply-to
header.

Best regards,
Andrew Savchenko


pgpgC7vggxciK.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Fabian Groffen]

On 16-06-2016 16:37:10 +0200, Michał Górny wrote:
> > P.S. Please don't CC me when replying to my e-mails on the list,
> > since I'm already subscribed to the list.
> 
> Please don't expect others to keep blacklists of people who can't
> handle their mail properly, or to generally harm others and ignore good
> practices because you can't handle your mail.

You mean ignoring the Reply-To header is "good practice"?


-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Davide Pesavento]

On Thu, Jun 16, 2016 at 4:39 PM, Ian Stakenvicius  wrote:
> On 16/06/16 09:47 AM, Michał Górny wrote:
>> On Thu, 16 Jun 2016 16:22:32 +0300
>> Andrew Savchenko  wrote:
>>>
>>> CONFIRMED state is useful, it means that dev or powerful user
>>> confirmed this bug and gives it more value. I'd like to keep it.
>>
>> Are you saying that bugs that haven't been marked as CONFIRMED have
>> less value? Maybe they don't have to be handled at all, unless someone
>> you consider more worthy confirms them?
>>
>
> To me it's not about increased or decreased value per se, it's about
> workflow:
>
> - An UNCONFIRMED bug I have to reproduce myself and diagnose to
> determine if it's really a bug or if it's something else.
>
> - A CONFIRMED bug to me means this has already been done (by myself,
> others in the project, or dev's that should know the difference) and I
> can skip directly to identifying and fixing the issue.
>
> So when I look at the list of bugs for firefox I know what the state
> is more or less for things that are outstanding.  If I have just a
> little bit of time to hack away at things I'd rather try to close a
> CONFIRMED bug than half-diagnose an UNCONFIRMED one.  Similarly if I
> don't have access to my dev system but have plenty of time, I may well
> try and triage UNCONFIRMED bugs.

+1

>
> IN_PROGRESS to me is something that should be reserved for when the
> fix is ready to go and just hasn't been fully applied or is readily
> available to all users (say, the fix is on an overlay for testing) --
> I would prefer not to start using that instead of CONFIRMED, but if
> that's what the new meaning would be after UNCONFIRMED/CONFIRMED is
> merged to OPEN, I guess I could live with it.
>
>
>

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Ian Stakenvicius]

On 16/06/16 09:47 AM, Michał Górny wrote:
> On Thu, 16 Jun 2016 16:22:32 +0300
> Andrew Savchenko  wrote:
>>  
>> CONFIRMED state is useful, it means that dev or powerful user
>> confirmed this bug and gives it more value. I'd like to keep it.
> 
> Are you saying that bugs that haven't been marked as CONFIRMED have
> less value? Maybe they don't have to be handled at all, unless someone
> you consider more worthy confirms them?
> 

To me it's not about increased or decreased value per se, it's about
workflow:

- An UNCONFIRMED bug I have to reproduce myself and diagnose to
determine if it's really a bug or if it's something else.

- A CONFIRMED bug to me means this has already been done (by myself,
others in the project, or dev's that should know the difference) and I
can skip directly to identifying and fixing the issue.

So when I look at the list of bugs for firefox I know what the state
is more or less for things that are outstanding.  If I have just a
little bit of time to hack away at things I'd rather try to close a
CONFIRMED bug than half-diagnose an UNCONFIRMED one.  Similarly if I
don't have access to my dev system but have plenty of time, I may well
try and triage UNCONFIRMED bugs.

IN_PROGRESS to me is something that should be reserved for when the
fix is ready to go and just hasn't been fully applied or is readily
available to all users (say, the fix is on an overlay for testing) --
I would prefer not to start using that instead of CONFIRMED, but if
that's what the new meaning would be after UNCONFIRMED/CONFIRMED is
merged to OPEN, I guess I could live with it.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Michał Górny]

On Thu, 16 Jun 2016 17:27:07 +0300
Andrew Savchenko  wrote:

> On Thu, 16 Jun 2016 15:47:46 +0200 Michał Górny wrote:
> > On Thu, 16 Jun 2016 16:22:32 +0300
> > Andrew Savchenko  wrote:
> >   
> > > On Thu, 16 Jun 2016 14:26:47 +0200 Michał Górny wrote:  
> > > > Hello, everyone.
> > > > 
> > > > Here's my second RFC wrt bugs.gentoo.org redesign.
> > > > 
> > > > Right now we have separate UNCONFIRMED and CONFIRMED states for bugs.
> > > > However, we use the two scarcely. I believe it would be beneficial to
> > > > replace the two with a single NEW state.
> > > > 
> > > > Rationale:
> > > > 
> > > > 1. Most of developers don't care about the two states, and which one
> > > > bugs are in.
> > > > 
> > > > 2. All bugs need to be handled the same, whether they were marked as
> > > > confirmed or not.
> > > > 
> > > > 3. We stage bugs through bug-wranglers@ which kinda has a similar
> > > > purpose to the UNCONFIRMED state in other Bugzillas.
> > > > 
> > > > 4. Some people who actually care about the two states change them,
> > > > causing unnecessary bugspam.
> > > > 
> > > > 5. Some users who think that the state matters get furious about bugs
> > > > staying in UNCONFIRMED for long.
> > > > 
> > > > Your thoughts?
> > >  
> > > CONFIRMED state is useful, it means that dev or powerful user
> > > confirmed this bug and gives it more value. I'd like to keep it.  
> > 
> > Are you saying that bugs that haven't been marked as CONFIRMED have
> > less value? Maybe they don't have to be handled at all, unless someone
> > you consider more worthy confirms them?  
>  
> Please don't exaggerate my words. "More value" doesn't imply that
> other bugs have no value. Under some conditions it means order
> of preference; e.g. if I'm not able to handle all bugs in a
> timeslot I have, but I am able to fix something, I may prefer
> confirmed bugs over unconfirmed ones, as bugs which are easier to
> reproduce and are likely to affect more users.
> 
> P.S. Please don't CC me when replying to my e-mails on the list,
> since I'm already subscribed to the list.

Please don't expect others to keep blacklists of people who can't
handle their mail properly, or to generally harm others and ignore good
practices because you can't handle your mail.

-- 
Best regards,
Michał Górny



pgpjbZy_3ds25.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Andrew Savchenko]

On Thu, 16 Jun 2016 15:47:46 +0200 Michał Górny wrote:
> On Thu, 16 Jun 2016 16:22:32 +0300
> Andrew Savchenko  wrote:
> 
> > On Thu, 16 Jun 2016 14:26:47 +0200 Michał Górny wrote:
> > > Hello, everyone.
> > > 
> > > Here's my second RFC wrt bugs.gentoo.org redesign.
> > > 
> > > Right now we have separate UNCONFIRMED and CONFIRMED states for bugs.
> > > However, we use the two scarcely. I believe it would be beneficial to
> > > replace the two with a single NEW state.
> > > 
> > > Rationale:
> > > 
> > > 1. Most of developers don't care about the two states, and which one
> > > bugs are in.
> > > 
> > > 2. All bugs need to be handled the same, whether they were marked as
> > > confirmed or not.
> > > 
> > > 3. We stage bugs through bug-wranglers@ which kinda has a similar
> > > purpose to the UNCONFIRMED state in other Bugzillas.
> > > 
> > > 4. Some people who actually care about the two states change them,
> > > causing unnecessary bugspam.
> > > 
> > > 5. Some users who think that the state matters get furious about bugs
> > > staying in UNCONFIRMED for long.
> > > 
> > > Your thoughts?  
> >  
> > CONFIRMED state is useful, it means that dev or powerful user
> > confirmed this bug and gives it more value. I'd like to keep it.
> 
> Are you saying that bugs that haven't been marked as CONFIRMED have
> less value? Maybe they don't have to be handled at all, unless someone
> you consider more worthy confirms them?
 
Please don't exaggerate my words. "More value" doesn't imply that
other bugs have no value. Under some conditions it means order
of preference; e.g. if I'm not able to handle all bugs in a
timeslot I have, but I am able to fix something, I may prefer
confirmed bugs over unconfirmed ones, as bugs which are easier to
reproduce and are likely to affect more users.

P.S. Please don't CC me when replying to my e-mails on the list,
since I'm already subscribed to the list.

Best regards,
Andrew Savchenko


pgpN82PAIPuK7.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Mike Gilbert]

On Thu, Jun 16, 2016 at 9:52 AM, Joshua Kinard  wrote:
> It'd be nice if, when replying in a comment, a flag
> could be made available to automatically to state that "I've encountered this
> issue, too", and once 2, 3, or 4 of those are logged, Bugzilla automatically
> changes the state to CONFIRMED, but doesn't bugspam on this specific state 
> change.

That sounds like the Voting extension, which we already have enabled.
Not sure what the threshold is set to, however.

https://www.bugzilla.org/docs/4.0/en/html/voting.html

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Kent Fredric]

On 17 June 2016 at 01:52, Joshua Kinard  wrote:
> because
> sometimes, issues can get reported that are really obscure and, for example,
> tied to a particular hardware configuration, thus cannot be easily and
> independently confirmed


Isn't that why "RESOLVED: Need Info" exists?

Or is "CONFIRMED" supposed to imply "I can replicate this", as opposed
to the description bugzilla uses: "Determined to be present". (
https://bugzilla.readthedocs.io/en/5.0/_images/bzLifecycle.png )

Our current doc only describes CONFIRMED vs UNCONFIRMED in terms of
"valid" and its predominantly used as a "Can't triage" :

> UNCONFIRMED: This bug has recently been added to the database.|
> Nobody has confirmed that this bug is valid.
> Users who have the "canconfirm" permission set may confirm this bug, changing 
> its state to CONFIRMED.
> Or, it may be directly resolved and marked RESOLVED.

> CONFIRMED: This bug is valid and has recently been filed.
> Bugs in this state become IN_PROGRESS when somebody is working on them, or 
> become resolved and marked RESOLVED.

-- 
Kent

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

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[M. J. Everitt]

On 16/06/16 14:22, Andrew Savchenko wrote:
> On Thu, 16 Jun 2016 14:26:47 +0200 Michał Górny wrote:
>> Hello, everyone.
>>
>> Here's my second RFC wrt bugs.gentoo.org redesign.
>>
>> Right now we have separate UNCONFIRMED and CONFIRMED states for bugs.
>> However, we use the two scarcely. I believe it would be beneficial to
>> replace the two with a single NEW state.
>>
>> Rationale:
>>
>> 1. Most of developers don't care about the two states, and which one
>> bugs are in.
>>
>> 2. All bugs need to be handled the same, whether they were marked as
>> confirmed or not.
>>
>> 3. We stage bugs through bug-wranglers@ which kinda has a similar
>> purpose to the UNCONFIRMED state in other Bugzillas.
>>
>> 4. Some people who actually care about the two states change them,
>> causing unnecessary bugspam.
>>
>> 5. Some users who think that the state matters get furious about bugs
>> staying in UNCONFIRMED for long.
>>
>> Your thoughts?
>  
> CONFIRMED state is useful, it means that dev or powerful user
> confirmed this bug and gives it more value. I'd like to keep it.
>
> Best regards,
> Andrew Savchenko
I think CONFIRMED is useful too, particularly if it shows that the
problem is easily reproducible (ie. either a wrangler/dev/proxy has
actually run the sequence of command as per report, and has replicated
the issue).

ASSIGNED should be the 'default' phase for a bug, after is has been
wrangled. See https://www.bugzilla.org/docs/3.6/en/html/lifecycle.html
for some useful (but not all necessary) states.

I suggest an approximate workflow of NEW->ASSIGNED->CONFIRMED->IN
PROGRESS->RESOLVED/CLOSED/etc.

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Joshua Kinard]

On 06/16/2016 09:22, Andrew Savchenko wrote:
> On Thu, 16 Jun 2016 14:26:47 +0200 Michał Górny wrote:
>> Hello, everyone.
>>
>> Here's my second RFC wrt bugs.gentoo.org redesign.
>>
>> Right now we have separate UNCONFIRMED and CONFIRMED states for bugs.
>> However, we use the two scarcely. I believe it would be beneficial to
>> replace the two with a single NEW state.
>>
>> Rationale:
>>
>> 1. Most of developers don't care about the two states, and which one
>> bugs are in.
>>
>> 2. All bugs need to be handled the same, whether they were marked as
>> confirmed or not.
>>
>> 3. We stage bugs through bug-wranglers@ which kinda has a similar
>> purpose to the UNCONFIRMED state in other Bugzillas.
>>
>> 4. Some people who actually care about the two states change them,
>> causing unnecessary bugspam.
>>
>> 5. Some users who think that the state matters get furious about bugs
>> staying in UNCONFIRMED for long.
>>
>> Your thoughts?
>  
> CONFIRMED state is useful, it means that dev or powerful user
> confirmed this bug and gives it more value. I'd like to keep it.
> 
> Best regards,
> Andrew Savchenko

+1 here, too.  UNCONFIRMED should be the default for new bugs, because
sometimes, issues can get reported that are really obscure and, for example,
tied to a particular hardware configuration, thus cannot be easily and
independently confirmed.  It'd be nice if, when replying in a comment, a flag
could be made available to automatically to state that "I've encountered this
issue, too", and once 2, 3, or 4 of those are logged, Bugzilla automatically
changes the state to CONFIRMED, but doesn't bugspam on this specific state 
change.

Also, +1 to changing UNRESOLVED to OPEN.

Don't suppose we can get a RESOLVED::RTFM, can we? :)

(I'm kidding)

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Michał Górny]

On Thu, 16 Jun 2016 16:22:32 +0300
Andrew Savchenko  wrote:

> On Thu, 16 Jun 2016 14:26:47 +0200 Michał Górny wrote:
> > Hello, everyone.
> > 
> > Here's my second RFC wrt bugs.gentoo.org redesign.
> > 
> > Right now we have separate UNCONFIRMED and CONFIRMED states for bugs.
> > However, we use the two scarcely. I believe it would be beneficial to
> > replace the two with a single NEW state.
> > 
> > Rationale:
> > 
> > 1. Most of developers don't care about the two states, and which one
> > bugs are in.
> > 
> > 2. All bugs need to be handled the same, whether they were marked as
> > confirmed or not.
> > 
> > 3. We stage bugs through bug-wranglers@ which kinda has a similar
> > purpose to the UNCONFIRMED state in other Bugzillas.
> > 
> > 4. Some people who actually care about the two states change them,
> > causing unnecessary bugspam.
> > 
> > 5. Some users who think that the state matters get furious about bugs
> > staying in UNCONFIRMED for long.
> > 
> > Your thoughts?  
>  
> CONFIRMED state is useful, it means that dev or powerful user
> confirmed this bug and gives it more value. I'd like to keep it.

Are you saying that bugs that haven't been marked as CONFIRMED have
less value? Maybe they don't have to be handled at all, unless someone
you consider more worthy confirms them?

-- 
Best regards,
Michał Górny



pgp4HhIc0h6Vy.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Kristian Fiskerstrand]

On 06/16/2016 02:56 PM, Kent Fredric wrote:
> On 17 June 2016 at 00:51, Michał Górny  wrote:
>> We could also use plain 'OPEN' ;-).
> 
> 
> +1. I was going to suggest the same.
> 

Bug is still open even if it is IN_PROGRESS or not in stable. But I
currently make use of the UNCONFIRMED / CONFIRMED distinction as well ,
CONFIRMED often in relation to UPSTREAM keyword that I'm not actively
working on myself

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

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Andrew Savchenko]

On Thu, 16 Jun 2016 14:26:47 +0200 Michał Górny wrote:
> Hello, everyone.
> 
> Here's my second RFC wrt bugs.gentoo.org redesign.
> 
> Right now we have separate UNCONFIRMED and CONFIRMED states for bugs.
> However, we use the two scarcely. I believe it would be beneficial to
> replace the two with a single NEW state.
> 
> Rationale:
> 
> 1. Most of developers don't care about the two states, and which one
> bugs are in.
> 
> 2. All bugs need to be handled the same, whether they were marked as
> confirmed or not.
> 
> 3. We stage bugs through bug-wranglers@ which kinda has a similar
> purpose to the UNCONFIRMED state in other Bugzillas.
> 
> 4. Some people who actually care about the two states change them,
> causing unnecessary bugspam.
> 
> 5. Some users who think that the state matters get furious about bugs
> staying in UNCONFIRMED for long.
> 
> Your thoughts?
 
CONFIRMED state is useful, it means that dev or powerful user
confirmed this bug and gives it more value. I'd like to keep it.

Best regards,
Andrew Savchenko


pgpqpzjzJbEL2.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Kent Fredric]

On 17 June 2016 at 00:51, Michał Górny  wrote:
> We could also use plain 'OPEN' ;-).


+1. I was going to suggest the same.

-- 
Kent

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

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Fabian Groffen]

On 16-06-2016 14:51:26 +0200, Michał Górny wrote:
> On Thu, 16 Jun 2016 14:41:43 +0200
> Fabian Groffen  wrote:
> 
> > On 16-06-2016 14:26:47 +0200, Michał Górny wrote:
> > > Hello, everyone.
> > > 
> > > Here's my second RFC wrt bugs.gentoo.org redesign.
> > > 
> > > Right now we have separate UNCONFIRMED and CONFIRMED states for bugs.
> > > However, we use the two scarcely. I believe it would be beneficial to
> > > replace the two with a single NEW state.  
> > ... 
> > > Your thoughts?  
> > 
> > How about UNRESOLVED instead?  Else you get bugs which are NEW for years
> > even though they have activity all over.
> 
> We could also use plain 'OPEN' ;-).

Works for me too.

-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Michał Górny]

On Thu, 16 Jun 2016 14:41:43 +0200
Fabian Groffen  wrote:

> On 16-06-2016 14:26:47 +0200, Michał Górny wrote:
> > Hello, everyone.
> > 
> > Here's my second RFC wrt bugs.gentoo.org redesign.
> > 
> > Right now we have separate UNCONFIRMED and CONFIRMED states for bugs.
> > However, we use the two scarcely. I believe it would be beneficial to
> > replace the two with a single NEW state.  
> ... 
> > Your thoughts?  
> 
> How about UNRESOLVED instead?  Else you get bugs which are NEW for years
> even though they have activity all over.

We could also use plain 'OPEN' ;-).

-- 
Best regards,
Michał Górny



pgpQzgIDYDXu9.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Fabian Groffen]

On 16-06-2016 14:26:47 +0200, Michał Górny wrote:
> Hello, everyone.
> 
> Here's my second RFC wrt bugs.gentoo.org redesign.
> 
> Right now we have separate UNCONFIRMED and CONFIRMED states for bugs.
> However, we use the two scarcely. I believe it would be beneficial to
> replace the two with a single NEW state.
... 
> Your thoughts?

How about UNRESOLVED instead?  Else you get bugs which are NEW for years
even though they have activity all over.

Thanks,
Fabian

-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

[gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Michał Górny]

Hello, everyone.

Here's my second RFC wrt bugs.gentoo.org redesign.

Right now we have separate UNCONFIRMED and CONFIRMED states for bugs.
However, we use the two scarcely. I believe it would be beneficial to
replace the two with a single NEW state.

Rationale:

1. Most of developers don't care about the two states, and which one
bugs are in.

2. All bugs need to be handled the same, whether they were marked as
confirmed or not.

3. We stage bugs through bug-wranglers@ which kinda has a similar
purpose to the UNCONFIRMED state in other Bugzillas.

4. Some people who actually care about the two states change them,
causing unnecessary bugspam.

5. Some users who think that the state matters get furious about bugs
staying in UNCONFIRMED for long.

Your thoughts?

-- 
Best regards,
Michał Górny



pgpFxj2strrbX.pgp
Description: OpenPGP digital signature