[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RDD] definition of bug reports and feature requests (was re: First time install - infinite loop in rdadmin around MySQL)



On Tue, Jul 14, 2009 at 8:33 AM, Michael <mbarnes@xxxxxxxxxxxx> wrote:

I'm not trying to sound nasty, but IMHO, a user who does not follow
directions or makes assumptions and adds steps not warranted or out of
sequence is not a basis for a bug report. The program is working
properly, there is no bug.  It is user error.

No offense taken. As a professional software engineer, I am of the opinion that minor user error should not cause the program to lock up silently and forever, with no logging, error reporting, etc. There should be a graceful exit, some sort of logging or error dialog. Programs - particularly those outside of the direct serving path (such as rdadmin) should be fault tolerant, rather than fault susceptible. I'm not suggesting that the program should be able to read the user's mind, of course (especially one with an freewheeling mind ;) ) but just that it explain itself once in a while.

As for unwarranted steps, by far the common install pattern for software that uses MySQL (or Postgres, etc. etc.) is that the db admin creates the database, and does not delegate create database/drop database rights to the non-admin user. I'm not so thrilled at the idea that the code here could just run "DROP DATABASE rivendell;" at its whim. Sure, it could also just DROP TABLE everything, but I find that about one order of magnitude less likely. The security/sysadmin part of my role wishes to limit user actions according to the principal of least privilege. Given the output of `grep -Ri "DROP DATABASE" sourcecode_dir` I am inclined to remove unnecessary privileges going forward, only restoring them temporarily when a schema upgrade is pending.

I agree that I did not follow the instructions to the letter, and I will do my best not to introduce outside assumptions into what I do, even if it deviates from common/best practice. When it does do so, can I file a feature request, or is this something that the team is not interested in hearing about?

Perhaps this is a question better asked of the development list, but along those lines, since it hasn't been commented on - is there an active bug tracker? Does the development team accept placeholder feature requests? Personally I don't care whether filed bugs are reprioritized to bulk, filed bugs are moved to a feature request queue, or they're closed as "will not fix." I'm used to working in software communities where filing bugs, code reviews, feature requests, and so forth are looked at as a positive contribution to the community, rather than an assignment of blame, frustration, or fingerpointing. If it's viewed as the latter here, I would like to know that upfront. If I do in fact encounter unexpected behavior, I would like to have the ability to file a bug, in order to defer to the prioritization and knowledge of the development team. If upfront bugs are unwelcome, but patches are, I'm happy to do that as well - the issue becomes that a non-core developer might write a patch only to have it rejected because there wasn't any communication during development of the patch.. or someone else may already be working on a patch, so there's wasted effort.

-Andrew Widdowson
KZSU Engineering

_______________________________________________
Rivendell-dev mailing list
Rivendell-dev@xxxxxxxxxxxxxxxxxxxxxxxx
http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev