It's the ideal. Inkscape is more anarchistic and has many people committing to trunk directly, which opens us up to conflicts (and isn't ideal) but we don't have a lot of resources for peer-review.
Here are some tricks I picked up dealing with conflicts of trunk committing:
Use `bzr pull` before you commit. Use `bzr push` right away. Thus only commit working code.
If your commit mis-times and you diverge from trunk:
Uncommit all of your commits using `bzr uncommit` Then `bzr pull` to sync up Then `bzr commit -m "foo"` again to get your commit in after.
Pay attention to any merge conflicts when you do pull requests.
Try not to do `bzr merge parent/lp:inkscape` because you'll then be committing someone else's work as if you merged it for them. Especially several someones.
Also help with any merge requests that come in, it's a good way to know more code I find and maybe we can make inkscape more ideal.
Martin,
On Tue, 2013-06-25 at 15:35 +0200, Christoffer Holmstedt wrote:
hmm, that workflow is what I use today (when I don't have access to trunk), do everyone do that within the Inkscape development process so all additions get peer reviewed?