[Opensim-users] [PROPOSAL]: Sim version filtering (was Re: Sim Version Filtering (re: Mantis #0002361...)

Wed Nov 5 20:32:11 UTC 2008

My key issue on the 0.6 tag release is having a sufficient number of folks comfortable with moving forward. Nebadon and daTwitch are two folks I depend on to help move us in an "increasing reliability and stability" direction. So, I would appreciate both feeling a bit more comfortable with a 0.6 release. Perhaps we will get there by Sunday, perhaps not.

Justin, if you want to add in your logic, please feel free. I can not imagine that it will decrease stability or reliability in any way. As I currently understand the problem, our issue for stability and reliability is that a) Sims have been freezing, b) Sims seem to consume memory until they start swapping or crash. If we feel that we have a reasonable enough trunk to tag it as 0.6, I am delighted to do so, and I hope we can get there by Sunday.

I think the key criteria for this tagged release is not what features exist, but rather, when we tag it, and those who only download tagged releases start using it will a) It work at least half-way reliably b) Connect to various grids c) Not increase our support overhead on IRC. If those three constraints are met, then I would vote "full speed ahead and darn the torpedoes".

Charles

----- Original Message ----
From: Justin Clark-Casey <jjustincc at googlemail.com>
To: opensim-users at lists.berlios.de
Sent: Wednesday, November 5, 2008 11:42:01 AM
Subject: Re: [Opensim-users] [PROPOSAL]: Sim version filtering (was Re: Sim Version Filtering (re: Mantis #0002361...)

Charles Krinke wrote:
> This seems eminently reasonable to me also.
> 
> On the 0.6 front, I would like to aim for this coming Sunday to tag svn 
> for a 0.6 release and start the cycle of zip/tarball and binaries for 
> download. As a consequence, this week needs to be one of reliability and 
> stability testing.

Ah okay, if we are doing this Sunday then there probably isn't time to both do this and give it a reasonable shakedown. 
  It would need an extra week, I think.  It's your call - I'm easy either way.

> 
> We had a few problems last week with freezes of regions and this appears 
> to be getting better.
> 
> This is the time to push for stability as we head towards Sunday with a 
> few to how to minimize support issues on both this channel and our IRC.
> 
> Charles
> 
> ----- Original Message ----
> From: Sean Dague <sdague at gmail.com>
> To: opensim-users at lists.berlios.de
> Sent: Wednesday, November 5, 2008 7:28:42 AM
> Subject: Re: [Opensim-users] [PROPOSAL]: Sim version filtering (was Re: 
> Sim Version Filtering (re: Mantis #0002361...)
> 
> Justin Clark-Casey wrote:
>  > PROPOSAL FOR SIM VERSION FILTERING
>  >
>  > Not being able to stop sim versions that implement obsolete comms 
> interfaces from connecting to a grid is becoming an
>  > increasingly awkward problem.  As you can imagine, it leads to a high 
> volume of support requests, particular if the grid
>  > is upgrading quite often (which is the case in large development test 
> grids).
>  >
>  > There has been a proposal (in 
> http://opensimulator.org/mantis/view.php?id=2361) to have the region 
> server send its SVN
>  > revision number to enable filtering by the grid server.  However, I'm 
> not a fan of this idea for the reasons outlined in
>  > the e-mails further below (ties us into a source control system, not 
> necessarily present in binaries/source, not
>  > friendly to non OpenSim implementations).
>  >
>  > Therefore, I am going to propose that there is an interface version 
> number in OpenSim.Framework.Servers.VersionInfo.cs 
> <http://OpenSim.Framework.Servers.VersionInfo.cs>.
>  >  This is separate from the OpenSim version, and would increase by 1 
> every time a change was made to OGS1 or interregion
>  > interfaces that was incompatible with older versions.
>  >
>  > So the sequence would be 1, 2, 3, 4, ...
>  >
>  > On region connection, the version number would be sent.  If it 
> differs from that of the grid, the grid would refuse
>  > connection with a message advising version upgrade (or possibly 
> downgrade)
>  >
>  > The advantages of this approach are that
>  >
>  > a)  We don't use the SVN revision number
>  > b)  Grid operators don't have to manually determine which regions are 
> compatible
>  >
>  > The disadvantages are
>  >
>  > a)  Developers have to upgrade the number themselves.  I don't 
> believe this is a huge burden.  It's also not a disaster
>  > if this is forgotton - one just upgrades it on the next commit.
>  >
>  > This may be the simplest thing that could possibly work whilst 
> avoiding the disadvantages of using the SVN number.  One
>  > can get more elaborate (e.g. minor verion numbers for compatible 
> changes) but I don't think the complication is
>  > worthwhile or known to be workable at this point.
>  >
>  > Comments?
> 
> +1 on this approach.  I like not using svn version, as that restricts
> compatibility too much.  I also think we'll have a good success rate at
> figuring out that something is destabalizing change.
> 
> I'd *highly* suggest this goes in before 0.6, so that 0.6 regions
> participate in this system.  This will be important as a lot of people
> will probably go to 0.6 when it comes out and get off the svn tracking
> at that point.
> 
>     -Sean
> 
> -- 
> Sean Dague / Neas Bade
> sdague at gmail.com <mailto:sdague at gmail.com>
> http://dague.net
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Opensim-users mailing list
> Opensim-users at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-users

-- 
justincc
Justin Clark-Casey
http://justincc.wordpress.com
_______________________________________________
Opensim-users mailing list
Opensim-users at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-users/attachments/20081105/c8771e1d/attachment.html>