Description of problem: I just tried to compile package balsa-2.2.4-1.FC3.1 from Redhat Fedora Core 3. The compiler said main.c(489): remark #592: variable "mbnode" is used before its value is set The source code is BalsaMailboxNode *mbnode; g_return_val_if_fail(mbnode, FALSE); I agree with the compiler. This code would benefit from rework. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Then by all means file a bug report with the upstream project that owns the software: http://balsa.gnome.org. Compiler warnings in external software are not the type of problem that makes sense for us to fix, the cost/benefit is not justified.
>Compiler warnings in >external software are not the type of problem that makes sense for us >to fix, the cost/benefit is not justified. Dozens of other folks at Redhat have a different opinion. I get bug fixes from them. What's different about balsa that makes obvious bugs hard to fix ?
> Dozens of other folks at Redhat have a different opinion. > I get bug fixes from them. Well I don't know who you are, but it sounds like you're upstream, thats the difference. It's much easier to inform upstream of issues that should be fixed than it is for us to create the equivalent of an ECO (Engineering Change Order) and track all this ourselves. > What's different about balsa that makes obvious bugs hard > to fix ? Because we have to create the patch, distribute the rpm, send the patch upstream so on the next release we don't have apply the patches again (many patches don't apply cleanly on subsequent upstream releases). Track the process of the patch, probably open an upstream bug report for the patch, track that, etc. It's a lot of work for us and it could be handled directly upstream without our involvement. We have to pick and choose what we spend money on, compiler warnings on a second tier mail client do not trump much more serious bugs or bugs in our primary mail client, I'm sorry if that sounds harsh, I don't mean to be, it just the way it is :-( You should proably know that Balsa is a very low priority, if we can just rebuild it great, but if it consumes any significant engineering resources its going to get pulled from the distribution and I don't think that serves your interest. There is a significant Balsa bug open now where it crashes, that needs attention that has be hard to find, compiler warnings given the current scenario don't pass the sanity test. Once again I'm sorry, please accept my appology, but going upstream will be vastly more productive in this instance.