GNOME 3.4 released

Posted Mar 29, 2012 12:49 UTC (Thu) by cortana (subscriber, #24596)
In reply to: GNOME 3.4 released by micka
Parent article: GNOME 3.4 released

And me too. I don't mean to come off as a grumpy old git, but the presumption that all users should have filed a bug report before they complain about features being removed, etc., really wrankles me. I file bugs with pretty much every piece of free software that I use but I realise that most users wouldn't have a clue about how to go about doing so, and furthermore, they find out that their pet feature has been removed when the software in question is pushed to them by their distro. I often find that by the time I file a bug, upstream has moved on and just asks me to re-test with the latest version (that I won't see for 6-9 months)...

GNOME 3.4 released

Posted Mar 29, 2012 12:57 UTC (Thu) by hadess (subscriber, #24252) [Link] (13 responses)

> but I realise that most users wouldn't have a clue about how to go about doing so,

Right. But I'm not talking about most users, I'm talking about people who complain on LWN's comments thread. Anyway, dead horse is flogged now.

GNOME 3.4 released

Posted Mar 29, 2012 16:31 UTC (Thu) by dgm (subscriber, #49227) [Link] (12 responses)

Was that a complaint? And in a LWN thread no less!!! Aren't you ashamed of yourself?

I suggest that, as an act of contrition, go and file a bug in the gnome-users bug tracker. Something like this:

Bug#1 Users complain about things they don't like Assigned to: nobody Status: closed (INVALID) Description: Users tend to complain, usually in public forums, about things they don't like. Also, they tend to give grumpy replies when told to file bugs on the bug tracking system, although the worst responses are gotten when they are told that they are wrong in disliking said things, and that it's all for their own good. Reproducible: always Steps to reproduce: 1. remove some feature users rely on, or change it in incompatible ways, preferably without prior warning. 2. release the modified version with much fanfare. 3. lurk in the said public forums and wait a bit. Comments: #1 by deity: This works as intended, users where designed to operate that way. Closing as invalid.

GNOME 3.4 released

Posted Mar 29, 2012 16:47 UTC (Thu) by micka (subscriber, #38720) [Link]

I think I wasn't understood. Please look at which comment I responded to, and read my answer again.
Actually I don't care, I just meant one doesn't really need to be aggressve towards people that report bugs neither when they file a bug in a tracker nor when they don't.

GNOME 3.4 released

Posted Mar 29, 2012 22:07 UTC (Thu) by blujay (guest, #39961) [Link]

Genius. Classic.

GNOME 3.4 released

Posted Mar 30, 2012 8:00 UTC (Fri) by ovitters (guest, #27950) [Link] (9 responses)

I know it is a joke but still want to say this.

In GNOME Bugzilla we use stock answers. Blaming and/or angry (as well as pointless messages) are not appreciated; either be friendly, or (preferably) use a stock answer (this because the stock answer has been refined over various years to explain everything).

For angry/pointless/blaming messages: You do get some leeway based on your contributions, but I don't care if a developer sends a bad message or a reporter. I don't like either.

GNOME 3.4 released

Posted Mar 30, 2012 8:26 UTC (Fri) by josh (subscriber, #17465) [Link] (8 responses)

Some of the stock answers get a bit insulting as well. For instance, the message that effectively says "we don't know if this bug is fixed or not, but it's old and we've released a new version, so we're closing it anyway". Followed immediately by a bug reporter going "still a bug, reopening it".

GNOME 3.4 released

Posted Mar 30, 2012 9:44 UTC (Fri) by ovitters (guest, #27950) [Link] (7 responses)

Eh.. I don't see that as insulting (I mean: at all)?

Sometimes you just don't know and have to rely on the reporter. Maybe some triagers are overactive in using it. E.g. closing just because of a new GNOME version isn't right. But if the bug is old and/or lots of new development happened in between, then it can be ok to ask if it still applies. But it is up to the triager/developer to make a judgement call.

Bugsquad decides entirely on how it is done in general for triagers. They used to ask the reporter and wait a while (e.g. 6 weeks, 3 months). But they noticed that often there was no feedback at all. So instead of leaving it open ("NEEDINFO"), they're closing it more quickly.

The reporter has the ability to reopen, so don't see anything wrong with this? It should say to please reopen, no?

Anyway, if you have suggestions on the stock answer, could you please email gnome-bugsquad@gnome.org (I tend to ignore LWN articles after a few days; hard to track if not a subscriber)? Or followup now and I'll mention it to them. Entire process change is better if you discuss directly (I'd just be a postman).

GNOME 3.4 released

Posted Mar 30, 2012 10:11 UTC (Fri) by josh (subscriber, #17465) [Link] (3 responses)

I was talking specifically about the practice of mass-closing bugs due to the release of a new GNOME version, without any particular reason to believe that the specific bug has gone away.

I don't see anything wrong with requesting more information on a specific bug and closing it if the reporter doesn't provide that information. I just object to having to babysit a pile of bugs and mechanically reopen them each time someone mechanically closes them.

GNOME 3.4 released

Posted Mar 30, 2012 11:29 UTC (Fri) by alankila (guest, #47141) [Link]

It is a tiring tactic. It is done to ensure that user base approaches 0 as time tends to infinity.

GNOME 3.4 released

Posted Mar 31, 2012 13:34 UTC (Sat) by ovitters (guest, #27950) [Link] (1 responses)

That's happening? It shouldn't be done like that. Care to give pointers?

GNOME 3.4 released

Posted Mar 31, 2012 19:30 UTC (Sat) by josh (subscriber, #17465) [Link]

Sure. I did a quick search for bugs closed with the OBSOLETE resolution, sorted from newest to oldest, and found several recent examples.

This one demonstrates particular rudeness: https://bugzilla.gnome.org/show_bug.cgi?id=671744

These just use the stock template I mentioned:

https://bugzilla.gnome.org/show_bug.cgi?id=672014
https://bugzilla.gnome.org/show_bug.cgi?id=671962
https://bugzilla.gnome.org/show_bug.cgi?id=671894
https://bugzilla.gnome.org/show_bug.cgi?id=671856
https://bugzilla.gnome.org/show_bug.cgi?id=671316
https://bugzilla.gnome.org/show_bug.cgi?id=671099

Valid reasons to close a bug: "can't reproduce that in the current version", or "the entire subsystem you reported the bug against doesn't exist anymore in the current version, and its replacement doesn't have that problem". Invalid reasons to close a bug: "there's a new version and we don't care about the old one anymore", without actually testing that the new version doesn't have the problem, especially when it turns out that it *does*.

GNOME 3.4 released

Posted Mar 30, 2012 14:10 UTC (Fri) by ekj (guest, #1524) [Link] (2 responses)

It's fine to close it if it's been triaged, if there's some actual reason to believe it may no longer apply, such as big changes having happened in the subcomponent with the bug after the filing of the bug.

That's not the behaviour I've been seeing though. Instead what I've seen are mechanical mass-closings of the "This is 9 months old, and we're released a new version, so it's being closed", even in cases where the bug was narrowed down to specific functions that hasn't had a single change in those 9 months.

If they instead put it at "NEED INFO" and didn't get any, in a reasonable amount of time, then okay, fine, close the sucker. But I've never once seen that happen. Instead the bug goes straight from "CONFIRMED" to "CLOSED" with no questions posed.

The routine should be to *either* investigate slightly to see if there's any actual reason to think the bug is probably gone, or else, to atleast ask the submitter "Has anyone tested this with a current release ? Is it still relevant?" *then* close it if 3 weeks later there's been no response.

GNOME 3.4 released

Posted Mar 31, 2012 13:35 UTC (Sat) by ovitters (guest, #27950) [Link] (1 responses)

That shouldn't happen. Please give me the bug numbers or any pointers.

GNOME 3.4 released

Posted Mar 31, 2012 15:34 UTC (Sat) by ekj (guest, #1524) [Link]

I'll see if I can dig up the bug-ids, but at the moment I'm in vacation until april 10th, will look at it when I come home.