On Saturday 02 June 2007, Arnout Engelen wrote: > Hi, > > I have some transposition cleanups and functionality (including a > transposition toolbar for the notation view for quickly switching > transposition (default off)). > > I'd like to commit them for some broader testing and feedback, but the > code does trigger an unresolved bug (the BasicSelectionCommand thing I > mailed about earlier).
I read that. I have no idea what to do about it. All of that is completely unfamiliar to me, and the last time I fooled around with selection-related things, Chris had to bail me out. > What's the rosegarden `policy' for this kind of situation? Can I commit > away or should I rather post a patch to the lists/trackers? As a rule, it's bad form to commit anything to trunk/ in a situation where you know for a fact that there is a nasty bug waiting for someone else to trip over. The usual thing would be to commit experimental code to a branch, and work out the problems there before merging the code into trunk/. In this case, it looks like the only way anyone will run into the problem is to use your new feature. If it's the kind of thing were we could just comment it out of the .rc file prior to a release if it isn't working yet, then I think it would be fine to commit it to trunk/ anyway. Why bother with a branch nobody would be likely to look at? > What are the current plans in terms of release cycle, are we in > 'development mode' or 'bugfixing/polishing mode'? :) I'd say we're in "whatever you're willing to do would be most appreciated" mode. It's generally a good idea to get some kind of concensus (I'd call a "concensus" a positive response from at least two other established developers, and no serious dissenting opinions voiced) before getting started on anything controversial. All kinds of things can be controversial around here. It can be a complicated and frustrating game. Right about now, I think I'd be inclined to push the envelope as far as I wanted, and risk stirring things up. Maybe you can get a fire started, and give this rolling ball some momentum again. It never really has stopped, but you have to use a stop action camera to see it moving right now. I would say that unless we really go get up a good head of steam where the whole project is moving somewhere purposefully, then it's probably best to try to keep trunk/ in a perpetually releaseable state. It seems likely that the next big head of steam we manage will be when we port to KDE4, and that is a ways off yet. Until then, I don't see a problem with something like what you're working on, so long as it can be easily hidden from the users if we decide to release before it is working properly. (We have a lot of code in this category already. Some of it so old and out of touch that it's probably never going to be worked into a functional state at all.) -- D. Michael McIntyre ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
