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? -- D. Michael McIntyre ------------------------------------------------------------------------- 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
