Robert Osfield wrote:
Hi Paul,
It sounds like we are now on roughly the same wavelength w.r.t how to progress.
Right, but that is for maintenance of the next stable branch. How about the
current one (2.4)?
I'd suggest going with a branch from 2.4.0 or 2.5.1 (if you want to be
lazy) i,e
svn copy
http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.4.0
http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph-2.4.x
Or name the branch OpenSceneGraph-2.4, or OpenSceneGraph-2.4.series.
I'm open to suggestions on naming of a branch - whatever makes sense
to those browsing the branches.
I'd suggest OpenSceneGraph-2.4. As it is located under /branches, that
should be clear enough.
Or perhaps we should start with an OpenSceneGraph-test branch.
At this point I'd suggest to create the 2.4 branch and allow some people to
backport stuff from the trunk as a first step. When we get to a point where
a 2.4.1 release is viable we can look at the infrastructure needed in terms
of scripts. This first release might even be done by hand to get to know
what is needed and what can be automated.
I can post my simple scripts on the wiki, scripts are good as once you
have one that works reliably you can make releases without worrying
about making typo's at a crucial moment.
I assume these are shell scripts? Should we decide in advance that the
release scripts are targeted at a Linux/Unix system?
Should we support two sets (one for Linux, one for Windows) to support
maintainers on Windows?
For the actual merging from trunk to the stable branch I suggest we take a
good look at svnmerge (http://www.orcaware.com/svn/wiki/Svnmerge.py). This
is a script that assists in the merging process, preventing the same things
to become merged twice among other things. It also keeps a list of revisions
already merged for a branch and has an option to block certain revisions
from being merged. The other nice thing is that it copies the log messages
of revisions being merged, so it's easy to track what a merged revision
actually contained (assuming the original log message was descriptive). The
Python folks use it extensively and seem to be happy with it. Here's an
example log message from the branch being merged _into_, note the two
revisions coming in:
I'll leave it up to you guys to work out what tools.
Another thing that might be useful is watching svn check-ins, as well
as convansing users requests for particular fixes to be merged.
Do you mean the RSS feed? Or is there a separate mailing list?
One thing about the feed that bugs me is that the messages don't contain
newlines (the <body> tag contains a single <pre> tag containing the log
message without newlines). Is this something that can be fixed? They're
really hard to read in the current state.
I can easily make the branch once we decide upon an name, then we'll
need Jose Luis Hidalgo to add logins and write permissions for
yourself, Eric and any others who wish to work on maintaining 2.4.x.
One thing about subversion is that it's relatively easy to set up a
local file-based repository containing some representative files to
experiment with. Perhaps we don't need a test branch, but on the other
hand testing on the actual infrastructure is probably a good idea.
Paul
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
