2008/9/9 D. Michael McIntyre <[EMAIL PROTECTED]>: > On Tuesday 09 September 2008, Chris Cannam wrote: >> Can we pause to agree on a definite policy for this kind of change? > > Yes, let's. > >> What do we think of this kind of thing? On the one hand it should >> permit building the application sooner; on the other hand it risks us >> leaving a feature incomplete and forgetting ever to restore it >> (especially if it's a subtle one). > > I think this is in a different category from what I intended the //@@@ markers > to mean. This is pretty serious, and I would prefer to avoid ever doing this > at all, if possible. It's better to try to get help first. I've certainly > seen plenty of things where I could have gotten the file to build by cutting > the tricky bits out, but there isn't a lot of point in that in the long run. > > Actually, in a way, I did the same thing myself with the QProgressBar stuff. > My code is an empty skeleton that won't do anything other than compile > successfully, but I'm going to fix that ASAP. Hopefully this very night, and > I certainly won't forget. > > Emanuel said: > >> I agree, we should preferably avoid deactivation, but in some cases it >> still might be suitable. > > Avoiding deactivation should be a very strong preference. > >> - I see as main target : port rg to qt4, make it work >> >> - Some errors may be easier to debug having a running rg-version. >> (I'd like to be shure to do it right, or not at all - I (or anyone) >> would have to came back to it anyway..) > > This is a valid point. I have seen many things where it will be hard to know > if we got it right until there's actually a running framework around which to > test the code. > >> Let me suggest to use >> "//@@@ deactivated!" > > Let's use //&&& instead. This isn't in the "this might cause problems, look > here first" category, because it's certain to cause problems. > > I'll try to create a wiki page and put all of these // codes on there RSN. > >> Let's use it rarely though, and better ask the list for a solution, if >> we are not able to do it ourself. > > Yes. I won't make it an absolute rule, but I think as a guideline anyone > should wait at least a day or so for comment on something like this before > going off to //&&& something out. Especially if they don't have a pretty > clear and immediate plan for putting the code back. > > As an example, I've figured out how to approach the QProgressBar stuff, but > just haven't had time to do it yet, so the empty skeleton is still in there > for now. This is different from not having a plan at all. I'll only mark it > with //&&& if my plan doesn't work out, and I have to wait until the code is > actually running to figure it out. > > Does this sound reasonable to everyone? > Yes, I agree with your suggestions.
I already added some comments to the wiki at: http://rosegardenmusic.com/wiki/dev:rg_qt4_task_list before I read your mail. Please adjust it as appropriate. I noted, there are already a lot of //!!! notes. Maybe we should use yes another comment for minor notes, in the process of conversion ? //### ? Sincerely Emanuel ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
