Our config file requirements are really really simple; we should be able to read off a name/value pair rather than having perl do it, which is possibly insecure.
Unloved bugs targetted for 2.18 but untouched since 9-15-2003 are being retargeted to 2.20 If you plan to act on one immediately, go ahead and pull it back to 2.18.
I think the whole params section should not be in a file in the first place. Everything is in the database so the params should be there as well in a new table called params and read from there. Why have a database when we would continue to use files to store data?
This bug has not been touched by its owner in over six months, even though it is targeted to 2.20, for which the freeze is 10 days away. Unsetting the target milestone, on the assumption that nobody is actually working on it or has any plans to soon. If you are the owner, and you plan to work on the bug, please give it a real target milestone. If you are the owner, and you do *not* plan to work on it, please reassign it to email@example.com or a .bugs component owner. If you are *anybody*, and you get this comment, and *you* plan to work on the bug, please reassign it to yourself if you have the ability.
Reassigning bugs that I'm not actively working on to the default component owner in order to try to make some sanity out of my personal buglist. This doesn't mean the bug isn't being dealt with, just that I'm not the one doing it. If you are dealing with this bug, please assign it to yourself.
(In reply to comment #2) > new table called params and read from there. Why have a database when we > would continue to use files to store data? Some parameters are required even when the DB is down, see bug 398075. We had this discussion in the developer mailing-list already.
If someone can write your data/params file, I think you've already lost. Gerv