On Tue, May 1, 2012 at 2:28 AM, Pedro Giffuni <[email protected]> wrote: > On 04/29/12 23:55, Juergen Schmidt wrote: >> >> ... >> >>> >>> I think it all depends on how fast we plan to release 4.0. >>> It looks likely that merging Symophony may be easy for the >>> IBM guys, since symphony already updated theit base OOo, >>> so a release may be fast and the 3.x branch may be short >>> lived. (I don't know for sure though). >>> > > One thing here that I should've mentioned is that it's rather > inconvenient that we will not have the symphony history. It > would've made it much easier to merge features. >
This can be discussed when the code is available. > >>> I think a 3.x branch does make sense in any case but the >>> rule should be clear: no direct commits to the stable >>> branch: in general all changes go first to the trunk >>> and are later merged. >> >> I don't think so, I would do it exactly in the other direction. Fixes for >> critical issues or issues that are assigned for a 3.4.1 should be fixed on >> the related stable branch and also merged into trunk. >> > > Well, developing an OS is different than developing an Office > Suite but direct commits to the stable branch in my favorite > OSS project are prohibited except for specific cases (like if > the code disappeared from trunk already) for good reasons. > > For one thing we are many committers and it's easy to lose track > if the change was merged to the trunk so it is a good policy to > ensure consistency in the different versions. It also keeps > the SVN merge properties consistent. I am by no means > a SVN expert but it's likely that using "svn merge", instead of > "svn commit" in branches is the recommended practice. > > Just my $0.02, > > Pedro. >
