Trunk-Versionen

 

Da sich die Verwendung von Trunk-Versionen und eigene Kompilate immer mehr verbreiten und zeitgleich immer öfter Fehler/Probleme reklamiert werden, fand ich folgende 2 Kommentare von Entwicklern eine recht hilfreiche Klarstellung:

 

From: "Frisby, Adam" <adam@deepthink.com.au>

Subject: Re: [Opensim-users] Strange effekt / Avatar totaly stretched

 

Diverting from the topic at hand - I would like to strongly point this out. Please, please, PLEASE use a release, or a postfixes branch if you are running OpenSim in a semi-production or production environment.

 

While this was a prank, sooner or later, we're going to have something like a full blown exploit, or DB crashing bug, or similar. You are a lot safer in a somewhat tested and confirmed stable branch than you are on trunk.

 

Trunk is very much an 'at risk' environment, and people putting OpenSim into production need to be aware of this fact. If nothing else, this prank has given the opportunity to highlight the importance of sticking to a tagged release for production work.

 

Adam

 

 

und

 

From: MW <michaelwri22@yahoo.co.uk>

Subject: Re: [Opensim-users] Strange effekt / Avatar totaly stretched

 

+1 to those comments.

 

We also can develope a lot faster and easier if we know that trunk is being used as it should be. As a place to do development, knowing that sometimes what we do will cause new problems rather than fix older problems in opensim.

 

Trunk isn't a daily release system for people wanting stable versions. Its great that lots of people run it to help test and debug opensim. But it shouldn't be used when people don't want to take all the risks that come with it.

 

und noch eine letzte:

 

From: "Frisby, Adam" <adam@deepthink.com.au>

Subject: Re: [Opensim-users] Fw: Re: [SLED] Linden Lab Sells Second

      Life!

 

Honestly, I think there's some disconnects between people here that need to be addressed.

 

There are several different audiences here, and consequently several different reactions. There is the group of users attempting to put OpenSim into production environments - the harsher reactions I have seen tend to fall into this group. There is home users and hobbyists - the more positive reactions are from there.

 

To the production users, we do as a team find it unfortunate you were badly impacted, however as a group a large portion of work on OpenSim comes from personal developers without sponsorship. As a team, we also make absolutely no guarantees about trunk releases at all (infact we often make the opposite), the best practices we publish on our website very clearly state that production users should stick to a tagged release, and even then you are operating alpha code.

 

While we have generally been blessed with a reasonably well written and maintained codebase - trunk is not guaranteed to operate. Had there been an accident and the database became corrupted over time due to coding error - the outrage on this list would not have been as loud, however the impacts would have been significantly worsened.

 

Often, developers need to break code and features in order to improve things, if we cannot make trunk unstable, then the ability to develop and continually improve the codebase is restricted. One recent example was some avatar appearance issues that showed up after the MXP stack - that one I caused by removing code which erroneously assumed an avatar utilized the LLUDP Stack.

 

The short term result of that change was it broke avatar appearance in certain circumstances for a period of about 24 hours, the long term result was we got one step closer to more protocols, more neutrality and abstracted behaviour - all seen as good things to the codebase -- however another example of why we do not recommend anyone utilize trunk for production - it was still broken for a day, and this is a regular occurance.

 

For instance, a patch not too long ago adjusted the asset database format - while fine on local systems with small asset counts, in a production environment (specifically osgrid), it caused the entire database to melt. OSGrid accepts that risk since they are a testing grid - but to another operator, you would have applied that same patch just as easily as osgrid did if today's example is the norm.

 

Now the first response, I expect will be 'this was deliberate/vandalism' - yes there was an april fools joke in the codebase. However, please consider the following:

 

* The impact was for the most part completely negligible - no permanent changes were made, the code deactivates automatically, a patch is available on mantis (and is no longer in trunk anyway).

* You are running a version of the codebase that is *explicitly marked as 'not suitable for production'*.

* You are receiving a product for free under an extremely liberal license on behalf of the generosity of others.

 

That april fools joke was /only ever accessible in the developers and testers oriented release/. The intended audience was those two groups - developers and testers. Even the release candidate version had the offending code removed.

 

If you want to put OpenSim into production, fantastic - we like to see it being used. However when you then do not follow the advice we post clearly on the website in multiple places and put trunk into production, then no - the responsibility for failure rests upon your shoulders - trunk is /not safe for production/.

 

We do recognize the growing corporate demand for OpenSim - it's one of the reason that people such as Stefan have begun a back-patches version (post-fixes) which incorporates fixes into the last stable version. We spend the time maintaining that version because we recognise the need, it's also the reason we have been as a group moving towards more release-oriented packaging such as the installers and other easy-to-deploy packages.

 

If you are a corporate user putting OpenSim into production, make sure you have the following preparations:

 

1. Have a stable revision handy - currently that is 0.6.3-postfixes. Sometimes bugs show up randomly and break things badly. You should always have a backup system when working with OpenSim.

 

2. Use our postfix releases normally - sometimes a feature patch is very tempting to upgrade to, but then ask yourself what the cost might be? If stick figure avatars are going to cause you to have issues with clients - ask yourself what random object destruction might cause. It's happened in the past on trunk - I have no doubts major unintended bugs will sneak into trunk in future.

 

Only upgrade past post-fixes if you keep a very keen eye on SVN commit logs and are capable of testing hardened revisions.

 

3. Keep backups. Too many OpenSim installs do not do this. OAR works well for content, however a full database backup is recommend (this varies from tool to tool, know your system.)

 

4. Slow and steady is the name of the game. We actually keep several of our clients on a r6XXX release since we're able to confirm it works for their uses in the majority of cases and doesn't have unknown factors.

 

Regards,

 

Adam

 

 

Also:

- wer stabile Versionen haben möchte nutzt binaries von versionierten Releases (6.4 etc)

- wer es stabil aber etwas näher dran am aktuellen Stand mag wählt binaries von den Stellen die Trunk´s kompilieren , testen und "semi-stabile" Versionen zum download bereitstellen

- wer vor Explosionen nicht zurückschreckt, weiß wie Backup und Restore funktioniert und auch mal mit ein paar Stunden bis Tagen Fehler(suche) leben kann - der kann und sollte sich ruhig dem Abenteuer der neues Features und Fehler in den Trunk Versionen hingeben.  Am meisten hat die Entwicklung davon, wenn Fehler dann auch auf Mantis reported werden.  Erfahrungsgemäß sollte man damit erst beginnen, wenn man mit dem Betrieb von opensim an sich bereits einige Erfahrung hat, opensim.ini, region .xml´s und supportwege gute Freunde geworden sind.

 

(Naja, Backups sollte jeder immer haben - ich denke die Aussage ist aber verständlich)

 

Die Entwickler bitten darum ,keine direkten SVN Kommandos weiterzugeben. Vielmehr sollen alle die sich für eigenes Kompilieren der instabilen (bleeding edge / trunk) Versionen interessieren, die Basisinfos auf http://opensimulator.org/wiki/Download verstehen und akzeptieren.

 

Date: Thu, 02 Apr 2009 18:46:44 -0400

From: Sean Dague <sdague@gmail.com>

Subject: [Opensim-dev] New language for Downloads Page

 

A lot of what transpired was because it was apparently not clear enough

about not using trunk.  So that there isn't such confusion in the

future, I've removed the direct SVN link off the front page, and moved

the trunk links to this section of the Downloads page

(http://opensimulator.org/wiki/Download) :

 

Experimental Upstream Code

 

There Be Dragons Beyond This Point

 

If you are truly feeling dangerous, adventurous, or want to help us test

the next version of OpenSim you are welcome to grab the latest unstable

code out of our subversion trunk. Any warnings previous expressed about

the alpha nature of the code go double or triple if you are running

directly off of trunk. Never, ever, ever, never run this in production

environments, it is not suitable for that unless you are very familiar

with the source code, and can hot fix any piece of it (that probably

means you are an OpenSim core member). Feedback and testing on the

unstable tree is appreciated, as that helps us make the next release

better. If this scares you from using trunk, that was intended.

 

If it breaks, you get to keep both pieces.

 

    * Latest Subversion revision version (bleeding edge)

...

 

 

I replicate this here, because there are plenty of people that already

have a trunk tree, hopefully they'll get this message here if not via

the website.

 

I'd also ask a favor from our users, if you find links to SVN anywhere

else in the wiki, please remove them, and just link in the Downloads

page.  If anyone in IRC asks you how to get source, please don't give

them a direct svn command, please send them to that page.  Everyone

getting svn trunk needs to read that paragraph, and really internalize it.

 

Apologies to people for which this makes it a couple more steps to get

code who understand trunk, and continue to be incredible testers for

this incredible project.

 

Thanks folks,

 

      -Sean

 

--

Sean Dague / Neas Bade

http://dague.net

 

 

 

(1.4.2009 - kein Aprilscherz)