Jesse,
Thanks for adding your view. Please note that some of the views
ascribed to me are at least slight distortions of what I wrote.
Comments embedded.
On Mon Oct 26 11:50:06 2009, Jesse wrote:
Show quoted text> Hi. rt.cpan.org admin here,
>
> One of SQL::Statement's maintainers asked me to jump in here. It seems
> like things have gotten a little antagonistic - and
> that's counterproductive for everybody.
>
> From what I can see, there are a few different issues:
>
> 1) Should maintainers keep a ticket "open" if a bug is fixed in the
> latest version but still present in older versions shipped
> by vendors?
>
> No. You'll want to open tickets in the vendor ticketing systems asking
> them to come up to a current version.
But the bug should be kept open, I'm sure you will agree, while it is
considered if the bug, especially a critical one, might exist in the
latest version. And that such consideration should be done!
Show quoted text> 2) Should maintainers accept bug reports against older versions of a
> module?
>
> In general, we discourage bug reports against older versions of
> modules other than for historical reporting purposes (ie
> close immediately upon report with a note that it's been tested and
> found to work in the current version.)
>
> If a bug exists in the current CPAN version of a module, please do
> report the bug.
Once again, what if the bug is a critical one, in the version being used
by everyone? You suggest, as I do, that the rational approach must at
least include considering if the bug exists in the current version.
It is sometimes difficult for a user to be using the bang-up-to-date
version of a CPAN module. In this module's case no distro has taken a
new release for a long time - until Debian took 1.22 last week. And I
am sure Debian would not have taken 1.22 if they knew there was a
critical bug. And, it has been indicated to me by someone running 1.22,
the bug I reported is in 1.22 as well.
Not that the package maintainer admits this. But all he need do is run
the code I supplied.
Show quoted text> 3) Are maintainers responsible for the versions of modules shipped by
> vendors?
>
> No. Paul, if a vendor is shipping an older version of a module that
> you know to be broken, you should work with the CPAN
> module maintainer to verify the _current_ version shipped and
> supported by the CPAN module maintainer and work with
> the vendor to ship a newer version of the module.
What do you mean by "responsible"? They are not legally or even
primarily responsible. But if they know a version is buggy and they
refuse the filing of a bug report against that version they then become
complicit in not keeping distro "vendors" fully informed and thereby in
supplying dodgy software to users. They share a responsibility here, to
their fellow man, to do good, to refrain from allowing bad to be done
without comment. Sorry if that sounds pompous. Or if it exposes my
disdain for moral relativism.
Show quoted text> 4) Are maintainers required to act on all bugs reported by end users?
>
> No. They are not. Unless you have an outside contractural relationship
> with a maintainer, you need to assume that they are
> a volunteer. Telling them they "must" do something is impolite and
> counterproductive.
Please refer to my initial bug report. And to the response. I am not
going to take responsibility for the initial degeneration in tone.
Show quoted text> Paul, The test code you submitted wasn't in the form requested by the
> maintainer. When he asked you to test against his
> current release or to send a test file in a format that worked for
> him, you refused.
He was not explicit as to what he wanted. Far from it. I supplied a
script. Unpack, cd, run. Whether bug exists in v1.22 or not would be
made plainly evident. He refused to do that. He still has not done so,
as far as we know.
I do not have a 1.22 environment. But I did provide code which, if run,
and if it existed in 1.22. would IMMEDIATELY expose the bug.
It has been difficult for me to assume good faith from the maintainer
here. Especially when it turns out the bug DOES exist (so it is
reported to me by another participant in this discussion) in v1.22.
Show quoted text> It's important to keep in mind that these folks are all volunteers who
> give away their software at no charge. You're asking
> them to do work on your behalf. If you aren't able to help them in the
> ways they ask you to, then you need to ask for help
> rather than complain that you don't like how they're handling your
> issue. It's easy to test CPAN modules locally.
>
http://search.cpan.org/dist/local-lib/ is a tool that will let you
> install a set of CPAN modules in your home directory
> without harming the outdated versions shipped by your vendor.
I have not been paid for making this bug report. So what? Do we do
this for money? No. Testers and bug-reporters ALSO play an important
part in software development.
Show quoted text> -Jesse Vincent
> rt.cpan.org admin
Do we want bugs reported or not? More to the point, do you, Jesse, want
them reported? You and I would at least agree that it is better to
encourage bug reports than not. Better if the bug report is accompanied
by test code. Best if it is accompanied by a patch. But if there is no
patch we still want to know about the bug. Even if there is no test
code supplied, we would still like to know about the bug.
But not HERE, at SQL::Statement.
While advice is being dished out perhaps advice to be more welcoming of
bug reports would be apt. Perhaps advice to try and meet the bug
reporter half way, and to at least attempt to run the supplied test code
against the LATEST version. This advice would be consistent with what
you have written above.
Regards,
Paul
--
Paul Beardsell
