You've been referred to this page because you've been granted commit access to our Subversion repository.
Rosegarden is a large and complex project, and we depend on volunteers like you to make it happen.
Thanks for participating in Rosegarden development, and welcome to the team!
1. Developers should strive to ensure that trunk/ always compiles and makes a reasonable attempt to run. Once we approach a release, we will fork off a stable branch for that release, so trunk/ never has to be pristine and perfect. However, you should make a reasonable effort to be a good neighbor, and try to keep trunk/ in a state where it always builds and always runs with at least most of its features intact.
One common source of breakage is where one developer adds new files that are called on by other files, and forgets to add those files before committing changes. Now, thank you very much, the entire repository is broken for everyone. It is especially obnoxious when someone does this right before going to bed, or to work, or worst of all, on vacation/holiday, where they can't be reached to correct the problem for hours or days.
Another common source of breakage is where one developer fires off a few incidental lines of code without testing to notice that they cause the entire application to crash at startup, or they break the notation editor completely, etc. This kind of thing is impossible to avoid completely, but making a reasonable effort to do some sanity checking before a commit is a good neighbor policy.
If your work is highly likely to cause problems for other developers while it is under way, then please consider doing the work in a branch instead. See Working with branches.
2. Follow the published Coding Style guidelines as closely as possible. Most particularly, if you ever think about running the codebase through a code reformatter, don't. Do feel free to adjust any code you run across that does not conform to these standards though. Most particularly, if you find tabs or bizarre indentation, this is probably the result of the bad old days when we had no formal guidelines, and these problems need to be corrected.
3. If you do any work with layouts, please read the guidelines for Qt Layouts, and you might read about QSettings config groups while you're at it too, though both of these documents are also linked at the bottom of the Coding Style document.
If you're not already subscribed to rosegarden-bugs@lists.sourceforge.net you should consider subscribing. This list tracks activity from bug reports, feature requests, commits, and changes to the wiki all in one place, and a lot of things go on which you can keep up with through rosegarden-bugs but might get no hint of if you only follow rosegarden-devel and rosegarden-user.
You've found the wiki. While you're here, you should create an account. We use the wiki for all kinds of things, such as user documentation, development notes, electronic napkin drawings, and so on. You might want to have a look from the main page to see how it's all laid out, and if you have any grand ideas about how we can make the wiki better and more productive, then please jump in. I feel like it all has a lot more potential than anything it has really lived up to so far.
Most particularly, I'd be very interested in porting all of our user documentation to this wiki.