On Sun, 2008-08-31 at 02:50 +0300, Mika Hanhijärvi wrote: > On Sat, 2008-08-30 at 20:12 +0100, Neil Williams wrote: > > > > And it's not > > > just one option which noneone uses. it's quite likely that many users > > > will try to run program that way and then it crashes. > > > > Actually, a lot of programs need to be tested in different ways, > > providing options and passing files on the command line. > > You can do that directly from Anjuta too.
It is far more work to arbitrarily set options and commands on a rotational basis - e.g. where a program has a few dozen command line commands/options/permutations. (Yes, I do have a program like that, there are also many others.) > > I use Anjuta for six or seven upstream C projects - not once have I > > needed to execute the program from the Build menu - it is almost never > > appropriate. > > If you want to lower the severity then do so. (I already did.) > But if the only reason is > that YOU don't need that feature then I really don't understand. You > really should not try to decide what feature users need or want to use, > just make the damn thing work. The reason for lowering the severity is that equivalent alternative functionality is already available within the program and within other programs that would exist on the same system which do not require any specialist knowledge to use and which give directly equivalent (some would argue more useful) results and feedback to the single (convenience) mode that is broken. Therefore, as this is only one option out of many that is broken, the bug in that option cannot be deemed to render the package unusable because the package itself provides a fully equivalent alternative. In reportbug, this comes under the problem "a bug in a single option that does not prevent use of the entire program" - i.e. normal severity. I've left it as important because the bug does cause a crash which (temporarily) makes Anjuta unresponsive but this crash is avoidable (not using the option from the Build menu) both within the program and using external tools that necessarily exist on the same system. The crash does not cause data loss or damage the filesystem in some other way, the crash does not (in and of itself) have any extraneous consequences (with the possible exception that Anjuta might not have gotten around to saving a file but that is inevitable with any crash). Therefore, the bug remains open because it should be fixed, eventually. Upstream are aware of it and there is some discussion about whether the bug is in Anjuta or libvte9. (i.e. if this bug was to be RC, it could quite easily cause the removal of the WRONG package). The mere fact that anjuta crashes due to this bug does not make the bug RC. A crash is a crash - important and something that needs fixing - but unless it has certain other features (like being unavoidable, on startup or similar) then it is not necessarily release-critical. Certainly, elements of the anjuta crash are evident in other programs using libvte9 and updating libvte9 to a later version does help with one of those other programs but I was still able to reproduce the anjuta bug with that later version (but that might just mean that vte upstream have fixed part of the bug but another element of this bug still exists in vte which is causing anjuta problems). vte has a difficult task and has quite a lot of bugs as a result. > > Not at all - it is vital to be able to pass arbitrary options that > > change with each test. > > As I already said you can pass options to program directly from Anjuta > too. Actually, it is simply impractical when testing a program that has more than a handful of command line options - particularly when the command line options take filenames and testing a particular function can require multiple tests with multiple filenames passed in combination with multiple other options. bash history was invented for stuff like that. The problem of trying to execute build tests also means that the Build menu option is less than useful to many projects. However, you quite nicely made my point that equivalent functionality already exists and that the Build menu option is optional. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
signature.asc
Description: This is a digitally signed message part
