Quality of PowerTools (was: Del button .. no function)

jv16

Sorry, we encountered an error while displaying this content. If you're a user, please try again later. If you're an administrator, take a look in your Flarum log files for more information.

mrcs

jv16 wrote
...you cannot modify or even see the list.

Thank you.

For clarity sake, I guess the files in the Ignore sub-directory are collectively referred to as the Ignore List (version 1.3). Specifically, the file in that directory I was referring to was "Just to be safe.dat" that contained the following instructions:

//These items are here only to be on the safe side. If

//you carefully check each entry before you remove it

//you can delete this file.

Admin //It's not a good idea to mess with Administartor options.

Component

Firewall

Install

...etc.

So, I was actually looking for a way to remove, not add, items. If you care to, please see my previous post about considering it as an advanced feature for the future.

Thanks again, and looking forward to your next release.

jv16

Sorry, we encountered an error while displaying this content. If you're a user, please try again later. If you're an administrator, take a look in your Flarum log files for more information.

layman

jv16 wrote
Where I am standing there are bugs in every single real software product. Therefore if bugs are a process failure, every single computer software company in the World seem to have this failure or failures in their development process.

Sure. But every defect has a root cause, and the professional developer studies the defect until he identifies its root cause. Once you've understood the root cause, you alter your approach to address that weakness, which helps you avoid repeating the class of mistakes it causes.

jv16 wrote
If there would be a good method of producing even "mostly bug free" software, there would be "mostly bug free" software out there. I for one haven't ever seen any.

Well, I, for one, have seen plenty of software that is mostly bug free. So have you, if you'll only stop and think about it. Gosh, I just rode an operator-less airport shuttle from the concourse to the terminal thanks to software that is "mostly bug free". Frankly, I'm relieved that no one who shares your attitude about process had any hand in developing that software!

Needless to say, you don't need the same process sophistication to develop a simple utility suite like PowerTools as is required, say, to develop the on-board software for the space shuttle. Still, defending buggy software on the grounds that buggy software is ubiquitous is rather like an alcoholic rationalizing that his disease is not a problem on the grounds that alcoholics are numerous.

hanzie

Layman, I totally agree with you.

For me it feels like Macecraft is developing, correcting and implementing the otherway around:

only when reporting bugs you'll get better software instead.

I wonder why the way of reporting bugs has changed?

Reporting this way makes it all - to my humble opinion - less transparant.

And we all know the effect of less transparency ....

Ofcourse the 'bugtracker' is very convenient for the developer, however being and enduser of software you are being cuttoff.

You are cuttoff because you can not read anymore about the way end users deal with the bugs...

You are being cuttoff of bugs discussions...

Many users think - when running into a software problem - that's their own fault.

And in some cases that is true, however in many cases not. (So what now...)

And than we are talking again about the quality of software... :

jv16

layman wrote

Well, I, for one, have seen plenty of software that is mostly bug free. So have you, if you'll only stop and think about it. Gosh, I just rode an operator-less airport shuttle from the concourse to the terminal thanks to software that is "mostly bug free".

With an user interface of an operatorless airport shuttle you can't really tell how bug free its software is, can you really?

layman wrote

Needless to say, you don't need the same process sophistication to develop a simple utility suite like PowerTools as is required, say, to develop the on-board software for the space shuttle. Still, defending buggy software on the grounds that buggy software is ubiquitous is rather like an alcoholic rationalizing that his disease is not a problem on the grounds that alcoholics are numerous.

I am not defending a buggy software. I am only explaining why our products have small bugs but not critical ones.

jv16

Hanzie wrote

Reporting this way makes it all - to my humble opinion - less transparant.

And we all know the effect of less transparency ....

That is true, I'm afraid. But this Bug Tracker is still many times more transparent than with most companies who do not say a word about the bugs in their products. At least in our tracker regular users can even browse through the found bugs.

layman

jv16 wrote
I am only explaining why our products have small bugs but not critical ones.

This is an amusingly illogical statement, Jouni. And it goes to why I, for one, am finally giving up on your work. Except when "error seeding" is employed as part of the testing process, errors in software are all introduced inadvertently. If you could intentionally introduce only small bugs, then it would be possible, intentionally, to introduce no bugs at all. Safeguards only serve to catch critical bugs, not to prevent them. And if the workmanship was shoddy enough to introduce any critical bug in the first place, then it's shoddy enough to build a faulty safeguard.

In any event, when it comes to bugs, 'small' and 'critical' aren't opposites. Your software has bugs that are anything but small, however non-critical they may be. Good grief, man! You have been tinkering with this same basic functionality for ten years or more now. You may put it in a new jar each year, but it's the same stock functionality! Yet, you can release a version of the registry manager with major functional lapses and never even notice! How can anyone have been working on this stuff all these years and not have built up a scheme for regression testing that would prevent this sort of glaring gaffe?

« Previous Page