Reporting bugs in corporate-sponsored CPAN code

[Tanktalus]

I had a weird situation arise yesterday. I was using a CPAN module that actually was released by $work (and not me) as an officially-supported module. And I had problems with it in a not-$work-related usage. So the first question that arose in my mind was where to report this. Internally, where, in my case, it would get higher visibility and more likely to be fixed in a timely manner, or externally so that others that may be affected would see the problem was already reported?

In my case, I decided to report internally, and provided a short patch (minimal changes) as well as a longer patch (taking care of other stylistic issues that provided a more perlish long-term solution). I'm curious, though, how others have dealt with this, or would deal with it were it to happen, or just what the community would generally prefer?

[almut]

...where to report this. Internally, where, in my case, it would get higher visibility and more likely to be fixed in a timely manner, or externally so that others that may be affected would see the problem was already reported?

Why not report both internally and externally? That way, everyone affected would be informed, chances of getting it fixed in a timely manner wouldn't be worse than when reporting either internally or externally alone, and once the issue is fixed, you could simply update/close the bug report in both places...  Or have I misunderstood something?

[Your Mother]

I think only internally is fine as long as the bug will be fixed and released right away and the problem noted in the Changes. Otherwise I'd do both as almut suggested so you don't waste some poor hacker's weekend tracking it down, confirming it, writing a patch, etc.

On a tangent: thank you (and GrandFather and everyone else) so much for working on stuff and encouraging your office to work on stuff which is released to the wild. Companies that do this look good to me and I would patronize them before another were all else roughly equal.

[GrandFather]

I have a couple of modules in CPAN that are in a somewhat similar category. One of them is a mission critical component at $work and is maintained in like fashion to all our other software using our internal bug reporting and tracking mechanism. From time to time I roll up the work changes in the module and include them in an update to the CPAN hosted version with appropriate entries in the change history.

Recently I've had a couple of bug reports come in through RT which I handled at home. Those changes will find their way back into the work image of the module next time I'm working on it at work.

[Joost]

Personally, any module that's released via any work-related entity that I run into trouble with I patch and release publicly ASAP. That's just the most efficient way of dealing with it, but that's just because I'm usually the public maintainer of that code. When you're working with a large group so that changes may take more time, it might be a good idea to put the bug (and possibly patch) in whatever public ticketing system is the most useful - rt.cpan.org is available for all CPAN modules, but if you have your own system, it may be better to use that.

Aside from that, if you're putting up modules as "open source", I just want to plug http://github.com as a code repository. It makes publicly forking / patching other people's code a breeze and gives you a very clear view of whatever other people are doing with the code.

edited to add: my repos @ github

[JavaFan]

I'd say what you should depends a lot on information that you aren't providing. What does your $WORK do with external bug reports? What does $WORK do with internal bug reports? How does $WORK appreciate internal bug reports that actually don't affect $WORK? Who's maintaining $WORK module? Is the CPAN version the same as the $WORK version? Can you just fix the bug and check in the code? Can you just walk up to the desk of the person who made the module and ask her/him to fix it?

[Tanktalus]

Of course, answering those would only be helpful for my particular case. That said, I'd point out that in my case, the development of said module is corporately motivated (we don't sell the module - but we do sell the code that the module provides an interface to). And I do not have anything to do with development of said module, though I like to beat them about the head once in a while when it stops working for me. It was just this week that I realised that this may not be the community's preferred method, even if it provides me with a sense of temporary relief ;-)

I have access to open internal bugs. I do not have authority to modify the code (i.e., I can, but that's due to a lack of control from the version control system, not because I'm supposed to, and there would be repercussions if I did). The $WORK version's sole purpose is to escape $WORK and be used by customers of the main product line, so I hope it matches CPAN, though I expect some sort of delay.

And, no, I can't just walk up to their desk. For starters, I work from $HOME. Second, the development of said code has moved from our primary location to a location in the US. And from there, to India. (And I've not been picky - I pestered the developers that owned it back when my former team lead switched positions and took it over, as well as when it went to the US, and again in India - I'm an equal-opportunity basher, and I've not found one group particularly better or worse than another.) Getting to said desk would take all day. And a few grand.

I guess the most important question you posed is what they do with external bug reports. The thing is, I don't know. That's a good question, and I should pose that to them next week. Thanks for that bit of the obvious: sometimes the obvious isn't so much when you're inside the box ;-)

[CountZero]

I guess the most important question you posed is what they do with external bug reports. The thing is, I don't know.

I thought that one of the reasons why companies release software as open source is that it instantly gives them a free user and test-base and solutions to bugs may be "donated" to their software without costing them much. So, external bug reports should get equal --if not more-- attention than internal ones. One could even consider publishing the internal bug-reports on the external bug-tracker, in the hope that it gets solved faster and cheaper than doing it themselves.

It probably also depends on whether the company still has an active team available dealing with the development and maintainance of this software.

[JavaFan]

Of course, answering those would only be helpful for my particular case.

Well, I would say your answers are only helpful in your particular case. But I think anyone who has a choice between reporting something internally or externally and who is wondering how to report a bug could benefit from thinking about the questions I raised. I don't think there's a general answer - each case will be different.