Hi all, Having been working on a branch I might have one or two things to add :). I had a huge rant all planned but then realized that that is not the point of this thread.
So to save you lots of reading I will just submit my suggestion. I would like to see the project more reluctant to letting people branch. As an alternative perhaps the project could allow for more "unstable" development. It might tick people off short term but in my opinion a bit of annoyance is better then having someone lose 6 months of work, and never having that work recontributed back to the core. I know that this has been proposed before but perhaps we could adopt a scheme in which odd numbered releases are "unstable", during which R&D is allowed on trunk. -Justin 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 > > !DSPAM:1004,448c171c43302095110867! > -- Justin Deoliveira The Open Planning Project [EMAIL PROTECTED] _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
