A defined timeline to merge branches back onto trunk will help too. It's always hard to "finish" a project unless you have a deadline. Even if it isn't complete, you can gain a lot by merging over at reasonable intervals.
Brent Owens (The Open Planning Project) Andrea Aime wrote: > Hi developers, > I have a little suggestion for everyone playing on branches. We all know > branches > are both an opportunity, when opened to explore new paths, and a > headache when > they try to come home. > > For every branch that is not just a playground, I'd like to see the > following: > * a clear cut objective of the branch, that is clearly stated somewhere > and mantained, > should amendments be necessary. A branch that does a single crisp > change has > a much better change of getting back into trunk. > * a changelog that summarizes what has been done on the branch. This > server two > purposes, it allows people to track what's going on without having to > skim thru the > svn commits or svn log, and provides PMC an overview of what happened > when > the developer(s) ask for merger into trunk. > > I know I'm guilty in this respect, me too, but since branches are become > common place > I'd like at least to have them more manageable. > Finally, since both Geotools and Geoserver (with 1.4.x branch) do have a > modular > architecture, think hard if the purpose of the branch could not be > better served with > a separate module (and no need to branch :-) ) > > Any other suggestions in this respect? In my opinion some branch > guideline would > be a nice addition to the developer guide and the development effort itself. > Comments welcome :-) > > Cheers > Andrea > > > > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
