Hi Paul,
I'm top-posting because I totally agree with all your points. You'll
notice I replied to all suggestions, whether they involve changes in
process or tools or infrastructure. Any of those might help, and the
total gain we need might not come from any one solution but from a
combination of solutions whose gain alone would have been less interesting.
I think as a community we have enough people to be able to investigate
many things at once. What we need to do is to investigate instead of
*talking* about investigating... Because in many cases predicting the
learning curve is very hard. And people need to be objective and see the
downsides as well as the good points.
J-S
On 2/23/2010 3:45 PM, Paul Martz wrote:
Jean-Sébastien Guay wrote:
Hi Chris,
I am very hesitant about changing our wiki and VC hosting. While what
we have is not
perfect, it works 99% of the time, and is mostly under our control.
Changing to a new
platform involves MORE work, not less, and we don't really know the
reliability and
performance of the new platform. This worries me greatly. We've had a
lot of bad
situations before and what we have now, while imperfect, is still
closer to perfect than
anything in the past, and I'd rather not risk going backwards.
I'd normally agree with you wholeheartedly, but we've had more server
problems in the last few months than in the year or two before, and
that's what makes me think that the current platform might not be up
to the task of supporting the amount of traffic we ask it to. Plus,
control is good but an established service might have guarantees of
reliability, redundant backups/load-sharing, etc. which would be too
much to manage ourselves.
I'm not saying we should go and change everything, just that we might
want to investigate and that another solution might work just as well
while offering some guarantees. We can investigate without committing
ourselves to anything. We have some time anyways, if we want to wait
until after the next stable release to decide and make any move we
decide on...
I'm in favor of investigation, especially if that investigation doesn't
further tax Robert.
But I do have concerns similar to Chris's. Back when MS came out with
.NET, there was a well-circulated blog speculating that MS's strategy
was to change the API every few years just to slow down all of its
competition as they came up to speed on a new development environment. I
don't know whether the blog was intended as humor or not, but new APIs
and new tools do require spin up. There's a reason that all cars have
steering wheels year after year after year, and no one ever replaces it
with a joystick, for example.
What we're discussing here is changing the VCS, changing the wiki, and
setting up automated testing. How much work will all this actually take,
including spin up time by those of us in the community already familiar
with the existing tools? Will the new tools have a net reduction on our
workload, or a net increase? Will these tools address the root cause of
the issues we face? What _is_ the root cause of the issues we face?
These are the core questions we need to examine while investigating
these tools.
What is really the most effective way for us to increase our
productivity: new tools, like these? Or some other solution? What gets
us the most bang for the buck? The OSG management issues we face are
big. If we suspect the new tools will not have a sizable impact on these
issues, then we should consider alternatives.
-Paul
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
______________________________________________________
Jean-Sebastien Guay jean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
