11:41 a.m.
What can be done about a package maintainer with, for lack of a better
term, an ongoing attitude problem?
Here are some examples of interactions I've had with this individual. I
am trying to be circumspect because I'm not trying to engage in public
shaming, but I really need some advice...
The maintainer closed an abrt crash report about a package with
INSUFFICIENT_DATA. He didn't actually ask the reporter of the issue for
any additional information before closing it. I asked why in the bug,
and he responded, "No steps to reproduce = closed bug. Why should we
have to ask as it takes valuable time?" Leaving aside for the fact that
I think he's wrong about that to begin with, I posted my own
reproduction steps in the bug and he didn't reopen it.
I filed another defect about the same package because one of its dialogs
provided several pieces of incorrect information about a particular
configuration setting and how to change it. He responded, "Oh, that
screen is wrong, we don't actually use that configuration setting.
Here's the setting you actually need to use, and how to examine or
change it from the command line." Then he closed the defect with
NOTABUG. I responded and pointed out that surely it was a bug that the
dialog gave incorrect information about both the value of the setting
and how to change it, and surely it was a but that the setting could
only be changed from the command line. He ignored my comment and did not
reopen the bug.
I filed another defect about the same page explaining exactly what I had
done to cause the issue I was reporting. He closed the bug with
INSUFFICIENT_DATA, without any comment about what exactly he found
lacking in my reproduction steps. I didn't try to argue with him,
because, well, I'd seen by this point how much good that would do.
I am reluctant to criticize the volunteers without whom Fedora would not
exist, but at the same time, I think this package maintainer is doing a
poor job of maintaining this package (and, I assume, the others he
maintains), doing a poor job of providing feedback about issues like
this to the upstream maintainers, and scaring away end users from filing
defects about real issues.
Is there anything that can be done?
Thanks,
jik
**
11:44 a.m.
On Mon, Jul 22, 2013 at 11:41 AM, Jonathan Kamens <jik(a)kamens.us> wrote:
What can be done about a package maintainer with, for lack of a
better
term, an ongoing attitude problem?
Here are some examples of interactions I've had with this individual. I am
trying to be circumspect because I'm not trying to engage in public
shaming, but I really need some advice...
The maintainer closed an abrt crash report about a package with
INSUFFICIENT_DATA. He didn't actually ask the reporter of the issue for any
additional information before closing it. I asked why in the bug, and he
responded, "No steps to reproduce = closed bug. Why should we have to ask
as it takes valuable time?" Leaving aside for the fact that I think he's
wrong about that to begin with, I posted my own reproduction steps in the
bug and he didn't reopen it.
I filed another defect about the same package because one of its dialogs
provided several pieces of incorrect information about a particular
configuration setting and how to change it. He responded, "Oh, that screen
is wrong, we don't actually use that configuration setting. Here's the
setting you actually need to use, and how to examine or change it from the
command line." Then he closed the defect with NOTABUG. I responded and
pointed out that surely it was a bug that the dialog gave incorrect
information about both the value of the setting and how to change it, and
surely it was a but that the setting could only be changed from the command
line. He ignored my comment and did not reopen the bug.
I filed another defect about the same page explaining exactly what I had
done to cause the issue I was reporting. He closed the bug with
INSUFFICIENT_DATA, without any comment about what exactly he found lacking
in my reproduction steps. I didn't try to argue with him, because, well,
I'd seen by this point how much good that would do.
I am reluctant to criticize the volunteers without whom Fedora would not
exist, but at the same time, I think this package maintainer is doing a
poor job of maintaining this package (and, I assume, the others he
maintains), doing a poor job of providing feedback about issues like this
to the upstream maintainers, and scaring away end users from filing defects
about real issues.
Is there anything that can be done?
I'd suggest either the person's sponsor or
https://fedoraproject.org/wiki/Community_working_group
-J
Thanks,
jik
**
--
test mailing list
test(a)lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
--
http://cecinestpasunefromage.wordpress.com/
------------------------------------------------
in your fear, seek only peace
in your fear, seek only love
-d. bowie
11:51 a.m.
On 07/22/2013 12:44 PM, Jon Ciesla wrote:
I'd suggest either the person's sponsor or
https://fedoraproject.org/wiki/Community_working_group
How does one find out
someone's sponsor?
I looked at the Wiki page for the CWG, and it doesn't have any
enforcement powers. "Specific anti-duties of the CWG: playing the role
of arbitrator... in a dispute; making judgments in a dispute." Frankly,
I do not think this is a communication issue; I think the only way this
is going to change is if somebody with the authority to do so tells this
individual that the way he's maintaining his packages isn't OK and
compels him to do things differently or find another way to spend his time.
I have little interest in wasting my time engaging in pointless
"mediation" that is just going to boil down to he-said, she-said, i.e.,
me saying, "This is not how things are supposed to be done. Doing things
this way is damaging to the community and to the Fedora project," and
him responding, "Yes, it is. No, it isn't." I've been involved with the
FOSS community for long enough to know how such conversations turn out
when there is no one in a position of authority to make and enforce
judgments.
jik
11:54 a.m.
On Mon, Jul 22, 2013 at 11:51 AM, Jonathan Kamens <jik(a)kamens.us> wrote:
On 07/22/2013 12:44 PM, Jon Ciesla wrote:
I'd suggest either the person's sponsor or
https://fedoraproject.org/wiki/Community_working_group
How does one find out someone's sponsor?
I looked at the Wiki page for the CWG, and it doesn't have any enforcement
powers. "Specific anti-duties of the CWG: playing the role of arbitrator...
in a dispute; making judgments in a dispute." Frankly, I do not think this
is a communication issue; I think the only way this is going to change is
if somebody with the authority to do so tells this individual that the way
he's maintaining his packages isn't OK and compels him to do things
differently or find another way to spend his time.
I have little interest in wasting my time engaging in pointless
"mediation" that is just going to boil down to he-said, she-said, i.e., me
saying, "This is not how things are supposed to be done. Doing things this
way is damaging to the community and to the Fedora project," and him
responding, "Yes, it is. No, it isn't." I've been involved with the
FOSS
community for long enough to know how such conversations turn out when
there is no one in a position of authority to make and enforce judgments.
If you have a FAS login you can look it up there. If not, you could have
a trusted
party who you know does have a FAS account look it up for you.
If you're not sure CWB is the right venue, you could log a Trac for FESCO.
-J
jik
--
test mailing list
test(a)lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
--
http://cecinestpasunefromage.wordpress.com/
------------------------------------------------
in your fear, seek only peace
in your fear, seek only love
-d. bowie
11:58 a.m.
>>>> "JK" == Jonathan Kamens
<jik(a)kamens.us> writes:
JK> How does one find out someone's sponsor?
Look them up in the account system.
https://admin.fedoraproject.org/accounts/group/members/packager and
filter it or go through the list.
JK> I looked at the Wiki page for the CWG, and it doesn't have any
JK> enforcement powers.
Why are you concerned with enforcement powers? What is anyone going to
do to a volunteer in any case? Go to their house and threaten them with
violence unless they maintain their packages in the way you want them
maintained?
The only thing anyone can really do, besides communicate, is to remove
the packager's privileges. Are you willing to maintain those packages
yourself? (And if so, have you signed up to comaintain them?) Is
having them removed from the distribution a better outcome than the
status quo?
- J<
12:30 p.m.
On 07/22/2013 12:58 PM, Jason L Tibbitts III wrote:
Look them up in the account system.
https://admin.fedoraproject.org/accounts/group/members/packager and
filter it or go through the list.
Thank you.
JK> I looked at the Wiki page for the CWG, and it doesn't have
any
JK> enforcement powers.
Why are you concerned with enforcement powers? What is anyone going to
do to a volunteer in any case? Go to their house and threaten them with
violence unless they maintain their packages in the way you want them
maintained?
I am concerned about enforcement powers exactly because I do not think
this is a question of packages being maintained "the way [I] want them
maintained," but rather a question of packages being maintained in a way
that is of net benefit to the Fedora project and community.
I believe that the maintainer in question is, objectively, failing to
follow the Fedora package maintenance guidelines, and in so doing
damaging the project and community. However, I acknowledge that this is
a /subjective/ evaluation of the /objective/ question about whether the
guidelines are being followed, and that pursuing my beliefs further in
the absence of someone who is able to make definitive, authoritative
determinations about them would do even more damage to the project and
community than I believe is already being done.
I've been around the blocks a few times. I know how this stuff works. If
it's just going to come down to me disagreeing with the package
maintainer about how he's doing his job, with no one willing or able to
step in and put a stop to it, then I'm just going to drop it.
The only thing anyone can really do, besides communicate,
There
is a difference between "communication" that comes from one of the
bug reporters this maintainer is shafting and from a disinterested third
party. There is a difference between a bug reporter who has no formal
position within the organization and someone who does. Perhaps the
maintainer's sponsor will be able to talk some sense into him, and I
will pursue that avenue. But the CWG, given that it is self-admittedly
not willing to make "judgments" about the issues brought before it, is
not going to be able to provide the kind of communication that is likely
to improve the situation.
is to remove
the packager's privileges. Are you willing to maintain those packages
yourself? (And if so, have you signed up to comaintain them?) Is
having them removed from the distribution a better outcome than the
status quo?
This is a false dichotomy. There is a third choice, which is trying to
find some avenue that has the potential to convince the maintainer to do
things differently, but settling for him continuing to maintain them the
way he is now if that fails. And there is a fourth choice, which is
seeing if there is anyone else willing to maintain the packages, but
again, settling for the current maintainer continuing if no one else
steps forward.
Frankly, the particular package that I've been attempting to report bugs
about (and, by the way, while this thread was ongoing, the maintainer
closed yet another bug report of main with INSUFFICIENT_DATA without
comment, despite the fact that I described exactly how to reproduce the
issue) is nearly unusable due to several serious bugs (one of which,
e.g., causes /var/log/messages to be spammed with 20MB of log entries
per hour) that the maintainer hasn't shown any indication of intending
to do anything about.
jik
1:55 p.m.
On Mon, 22 Jul 2013 13:30:38 -0400, Jonathan Kamens wrote:
Frankly, the particular package that I've been attempting to
report bugs
about (and, by the way, while this thread was ongoing, the maintainer
closed yet another bug report of main with INSUFFICIENT_DATA without
comment, despite the fact that I described exactly how to reproduce the
issue) is nearly unusable due to several serious bugs (one of which,
e.g., causes /var/log/messages to be spammed with 20MB of log entries
per hour) that the maintainer hasn't shown any indication of intending
to do anything about.
It's kinda silly to try handling it like a secret, because that makes it
even more difficult to comment on it. One can easily search bugzilla for
your email address (using regexp) and find the tickets you've
reported. So, let's get some details:
* https://bugzilla.redhat.com/986938
* https://bugzilla.redhat.com/986935
That package is maintained by three packagers:
* https://admin.fedoraproject.org/pkgdb/acls/bugs/cinnamon
-> https://admin.fedoraproject.org/pkgdb/acls/name/cinnamon
Try to talk to all of them via the PACKAGENAME-owner(a)fedoraproject.org
address. If you consider yourself a part of the Fedora community,
see how you could contribute to improving the packages (e.g. by
signing up as a co-maintainer, so you could apply fixes yourself).
2:06 p.m.
On Mon, Jul 22, 2013 at 08:55:02PM +0200, Michael Schwendt wrote:
This does seem like a horrible abuse of the "insufficient data" close
reason.
On the other hand, I guess it's slightly better than completely ignoring the
bugs forever? Maybe?
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
3:48 a.m.
在 2013-7-23 AM2:55，"Michael Schwendt" <mschwendt(a)gmail.xn--com>:-0s6m5392c
It's kinda silly to try handling it like a secret, because that
makes it
even more difficult to comment on it. One can easily search bugzilla for
your email address (using regexp) and find the tickets you've
reported. So, let's get some details:
* https://bugzilla.redhat.com/986938
* https://bugzilla.redhat.com/986935
That package is maintained by three packagers:
* https://admin.fedoraproject.org/pkgdb/acls/bugs/cinnamon
-> https://admin.fedoraproject.org/pkgdb/acls/name/cinnamon
Try to talk to all of them via the PACKAGENAME-owner(a)fedoraproject.org
address. If you consider yourself a part of the Fedora community,
see how you could contribute to improving the packages (e.g. by
signing up as a co-maintainer, so you could apply fixes yourself).
Should we 'invite' the problem person to this thread?
I think we can let the packager explain why he did that.
Sent from Note I
2:08 p.m.
On Mon, Jul 22, 2013 at 12:51 PM, Jonathan Kamens <jik(a)kamens.us> wrote:
I have little interest in wasting my time engaging in pointless
"mediation"
that is just going to boil down to he-said, she-said,
If mediation is not something you're interested in, because your time
is too valuable (but apparently, the module owner time's is not, as
you feel free to waste HIS time with a bug report that lacks the steps
to reproduce), then what is it that you're asking for? For him to be
removed from the project? Problicly reprimanded? hanged on main
square?
FC
2:21 p.m.
On Mon, 22 Jul 2013 15:08:06 -0400, Fernando Cassia wrote:
On Mon, Jul 22, 2013 at 12:51 PM, Jonathan Kamens wrote:
> I have little interest in wasting my time engaging in pointless
"mediation"
> that is just going to boil down to he-said, she-said,
If mediation is not something you're interested in, because your time
is too valuable (but apparently, the module owner time's is not, as
you feel free to waste HIS time with a bug report that lacks the steps
to reproduce),
??? Jonathan pointed out that he had added reproduction steps to the
tickets. That's why we need to discuss details -> specific tickets.
For example:
> I posted my own reproduction steps in the bug and he didn't
reopen it.
Here it's mandatory to examine how long has been waited between posting
the steps and deciding that the ticket won't be reopened. Further, the
reporter can reopen tickets, too. So, why has the ticket not been
reopened by the reporter? *Then* it would get more interesting, if none
of the assignee/watchbugzilla packagers would respond anymore at all.
2:26 p.m.
On 07/22/2013 03:21 PM, Michael Schwendt wrote:
Here it's mandatory to examine how long has been waited between
posting
the steps and deciding that the ticket won't be reopened.
The maintainer in
question has been active on bugzilla (as noted
previously, he closed two other bugs of mine with INSUFFICIENT_DATA)
/after/ I posted the reproduction steps, so it seems clear that were he
planning on reopening the ABRT ticket based on my additional posted
information, he would have already done so.
Further, the
reporter can reopen tickets, too. So, why has the ticket not been
reopened by the reporter?
In the past, I have been yelled at rather aggressively by
some package
maintainers for reopening tickets which I felt were closed inappropriately.
Certainly not all package maintainers act that way, but some do, and my
recent experience with this particular package maintainers suggests that
getting into an CLOSE / OPEN / CLOSE ... back-and-forth with him would
not be a wise strategy.
jik
2:50 p.m.
On Mon, 22 Jul 2013 15:26:43 -0400, Jonathan Kamens wrote:
The maintainer in question has been active on bugzilla (as noted
previously, he closed two other bugs of mine with INSUFFICIENT_DATA)
/after/ I posted the reproduction steps, so it seems clear that were he
planning on reopening the ABRT ticket based on my additional posted
information, he would have already done so.
You cannot be sure that the assignee (or a co-maintainer) won't reopen the
ticket later, e.g. when noticing a bugzilla notification in a special mail
folder. It could even be that the ticket has been closed by mistake.
In the past, I have been yelled at rather aggressively by some
package
maintainers for reopening tickets which I felt were closed inappropriately.
Aggressively? That's sad to hear, but again, it would need a concrete
example before one could judge about it.
Certainly not all package maintainers act that way, but some do, and
my
recent experience with this particular package maintainers suggests that
getting into an CLOSE / OPEN / CLOSE ... back-and-forth with him would
not be a wise strategy.
Well, then we disagree. Especially when the tickets get closed without
a rationale (= a real comment and not just the Status/Resolution field),
it would be wise to reopen it at least once and wait for the assignee's
reaction. We're not talking about hours here, but days up to a few weeks
before reaching the conclusion that the ticket gets ignored. Only then
you've got usable input for others (e.g. sponsors or FESCo). And, of
course, this gets even more interesting when your ticket contains a
solution.
10:43 a.m.
On Mon, 22 Jul 2013, Jonathan Kamens wrote:
I filed another defect about the same package because one of its
dialogs
provided several pieces of incorrect information about a particular
configuration setting and how to change it. He responded, "Oh, that screen
is wrong, we don't actually use that configuration setting. Here's the
setting you actually need to use, and how to examine or change it from the
command line." Then he closed the defect with NOTABUG. I responded and
WONTFIX
I filed another defect about the same page explaining exactly what I
had
done to cause the issue I was reporting. He closed the bug with
INSUFFICIENT_DATA, without any comment about what exactly he found lacking
in my reproduction steps. I didn't try to argue with him, because, well, I'd
seen by this point how much good that would do.
On Mon, 22 Jul 2013, Jonathan Kamens wrote:
I have little interest in wasting my time engaging in pointless
"mediation"
that is just going to boil down to he-said, she-said, i.e., me saying, "This
There is at least one objective test that can be made:
Someone should try to repoduce the problem from your bug report.
Cannot do it myself. Cannot get past F14.
--
Michael hennebry(a)web.cs.ndsu.NoDak.edu
"Nothing says it like words if you know how to use them."
-- the Professional Organization of English Majors
10:47 a.m.
On 07/23/2013 11:43 AM, Michael Hennebry wrote:
There is at least one objective test that can be made:
Someone should try to repoduce the problem from your bug report.
Cannot do it myself. Cannot get past F14.
ABRT bugs are often intermittent. As I
noted in an earlier email message
in this thread:
...reproduction steps are not the only way that a bug can be tracked
down. ABRT bugs, for example, include a stack trace and a bunch of
other information intended to allow the maintainer to try to track
down the bug even if the user doesn't know exactly what caused the
crash. This is, after all, the whole point of all that data that
ABRT uploads. The maintainer we're talking about closed an ABRT bug
with INSUFFICIENT_DATA seemingly without bothering to look at any of
the ABRT data. Then when I added information to the defect about
what caused that same crash for ME, he ignored it and did not reopen
the bug.
The other reason why it's a bad idea to close ABRT bugs with
INSUFFICIENT_DATA is because ABRT doesn't add CC's to closed bugs, so
it's impossible to find out how many people are being impacted by a
crash bug if you close it.
jik
3 p.m.
On Tue, 23 Jul 2013, Jonathan Kamens wrote:
On 07/23/2013 11:43 AM, Michael Hennebry wrote:
> There is at least one objective test that can be made:
> Someone should try to repoduce the problem from your bug report.
> Cannot do it myself. Cannot get past F14.
ABRT bugs are often intermittent. As I noted in an earlier email message in
this thread:
Are all the bugs under discussion ABRT bugs?
--
Michael hennebry(a)web.cs.ndsu.NoDak.edu
"On Monday, I'm gonna have to tell my kindergarten class,
whom I teach not to run with scissors,
that my fiance ran me through with a broadsword." -- Lily
3:22 p.m.
On 07/23/2013 04:00 PM, Michael Hennebry wrote:
Are all the bugs under discussion ABRT bugs?
All of the bugs
which prompted me to start this thread on the test list
fall into one of two categories: reproducible bugs where reproduction
steps were provided, and ABRT bugs.
There are no bugs in the set which are neither reproducible nor
generated by ABRT.
Having said that, I agree with John Morris
<https://lists.fedoraproject.org/pipermail/test/2013-July/117110.html>
that just because neither came from ABRT nor has reproduction steps
included is not /ipso facto/ justification for the maintainer closing
the bug with INSUFFICIENT_DATA without making any effort to obtain the
additional data necessary to further pursue the bug. Furthermore, as I
pointed out earlier in this thread, the bug status workflow document
<https://lists.fedoraproject.org/pipermail/test/2013-July/117095.html>
agrees with me and John as well.
jik
4:41 p.m.
On Tue, 23 Jul 2013, Jonathan Kamens wrote:
On 07/23/2013 04:00 PM, Michael Hennebry wrote:
> Are all the bugs under discussion ABRT bugs?
All of the bugs which prompted me to start this thread on the test list fall
into one of two categories: reproducible bugs where reproduction steps were
provided, and ABRT bugs.
There are no bugs in the set which are neither reproducible nor generated by
ABRT.
Having said that, I agree with John Morris
<https://lists.fedoraproject.org/pipermail/test/2013-July/117110.html> that
just because neither came from ABRT nor has reproduction steps included is
not /ipso facto/ justification for the maintainer closing the bug with
INSUFFICIENT_DATA without making any effort to obtain the additional data
necessary to further pursue the bug. Furthermore, as I pointed out earlier
in this thread, the bug status workflow document
<https://lists.fedoraproject.org/pipermail/test/2013-July/117095.html>
agrees with me and John as well.
I'm not suggesting that either you or the
maintainer behaved correctly or otherwise.
I am suggesting that there might be one
more bit of objective data available.
If the steps to reproduce (children leave the room) are there now,
you might re-open the bug and put in a "comment" asking
others (plural) to reproduce the bug and report.
If you get a report of successful reproduction,
that would be objective evidence that the
maintainer has the informaion he needs.
--
Michael hennebry(a)web.cs.ndsu.NoDak.edu
"25 And the Lord spake unto the Angel that guarded the gate,
saying Where is the flaming sword which was given unto thee?
26 And the Angel said, I had it here a moment ago,
must have put it down somewhere, forget my own head next.
27 And the Lord did not ask again.” -— Genesis, 3:25-27
2:05 p.m.
On Mon, Jul 22, 2013 at 12:41 PM, Jonathan Kamens <jik(a)kamens.us> wrote:
The maintainer closed an abrt crash report about a package with
INSUFFICIENT_DATA. He didn't actually ask the reporter of the issue for any
additional information before closing it. I asked why in the bug, and he
responded, "No steps to reproduce = closed bug. Why should we have to ask as
it takes valuable time?" Leaving aside for the fact that I think he's wrong
about that to begin with, I posted my own reproduction steps in the bug and
he didn't reopen it.
It seems to me like you don't know how to report bugs. Bug reports
should include STEPS TO REPRODUCE, ALWAYS, it is not "OPTIONAL".
Including the steps after the fact doesn't pardon you for the
incorrect reporting to begin with.
Then you say that you did the same a SECOND TIME... and do you expect
a different outcome?
FC
2:20 p.m.
On 07/22/2013 03:05 PM, Fernando Cassia wrote:
It seems to me like you don't know how to report bugs. Bug
reports
should include STEPS TO REPRODUCE, ALWAYS, it is not "OPTIONAL".
First of
all, I have, in fact, included reproduction steps in all of the
bugs we're discussing here. I am dissatisfied with the way those bugs
were handled exactly because the maintainer closed them with
INSUFFICIENT_DATA despite the fact that reproduction steps were
provided. In short, your interpretation of the events in question is
factually incorrect.
Second, reproduction steps are not the only way that a bug can be
tracked down. ABRT bugs, for example, include a stack trace and a bunch
of other information intended to allow the maintainer to try to track
down the bug even if the user doesn't know exactly what caused the
crash. This is, after all, the whole point of all that data that ABRT
uploads. The maintainer we're talking about closed an ABRT bug with
INSUFFICIENT_DATA seemingly without bothering to look at any of the ABRT
data. Then when I added information to the defect about what caused that
same crash for ME, he ignored it and did not reopen the bug.
Including the steps after the fact doesn't pardon you for the
incorrect reporting to begin with.
Even if you were right that I had reported bugs
without providing
reproduction steps, that would not justify the package maintainer
treating me or any other user rudely and not even bothering to put a
comment in the defect asking for the additional required information.
Maintainers are expected to act like grown-ups and treat users, even
clueless users, with respect. From BugStatusWorkFlow
<http://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow>;: "Bugs can
be closed as *INSUFFICIENT_DATA* by a triager or maintainer if it seems
impossible or very unlikely that the reporter will be willing or able to
provide sufficient information." That is hardly a determination that can
be made by the maintainer when he hasn't even asked the reporter for the
missing information.
Oh, and there's this too: "The /needinfo/ flag is added by bug triagers
or maintainers when adequate information is missing to move the bug
towards resolution." *That* is what the maintainer of a package is
supposed to do when the reporter does not provide sufficient information.
jik
2:47 p.m.
Aside from the people problems, perhaps bugzilla could be changed so
that certain status paths preclude closing the bug?
In my personal experience, I choose to not close *any* bug opened by a
customer - it's up to them to decide if the issue has been resolved to
their satisfaction. Instead, I put it in some "waiting for customer
to close" state so they know the next step is up to them, and let the
system time it out if they ignore it.
Perhaps in this case, any state that implies "waiting on reporter"
would stop anyone else from closing the bug, but let the system time
it out and auto-close it if the reporter ignores it?
So, a maintainer could close the bug if there were a "valid" reason to
close the bug (can't/won't fix, already fixed, dup, old version, etc)
but not if they just didn't have enough information to reproduce it
(can't reproduce, need-info, missing abrt file, etc).
2:49 p.m.
On 07/22/2013 03:47 PM, DJ Delorie wrote:
Perhaps in this case, any state that implies "waiting on
reporter"
would stop anyone else from closing the bug, but let the system time
it out and auto-close it if the reporter ignores it?
This is exactly how
/needinfo/, which we already have, is supposed to work.
jik
2:56 p.m.
On Mon, 2013-07-22 at 15:47 -0400, DJ Delorie wrote:
Aside from the people problems, perhaps bugzilla could be changed so
that certain status paths preclude closing the bug?
In my personal experience, I choose to not close *any* bug opened by a
customer - it's up to them to decide if the issue has been resolved to
their satisfaction. Instead, I put it in some "waiting for customer
to close" state so they know the next step is up to them, and let the
system time it out if they ignore it.
Perhaps in this case, any state that implies "waiting on reporter"
would stop anyone else from closing the bug, but let the system time
it out and auto-close it if the reporter ignores it?
So, a maintainer could close the bug if there were a "valid" reason to
close the bug (can't/won't fix, already fixed, dup, old version, etc)
but not if they just didn't have enough information to reproduce it
(can't reproduce, need-info, missing abrt file, etc).
This would work out horribly in practice.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12:45 p.m.
On Mon, 2013-07-22 at 15:05 -0400, Fernando Cassia wrote:
It seems to me like you don't know how to report bugs. Bug
reports
should include STEPS TO REPRODUCE, ALWAYS, it is not "OPTIONAL".
[voice=droll]
So is is your stated position that intermittent or hard to reproduce
bugs are 'someone else's problem' or are you asserting they they don't
exist? Either it sounds kinda retarded, sir.[1]
If the reporter knows how to reproduce a bug, of course they should
report that. But an unexplainable failure is still a failure, and a
report at least begins a conversation and provides an entry point for
future reporters to search on and add to, eventually the hope being to
collect enough clues to point to a solution.
In a perfect world every bug report would include a complete breakdown
of the problem. Or heck, if we are wishing we could just assume every
user is a skilled developer who can code in every language, understand
the OO.o, Firefox codebases AND troubleshoot ACPI bugs in the kernel and
every bug report could be expected to include a patch as well. Or why
not assume that every user is a registered Fedora dev and can just
contribute a fixed package and we could eliminate bugzilla entirely. In
reality even a bad bug report is better than silence, at least a bad
report indicates that there is likely to be a real problem, even if it
can't be solved yet.
[1] Those not following recent U.S. news probably won't get the cultural
reference. It's just a bad joke, not a flame. (A pot, kettle sorta
gag.)
3971
days inactive
3973
days old
23 comments
11 participants
participants (11)
-
Adam Williamson -
Christopher Meng -
DJ Delorie -
Fernando Cassia -
Jason L Tibbitts III -
John Morris -
Jon Ciesla -
Jonathan Kamens -
Matthew Miller -
Michael Hennebry -
Michael Schwendt