From: Julian F. <ju...@be...> - 2002-12-22 10:34:48
|
I favour the same thing. It will be a bit hard on people upgrading... but 0.18 involves massive numbers of changes... we might as well get them all at once! Not sure if that logic really holds as far as users are concerned... but hey, you gotta clean things up some time and it's only going to get worse. Any thoughts on what the standards should be? If we come up with a list, we might be able to get people to start submitting patches to rename the config options (in small chunks). We also might want to add a bit more utility to the obsolete.php file. Indicating whether the variable is just renamed or whether they should actually look at the manual for info on how the new option works would be useful (like in the cases where we replaced 3 variables with 1 new one, you'd want to actually look it up). Presumably, we can just have a couple of different functions to call to indicate why the option is obsolete. Julian Victor Boctor wrote: > Hi Julian, > > I totally agree. I didn't like the name that I used > ("reminder_recipents_monitor_bug"), but I didn't like the "store_reminders" > either. I was actually going to raise the same issue, but you did it first! > > I was thinking that we should go through all the configs before releasing > 0.18.0 and change them to match a standard that we agree on. This should be > done before we start the testing. Of course all the old names should go > into the obselete.php. > > >>-----Original Message----- >>From: man...@li... >>[mailto:man...@li...]On Behalf Of Julian >>Fitzell >>Sent: Sunday, 22 December 2002 8:23 PM >>To: man...@li... >>Subject: [Mantisbt-dev] config option names >> >> >>I'm going to take this opportunity to raise this issue because I keep >>wondering about it. Are we happy with the config variable names? >> >>I realized that we don't want to rename them all if we can avoid it >>because it makes more work for people upgrading. But maybe we should at >>least give it some thought. There are at least 23 new config options >>since our last release and we are adding them at a fast rate. We are >>moving towards having standard prefixes for api functions... should we >>try to do something similar for config options (at least for now ones)? >> >>For example, relating to the bug reminder stuff, we now have: >> >>bug_reminder_threshold >>store_reminders >>reminder_recipents_monitor_bug >> >>We have both singular and plural forms of reminder. In two cases we >>mention bugs, but not in the others. The order is inconsistent. >> >>Should we, for example have these names instead: >> >>bug_reminder_send_threshold >>bug_reminder_store (or bug_reminder_add_bugnote) >>bug_reminder_recipients_monitor >> >>It seems to me that something like this would make config options easier >>to find and easier to remember (I know I can never remember any of the >>names when people ask questions on IRC... I have to look them up every >>time). >> >>But should we group all the thresholds together or group them with what >>they do? >> >>Anyway, I think it would be worth discussing this. Even if we don't >>want to change them all now or ever, we could at least try to make all >>the new ones we are adding follow some pattern. Every time I create a >>new config option I have no idea what to call it. And I think everyone >>else does the same. They just make something up and commit it. >> >>Julian >>-- >>ju...@be... >>Beta4 Productions (http://www.beta4.com) >> >> >> >>------------------------------------------------------- >>This sf.net email is sponsored by:ThinkGeek >>Welcome to geek heaven. >>http://thinkgeek.com/sf >>_______________________________________________ >>Mantisbt-dev mailing list >>Man...@li... >>https://lists.sourceforge.net/lists/listinfo/mantisbt-dev >> > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Mantisbt-dev mailing list > Man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev -- ju...@be... Beta4 Productions (http://www.beta4.com) |