Danger: older bugs are getting squashed with NEEDINFO

[Tristan Van Berkom-2]

Guys,
    Im sorry I missed the memo if there was one, I woke up this
morning to a full page of bugmail, deleting valid bugs from the
buglist and throwing them into a NEEDINFO state.

Javier pointed me to a blog post[0] which describes a new policy
to mark bugs as NEEDINFO after one year. I'm raising the flag here
on d-d-l because it concerns us all and I think every maintainer
needs to know this policy is currently in effect.

I know the guys mean well, and I cannot express my gratitude
enough for the efficiency that the bugsquad has for closing
some crash bugs that really do need info.

Suffice it to say; I really need to know this policy is going to stop,
or at least not effect Glade bugs.

Thank you,
      -Tristan

[0]http://blogs.gnome.org/aklapper/2009/08/10/gnome-bugsquad-policy-changes/
_______________________________________________
gnome-bugsquad mailing list
gnome-bugsquad@...
http://mail.gnome.org/mailman/listinfo/gnome-bugsquad

[C de-Avillez-2]

On Sun, 13 Sep 2009 12:24:23 -0400
Tristan Van Berkom <tristan.van.berkom@...> wrote:

> Guys,
>     Im sorry I missed the memo if there was one, I woke up this
> morning to a full page of bugmail, deleting valid bugs from the
> buglist and throwing them into a NEEDINFO state.
>
> Javier pointed me to a blog post[0] which describes a new policy
> to mark bugs as NEEDINFO after one year. I'm raising the flag here
> on d-d-l because it concerns us all and I think every maintainer
> needs to know this policy is currently in effect.
>
> I know the guys mean well, and I cannot express my gratitude
> enough for the efficiency that the bugsquad has for closing
> some crash bugs that really do need info.
>
> Suffice it to say; I really need to know this policy is going to stop,
> or at least not effect Glade bugs.
>

All,

We had a chat a few ago on #bugs, and we agree this was rather too
inclusive: as Tristan points out, and others commented, a confirmed
(i.e., status NEW) bug is no longer under the care of the bugsquad.

We have just revised the policy to refer exclusively to:

  * UNCONFIRMED bugs with *no* action in the last year

We appreciate the feedback, and we would like to keep on having
more ;-). We invite any interested party to either email us at the
gnome-bugsquad or to drop by #bugs, voicing their concerns and
suggestions.

Regards,





_______________________________________________
gnome-bugsquad mailing list
gnome-bugsquad@...
http://mail.gnome.org/mailman/listinfo/gnome-bugsquad

[Tristan Van Berkom]

On Thu, Sep 17, 2009 at 11:32 AM, C de-Avillez <hggdh2@...> wrote:
[...]

> All,
>
> We had a chat a few ago on #bugs, and we agree this was rather too
> inclusive: as Tristan points out, and others commented, a confirmed
> (i.e., status NEW) bug is no longer under the care of the bugsquad.
>
> We have just revised the policy to refer exclusively to:
>
>  * UNCONFIRMED bugs with *no* action in the last year
>
> We appreciate the feedback, and we would like to keep on having
> more ;-). We invite any interested party to either email us at the
> gnome-bugsquad or to drop by #bugs, voicing their concerns and
> suggestions.

Really, I dont think this is good enough for me.

As for Glade, a bug has always either been UNCONFIRMED or RESOLVED...

Let me put it this way, I have been contributing sporadically
over the last 5 years, the last time I gave the buglist a short
runthrough was in December before releasing Glade 3.6, since then
the buglist has seen alot of activity and I have religiously only
dealt with crasher bugs, it happens often enough that I dont touch
Glade at all for 6 months at a time.

I really dont have time to run after the crasher bugs that I do
run after this year, but I do it cause I wanted to promise at
least something usable that doesnt crash.

Now its like you are telling me that if I dont go through my
whole buglist myself and explicitly mark every unconfirmed
bug as new, that I will lose all the older bugs.

I also feel threatened that if I dont pay attention promptly
to bugmail that bugs will be lost on the long term.

So the bottom line is basically this: if you feel this should
be the minimum standard of attention that a maintainer must
absolutely pay to his buglist, then so be it, but I think you are
being unfair to ask this of me.

Regards,
          -Tristan
_______________________________________________
gnome-bugsquad mailing list
gnome-bugsquad@...
http://mail.gnome.org/mailman/listinfo/gnome-bugsquad

[Andre Klapper]

Am Donnerstag, den 17.09.2009, 15:26 -0400 schrieb Tristan Van Berkom:
> So the bottom line is basically this: if you feel this should
> be the minimum standard of attention that a maintainer must
> absolutely pay to his buglist, then so be it, but I think you are
> being unfair to ask this of me.

Yes, I expect maintainers should be able to take a look at the incoming
bug reports at least once in 12 months.
That is all what this policy is about.
Nothing else.

andre
--
 mailto:ak-47@... | failed
 http://www.iomc.de/  | http://blogs.gnome.org/aklapper

_______________________________________________
gnome-bugsquad mailing list
gnome-bugsquad@...
http://mail.gnome.org/mailman/listinfo/gnome-bugsquad

[Pietro Battiston]

Il giorno ven, 18/09/2009 alle 13.44 +0200, Andre Klapper ha scritto:

> Am Donnerstag, den 17.09.2009, 15:26 -0400 schrieb Tristan Van Berkom:
> > So the bottom line is basically this: if you feel this should
> > be the minimum standard of attention that a maintainer must
> > absolutely pay to his buglist, then so be it, but I think you are
> > being unfair to ask this of me.
>
> Yes, I expect maintainers should be able to take a look at the incoming
> bug reports at least once in 12 months.
> That is all what this policy is about.
> Nothing else.
>

Apparently the bugsquad should find some glade bugs maintainer; I can
witness Tristan has already more than enough work in the development (of
a key application which lacks manpower - I admit that with respect to
the second point, it may not be very peculiar, but apparently all other
developers have time to take care of bugs - oddly enough, I thought this
was the business of the bugsquad).

Then, once someone offers to be the glade bugs maintainer, I think we
could ask that he checks every bug once a year.

In the meanwhile, the policy obviously doesn't apply.

Pietro


_______________________________________________
gnome-bugsquad mailing list
gnome-bugsquad@...
http://mail.gnome.org/mailman/listinfo/gnome-bugsquad

[Olav Vitters]

On Fri, Sep 18, 2009 at 04:15:19PM +0200, Pietro Battiston wrote:
> Then, once someone offers to be the glade bugs maintainer, I think we
> could ask that he checks every bug once a year.

You're restating what has been suggested.

If a bug is valid, mark it as NEW. It was already proposed that the
policy only applies to unconfirmed bugs.
--
Regards,
Olav
_______________________________________________
gnome-bugsquad mailing list
gnome-bugsquad@...
http://mail.gnome.org/mailman/listinfo/gnome-bugsquad

[Andre Klapper]

Am Freitag, den 18.09.2009, 16:15 +0200 schrieb Pietro Battiston:
> Il giorno ven, 18/09/2009 alle 13.44 +0200, Andre Klapper ha scritto:
> > Yes, I expect maintainers should be able to take a look at the incoming
> > bug reports at least once in 12 months.

> Then, once someone offers to be the glade bugs maintainer, I think we
> could ask that he checks every bug once a year.

You completely missed the word "incoming".
Hence your argument is invalid.

andre
--
 mailto:ak-47@... | failed
 http://www.iomc.de/  | http://blogs.gnome.org/aklapper

_______________________________________________
gnome-bugsquad mailing list
gnome-bugsquad@...
http://mail.gnome.org/mailman/listinfo/gnome-bugsquad

[Tristan Van Berkom]

On Fri, Sep 18, 2009 at 7:44 AM, Andre Klapper <ak-47@...> wrote:

> Am Donnerstag, den 17.09.2009, 15:26 -0400 schrieb Tristan Van Berkom:
>> So the bottom line is basically this: if you feel this should
>> be the minimum standard of attention that a maintainer must
>> absolutely pay to his buglist, then so be it, but I think you are
>> being unfair to ask this of me.
>
> Yes, I expect maintainers should be able to take a look at the incoming
> bug reports at least once in 12 months.
> That is all what this policy is about.
> Nothing else.

I am seriously and sadly insulted now.

Lets recap:
  - There was no effort made at all to contact me about this policy change
  - The policy change you are making directly involves me doing lots
of work now:
       going over hundreds of entries in the buglist one by one, waiting for
       bugzilla.gnome.org to resolve, and manually "claim" bugs that I
am interested
       in keeping.
  - It also means that receiving bugmail is not good enough, I must from now on
    always visit bugzilla.gnome.org and resolve the page to claim the bug, after
    having coffee and reading my morning bugmail, and just before I
hurry out the door.

And if this weren't enough, now you are telling me that this policy is all about
me not doing enough work for GNOME, Nothing else.

This is the attitude I expect from people outside of GNOME, people
reporting bugs
whom dont completely understand what it is we go through to deliver GNOME.

To tell you the truth its gotten so bad this year that sometimes I just dont
want to look at the bugmail, for fear of another user telling me:
   "how dare you release 3.6 at all if its not perfect, you must fix it for
    me immediately or I will declare your work a waste of time".

I need to know that we are together in GNOME, we are supposed to be a team;
please dont tell me that my work is not welcome.

Regards,
   - A tired maintainer.
_______________________________________________
gnome-bugsquad mailing list
gnome-bugsquad@...
http://mail.gnome.org/mailman/listinfo/gnome-bugsquad

[Owen Taylor]

On Thu, 2009-09-17 at 10:32 -0500, C de-Avillez wrote:

> On Sun, 13 Sep 2009 12:24:23 -0400
> Tristan Van Berkom <tristan.van.berkom@...> wrote:
>
> > Guys,
> >     Im sorry I missed the memo if there was one, I woke up this
> > morning to a full page of bugmail, deleting valid bugs from the
> > buglist and throwing them into a NEEDINFO state.
> >
> > Javier pointed me to a blog post[0] which describes a new policy
> > to mark bugs as NEEDINFO after one year. I'm raising the flag here
> > on d-d-l because it concerns us all and I think every maintainer
> > needs to know this policy is currently in effect.
> >
> > I know the guys mean well, and I cannot express my gratitude
> > enough for the efficiency that the bugsquad has for closing
> > some crash bugs that really do need info.
> >
> > Suffice it to say; I really need to know this policy is going to stop,
> > or at least not effect Glade bugs.
> >
>
> All,
>
> We had a chat a few ago on #bugs, and we agree this was rather too
> inclusive: as Tristan points out, and others commented, a confirmed
> (i.e., status NEW) bug is no longer under the care of the bugsquad.
>
> We have just revised the policy to refer exclusively to:
>
>   * UNCONFIRMED bugs with *no* action in the last year
>
> We appreciate the feedback, and we would like to keep on having
> more ;-). We invite any interested party to either email us at the
> gnome-bugsquad or to drop by #bugs, voicing their concerns and
> suggestions.

I think for most modules, confirming bugs has usually seemed like a
waste of of the maintainer's time. Confirming bugs assumes that the
maintainer isn't looking at bugs until they are confirmed. Once the
maintainer is already looking at a bug, what's the point of confirming
it?

So, the confirmation step only makes sense in a module that is getting
lots of NOTABUG and DUPLICATE bugs and where bug triaging will help deal
with that stream.

There are huge numbers of bugs out there with extensively commentary,
patches, etc, that are in the UNCONFIRMED state because the module
maintainers don't care about that distinction.

Would you really propose closing:

https://bugzilla.gnome.org/show_bug.cgi?id=572312

even if there is no activity in the next year just because it's never
been confirmed?

Is it possible on a product-by-product basis to have all bugs go
automatically to the NEW state? And just have the UNCONFIRMED state for
modules where the bugsquad is actively triaging bugs?

Or have the first comment from a developer on a bug automatically mark
it as NEW if no other status change is made?

(Neither helps at all with past history and all the UNCONFIRMED bugs we
have now.)

- Owen


_______________________________________________
gnome-bugsquad mailing list
gnome-bugsquad@...
http://mail.gnome.org/mailman/listinfo/gnome-bugsquad

[Matthias Clasen-2]

Tristan,

I believe you could just ask the bugsquad to kindly skip over glade3
bugs if their policy doesn't work for you or causes you more work.
_______________________________________________
gnome-bugsquad mailing list
gnome-bugsquad@...
http://mail.gnome.org/mailman/listinfo/gnome-bugsquad

[Max Kanat-Alexander]

On 09/18/2009 11:28 AM, Owen Taylor wrote:
> Is it possible on a product-by-product basis to have all bugs go
> automatically to the NEW state?

        Normally, yes. However, implicit in the bugzilla.gnome.org
customizations is the idea that UNCONFIRMED will always be enabled, so
there are probably various bits of custom code that don't check if UNCO
is turned on or not for a product. Also, I believe the customizations
hide the UI from you (the voting admin parameters) that allows you to
disabled UNCONFIRMED in a product.

        -Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
_______________________________________________
gnome-bugsquad mailing list
gnome-bugsquad@...
http://mail.gnome.org/mailman/listinfo/gnome-bugsquad

[Andre Klapper]

Hi Tristan,

Am Freitag, den 18.09.2009, 14:16 -0400 schrieb Tristan Van Berkom:

> On Fri, Sep 18, 2009 at 7:44 AM, Andre Klapper <ak-47@...> wrote:
> > Am Donnerstag, den 17.09.2009, 15:26 -0400 schrieb Tristan Van Berkom:
> >> So the bottom line is basically this: if you feel this should
> >> be the minimum standard of attention that a maintainer must
> >> absolutely pay to his buglist, then so be it, but I think you are
> >> being unfair to ask this of me.
> >
> > Yes, I expect maintainers should be able to take a look at the incoming
> > bug reports at least once in 12 months.
> > That is all what this policy is about.
> > Nothing else.
>
> I am seriously and sadly insulted now.

That was not the intention.
I'm sorry and wonder which of my words insulted you.

> Lets recap:
>   - There was no effort made at all to contact me about this policy change

Absolutely valid criticism, and that's why it's good to have this thread
now.
We (bugsquad) underestimated that the initial policy would have such a
negative outcome for some maintainers.
Hence we've changed the policy to only apply to bugs in UNCONFIRMED
state that have not been touched for a year.

So from my personal point of view I'd define that "minimum standard of
attention" to bug reports as "once in a year".
Other opinions welcome.

>   - The policy change you are making directly involves me doing lots
> of work now:
>        going over hundreds of entries in the buglist one by one, waiting for
>        bugzilla.gnome.org to resolve, and manually "claim" bugs that I
> am interested
>        in keeping.

I'm unsure what "claim" means here. If it means "confirming by changing
the status from UNCONFIRMED to NEW": yes.

glade3 currently has 212 tickets in UNCONFIRMED state. Of these tickets,
70 have not been touched for more than one year[1].
So "hundreds of entries" are currently 70 for glade3.

>   - It also means that receiving bugmail is not good enough, I must from now on
>     always visit bugzilla.gnome.org and resolve the page to claim the bug, after
>     having coffee and reading my morning bugmail, and just before I
> hurry out the door.

If you replace "always" by "once in a year" this is a correct statement.

> And if this weren't enough, now you are telling me that this policy is all about
> me not doing enough work for GNOME, Nothing else.

I never used words like "not doing enough for GNOME" here. There was no
intention to imply this, or to imply, in any way, "not enough work done
for GNOME".

> To tell you the truth its gotten so bad this year that sometimes I just dont
> want to look at the bugmail, for fear of another user telling me:
>    "how dare you release 3.6 at all if its not perfect, you must fix it for
>     me immediately or I will declare your work a waste of time".

I think we've all made our bad experiences with people that
misunderstand open-source culture as "You work for free but you must fix
this for me because it's the most important bug in the world and I am
always right". For worse cases we also have a Code of Conduct in
place[2]. But of course it's also one of GNOME's aim to ship stable
software without any big flaws included.
I consider the "or I will declare your work a waste of time" part as
offending/insulting.

> I need to know that we are together in GNOME, we are supposed to be a team;
> please dont tell me that my work is not welcome.

Nobody ever stated this.
Everybody's work is welcome in GNOME. It is the Bugsquad's intention to
work in consensus with all of GNOME and it always has been.
We are sorry on *not* having communicated with the rest of GNOME about
this change, but we believed that all developers subscribed to bugs.
We would very much like to know which other mailing lists we should add
on.


So to summarize, the question boils down to:
Are you able to take a look at the latest glade3 bug reports once a
year? If not, glade3 probably has to be excluded from the policy.

And do other maintainers totally or partially share Tristan's criticism?

As already said, the GNOME Bugsquad is highly interested in feedback, as
it exists to help developers and maintainers to do their jobs (by trying
to find a good compromise between avoiding creating more work than
necessary for developers and avoiding having a database with lots of
outdated ancient bugs).

andre (with a big Thanks to C de-Avillez)

[1] https://bugzilla.gnome.org/buglist.cgi?chfieldto=-365d&chfieldfrom=-5000d&bug_status=UNCONFIRMED&product=glade3
[2] http://live.gnome.org/CodeOfConduct
--
 mailto:ak-47@... | failed
 http://www.iomc.de/  | http://blogs.gnome.org/aklapper

_______________________________________________
gnome-bugsquad mailing list
gnome-bugsquad@...
http://mail.gnome.org/mailman/listinfo/gnome-bugsquad

[Colin Walters]

On Fri, Sep 18, 2009 at 7:20 PM, Andre Klapper <ak-47@...> wrote:
>and avoiding having a database with lots of
> outdated ancient bugs).

Can you elaborate a bit on what the higher level goals of closing the
bugs is?  They still remain in the database, no?  Is the issue speed
of queries on the product pages?  Searches?

If so, again I think a far simpler solution is to add "modified in the
last year" to the default product query, with a link to "show all".
Similarly for search, first do a search including modified in last
year, if no hits, retry query for all of time.
_______________________________________________
gnome-bugsquad mailing list
gnome-bugsquad@...
http://mail.gnome.org/mailman/listinfo/gnome-bugsquad

[Tristan Van Berkom]

On Fri, Sep 18, 2009 at 3:20 PM, Andre Klapper <ak-47@...> wrote:
[...]
>
> So to summarize, the question boils down to:
> Are you able to take a look at the latest glade3 bug reports once a
> year? If not, glade3 probably has to be excluded from the policy.

I receive bugmail for all bugs and I am quite aware of the state of
the buglist at all times.

Glade will not see another major point release without running through
the buglist (in Glade 3.0, 3.2 and 3.4, we were able to use the list to chose
reasonable blocker bugs and release something more stable, this time
I simply could not do it), basically I need the buglist to be intact whenever
initiative picks up in the future, when Juan and I and hopefully some fresh
blood have motivation and time to run through the blockers.

To answer briefly, no I cannot afford to make any promise to remember
to claim bugs on the list by marking them NEW, rather I need the untended
to list to stay in tact for when we need it.

Please exclude Glade from this policy.

Regards,
           -Tristan
_______________________________________________
gnome-bugsquad mailing list
gnome-bugsquad@...
http://mail.gnome.org/mailman/listinfo/gnome-bugsquad

[Pietro Battiston]

Il giorno ven, 18/09/2009 alle 16.37 +0200, Andre Klapper ha scritto:

> Am Freitag, den 18.09.2009, 16:15 +0200 schrieb Pietro Battiston:
> > Il giorno ven, 18/09/2009 alle 13.44 +0200, Andre Klapper ha scritto:
> > > Yes, I expect maintainers should be able to take a look at the incoming
> > > bug reports at least once in 12 months.
>
> > Then, once someone offers to be the glade bugs maintainer, I think we
> > could ask that he checks every bug once a year.
>
> You completely missed the word "incoming".
> Hence your argument is invalid.

You completely misused the work "incoming". There is a better word,
"UNCONFIRMED" (I didn't decide it).

Pietro


_______________________________________________
gnome-bugsquad mailing list
gnome-bugsquad@...
http://mail.gnome.org/mailman/listinfo/gnome-bugsquad

[Sandy Armstrong]

On Fri, Sep 18, 2009 at 12:20 PM, Andre Klapper <ak-47@...> wrote:
> We are sorry on *not* having communicated with the rest of GNOME about
> this change, but we believed that all developers subscribed to bugs.
> We would very much like to know which other mailing lists we should add
> on.

The only mailing list that I ever assume GNOME developers are on is
desktop-devel-list.

When you say "subscribed to bugs", I can only assume you mean the
gnome-bugsquad@... list which appears in the CC here.  I have
never heard of this mailing list until now.  Is this something I
should be subscribed to?

About the change...

I usually don't mark a bug CONFIRMED until a developer has confirmed
it, and sometimes things slip through the cracks.  This is especially
the case with Enhancement bugs, because I only mark such bugs
CONFIRMED if I intend to implement them in the short-term.  Setting
them to NEEDINFO seems a little awkward.  NEEDINFO bugs tend to
disappear from a lot of searches, but I guess with this change I'll
need to start actively keeping an eye on that category.

I'm not too freaked out about it, but at the same time I'm not sure
how the change helps the bugsquad in the case of my modules.

Sandy
_______________________________________________
gnome-bugsquad mailing list
gnome-bugsquad@...
http://mail.gnome.org/mailman/listinfo/gnome-bugsquad

[C de-Avillez-2]

On Fri, 18 Sep 2009 15:48:27 -0700
Sandy Armstrong <sanfordarmstrong@...> wrote:


> When you say "subscribed to bugs", I can only assume you mean the
> gnome-bugsquad@... list which appears in the CC here.  I have
> never heard of this mailing list until now.  Is this something I
> should be subscribed to?

Yes indeed, we meant gnome-bugsquad. Sorry -- this is, specifically,
my fault.

This is a low-volume ML, usually with announcements and
questions/responses on the triaging process. I personally (and,
now obviously, absolutely wrong) expected this to be a
generally-subscribed ML.

ut, going on: we could do it either way, but I would rather have it set:
either all subscribe to gnome-bugsquad ML, or we copy all the GNOME
devel MLs when we send out an announcement like this one. But not both.

>
> About the change...
>
> I usually don't mark a bug CONFIRMED until a developer has confirmed
> it, and sometimes things slip through the cracks.  This is especially
> the case with Enhancement bugs, because I only mark such bugs
> CONFIRMED if I intend to implement them in the short-term.  Setting
> them to NEEDINFO seems a little awkward.  NEEDINFO bugs tend to
> disappear from a lot of searches, but I guess with this change I'll
> need to start actively keeping an eye on that category.

The whole issue, it seems, stems from the fact that triagers look, and
work, on UNCONFIRMED bugs, until such a point where enough information
has been collected, the issue identified, and a developer/maintainer
can then work on the bug.

Keeping a valid, ready-for-developer work, bug UNCONFIRMED only
pollutes the search results for triagers, making triaging much more
difficult: "is this old bug a ready-for-developer one, or should we work
on it"-type of questions.

As much as developers do not want to spend time doing unneeded work, so
do triagers.

> I'm not too freaked out about it, but at the same time I'm not sure
> how the change helps the bugsquad in the case of my modules.

Sandy, I do not know either. We erred in assuming all would read it.
But we *do* need to have a common way of working with bugs.

Cheers,

p.s. I am not subscribed to the dekstop-devel-list, so I have no idea
if this will make there or not. I am not a GNOME developer. Should I
subscribe to it?


_______________________________________________
gnome-bugsquad mailing list
gnome-bugsquad@...
http://mail.gnome.org/mailman/listinfo/gnome-bugsquad

[Danielle Madeley]

On Fri, 2009-09-18 at 14:28 -0400, Owen Taylor wrote:

> I think for most modules, confirming bugs has usually seemed like a
> waste of of the maintainer's time. Confirming bugs assumes that the
> maintainer isn't looking at bugs until they are confirmed. Once the
> maintainer is already looking at a bug, what's the point of confirming
> it?

So, while it is indeed an extra click or two to confirm a bug as NEW, is
it really that much extra time?

Surely most of your time was spent in reading the bug, thinking about
it, establishing that it was not a duplicate, and then commenting on it
that confirming it is only one extra mouse click.

It seems that an UNCONFIRMED bug is likely to move into one of three
states: NEW, DUPLICATE or NEEDINFO. Sometimes if the fix is easy, you
might fix it immediately and move it to RESOLVED, but in this case the
1yr rule clearly does not apply.

Marking bugs also seems to me to be a polite way of telling the reporter
that you're aware of her issue and that it does seem to be a legitimate
bug (especially in the case of GTK+ or another library, this means that
maybe the reporter will stop trying to work out if it's a bug in her
code).

I know that sometimes you can't be sure about a bug immediately, so you
leave it alone. Maybe we need a system that finds all UNCONFIRMED bugs
that are 6 months old, or 11 months old and emails a reminder summary to
the maintainer. That gives the maintainer an opportunity to confirm the
bugs she now knows/suspects to be real.

--danni

--
Danielle Madeley

Collabora Ltd., Melbourne, Australia
http://www.collabora.co.uk/

_______________________________________________
gnome-bugsquad mailing list
gnome-bugsquad@...
http://mail.gnome.org/mailman/listinfo/gnome-bugsquad

[Tristan Van Berkom-2]

On Fri, Sep 18, 2009 at 8:42 PM, Danielle Madeley
<danielle.madeley@...> wrote:

> On Fri, 2009-09-18 at 14:28 -0400, Owen Taylor wrote:
>
>> I think for most modules, confirming bugs has usually seemed like a
>> waste of of the maintainer's time. Confirming bugs assumes that the
>> maintainer isn't looking at bugs until they are confirmed. Once the
>> maintainer is already looking at a bug, what's the point of confirming
>> it?
>
> So, while it is indeed an extra click or two to confirm a bug as NEW, is
> it really that much extra time?
>

Yes,
   I do receive bugmail almost every day on average myself, and if I have any
reason to close the bug, if its invalid or misguided, I will go all the way
to bugzilla.gnome.org and close or correct the bug, which generally represents
at least one bug a week I have to close.

I have been taking care of Glade for ~5 years now; does it represent alot
of time for me to mark one bug as confirmed every day for the next 5 years ?

Yes in fact it can take a big slice out of your own life.

Cheers,
               -Tristan

> Surely most of your time was spent in reading the bug, thinking about
> it, establishing that it was not a duplicate, and then commenting on it
> that confirming it is only one extra mouse click.
>
> It seems that an UNCONFIRMED bug is likely to move into one of three
> states: NEW, DUPLICATE or NEEDINFO. Sometimes if the fix is easy, you
> might fix it immediately and move it to RESOLVED, but in this case the
> 1yr rule clearly does not apply.
>
> Marking bugs also seems to me to be a polite way of telling the reporter
> that you're aware of her issue and that it does seem to be a legitimate
> bug (especially in the case of GTK+ or another library, this means that
> maybe the reporter will stop trying to work out if it's a bug in her
> code).
>
> I know that sometimes you can't be sure about a bug immediately, so you
> leave it alone. Maybe we need a system that finds all UNCONFIRMED bugs
> that are 6 months old, or 11 months old and emails a reminder summary to
> the maintainer. That gives the maintainer an opportunity to confirm the
> bugs she now knows/suspects to be real.
>
> --danni
>
> --
> Danielle Madeley
>
> Collabora Ltd., Melbourne, Australia
> http://www.collabora.co.uk/
>
>

_______________________________________________
gnome-bugsquad mailing list
gnome-bugsquad@...
http://mail.gnome.org/mailman/listinfo/gnome-bugsquad

[Owen Taylor]

On Sat, 2009-09-19 at 10:42 +1000, Danielle Madeley wrote:

> On Fri, 2009-09-18 at 14:28 -0400, Owen Taylor wrote:
>
> > I think for most modules, confirming bugs has usually seemed like a
> > waste of of the maintainer's time. Confirming bugs assumes that the
> > maintainer isn't looking at bugs until they are confirmed. Once the
> > maintainer is already looking at a bug, what's the point of confirming
> > it?
>
> So, while it is indeed an extra click or two to confirm a bug as NEW, is
> it really that much extra time?
>
> Surely most of your time was spent in reading the bug, thinking about
> it, establishing that it was not a duplicate, and then commenting on it
> that confirming it is only one extra mouse click.

I'm not really objecting to the work of confirming bugs, though I
sometimes feel a reluctance to confirm a bug where the reporter has a
valid problem, but is proposing a solution to it which is utterly on
crack, and I would worry that I'd forget to confirm some bug, and then a
year later it would go poof.

But the main problem is that treating UNCONFIRMED bugs as invalid bugs
is imposing an interpretation that is utterly unsupported for 10's of
thousands of old bugs. The incentive to confirm bugs in the past was
just not there at all.

- Owen


_______________________________________________
gnome-bugsquad mailing list
gnome-bugsquad@...
http://mail.gnome.org/mailman/listinfo/gnome-bugsquad