Re: [Opensim-dev] Status of presence refactor?
2010/2/23 Cristina Videira Lopes lo...@ics.uci.edu Let's bring the focus of this thread back. We're about to merge the presence-refactor branch into the master branch, and then we'll need testers, some of us will be working overtime to fix the bugs, and hopefully Fly-Man- will update Wiredux sometime soon. Then a big effort in documentation will start. There's a lot of work to do. The last thing we need is switching development tools. Uhm, at this moment there is no Wiredux that will work with master or presence-refactor. The version I am developing for my own grids is not nearly finished up so don't expect a new version of Wiredux within the coming 2 months. And as I heard, there's about 4 groups working on the followup version of Wiredux so I find it strange that my name comes up for Wiredux as there's enough other ppl working on it as well ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Status of presence refactor?
d...@metaverseink.com wrote: News: the SQLite connector is done and working in the presence-refactor branch. UserAccount data is automatically migrated into the new table. People using SQLite-powered OpenSims will have to reset the passwords manually before they are able to login (with console command reset user password). This does not affect MySql-powered opensims, only SQLite. Out of interest, why is this? I can see this being a problem for people with multiple user accounts on an SQLite system. Hopefully Melanie_t will finish Friends today. We'll be ready to merge any time now. Frisby, Adam wrote: I would like to start the SOP refactor fairly soon - what if once 0.7 is tagged for the RC process; I go and and make a new branch; we can sic testers on the presence-branch, while dev happens on the branch I tag? Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey Sent: Friday, 19 February 2010 3:25 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Status of presence refactor? Melanie wrote: I would not like to see the refactor start in the branch, because that would postpone a merge indefinitely. Yes, please whatever happens, do not start any sog refactoring in Master until presence-refactor has been merged and we've started a branch for 0.7. In fact, when presence-refactor is merged with Master I think that we should wait at least 2 weeks before branching for 0.7 in order for all active developers to iron out any significant bugs associated with the merge. At a minimum, the 0.7 branch itself would be subject to the same release candidate and bug triage procedure as was 0.6.8. Only after this would 0.7 be tagged. I think that this is the very minimum we need to do in order to be a credible project. This would also give us an opportunity to get the documentation into a shape where at least super-intelligent pandimensional mice can understand it :) At the same time as 0.7 is branched, I also think that it would be prudent to branch for a potential 0.7.0.1. If all goes well with the sog refactor this will never see the light of day. But I think we should give ourselves a means of working with the old sog code in case the refactor encounters trouble. The sog refactor is far from trivial. However, the refactor caould be started in a NEW branch that is based off the current presence-refactor. The friends and SQLite functionality could be merged back to that new branch when they are completed. Git allows this easily. That sounds like a good idea. Melanie d...@metaverseink.com wrote: I could, but I'm hesitant to make diva distro releases from branches that aren't the master branch. Plus, so far the differences between the two branches are purely internal; there is no functional difference, or new bug fixes, or anything like that. The new architecture will allow for lots of exciting things to happen, but, again, I'm hesitant in making them happen in the branch. I'd rather merge this to master. Robert Martin wrote: On Thu, Feb 18, 2010 at 10:15 AM, d...@metaverseink.com wrote: Sigh. It's ready. It's been fully operational for several weeks, modulo buglets. It hasn't been merged because the SQLite connector hasn't been redone and at least Melanie doesn't want to merge without it. could you release a copy of Diva with the updated code (since Diva of course does not use SQlite)? ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- Justin Clark-Casey (justincc) http://justincc.org http://twitter.com/justincc ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- Justin Clark-Casey (justincc) http://justincc.org http://twitter.com/justincc ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Status of presence refactor?
Justin Clark-Casey wrote: Out of interest, why is this? Well, what I said isn't the only possible route. Here's the technical issue, then I'll explain the two ways to go at it. But then I have a question and a warning to whoever uses SQLite. Due to SQLite connection management constraints, the authorization data is being stored in a separate file than the user account data file. Different connections == different files, or things won't work. Conversely, one file == one connection, but that would mean having to merge the data layers for user accounts and authorization in SQLite, not pretty. Auth being on a separate file than the old userprofile db, data can't be copied over automatically. So, two ways to go at this: 1) Run without any pre-action, reset the password, then the right auth data will be placed in the right file. (this is what I meant in my previous email, runs without pre-action) 2) Use the old userprofiles.db as the basis for both the new useraccounts table and the auth tables. In other words, copy userprofiles.db to auth.db, then run. I have a migration in auth that will copy the auth data over to the auth table from the old users table. But now, the question. Why do you think that people running OpenSim over SQLite have multiple user accounts, like one expects from people running a real DB? Can you give me some rough numbers for who is doing that? I was under the impression that SQLite is being used for quick trials and for single-person worlds. I would *strongly* discourage people from using SQLite-powered OpenSims as if this was a sustainable multi-user configuration. It's not. It will bomb. Mantis #4437 is a good example of SQLite bombing on people. Had a bug like that affected MySQL, it would have been fixed in no time. It affecting SQLite, the issue has been open for over 2 months, and the fix is not in sight. More than SQLite performing poorly, which it does for large DBs, the main danger here is the lack of support for when things go wrong. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Status of presence refactor?
We can, by this order: 1) merge presence-refactor into master 2) create a sop-refactor branch from master immediately after 3) create a 0.7 branch some time later I would like to propose that the sop refactoring work be done in a branch rather than in the master branch, similar to what we did for the services refactoring. It works pretty well -- gives the refactoring devs peace of mind to leave things unstable and isolates the master branch from prolonged instability. Also, are there any suggestions for Adam before he starts doing this? He sent out a document some time ago, but there wasn't a lot of feedback or discussion. Are there any alternatives or wishes for his proposed work? Justin Clark-Casey wrote: Frisby, Adam wrote: I would like to start the SOP refactor fairly soon - what if once 0.7 is tagged for the RC process; I go and and make a new branch; we can sic testers on the presence-branch, while dev happens on the branch I tag? My concern with branching for 0.7 release candidates immediately after the presence-refactor merge is that we won't get everybody helping to iron out the inevitable hiccups since most people follow master. Waiting a couple of weeks for at least some of this to happen is the minimum, I feel. Ideally, I'd like that to be longer but I know that you and other folk want to press ahead. I guess some of this depends on how disruptive the refactor is. What do you think? I'm assuming there will be breakage but perhaps I'm wrong? Of course, I guess you could create a separate sop-refactor branch at any point and start work there, possibly merging back to master and continuing in master once 0.7 RC has been branched. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Status of presence refactor?
Can I make one request... Can we tag the current master as 0.6.9 (or something) prior to the merge? --mic On Mon, Feb 22, 2010 at 8:13 AM, d...@metaverseink.com wrote: We can, by this order: 1) merge presence-refactor into master 2) create a sop-refactor branch from master immediately after 3) create a 0.7 branch some time later I would like to propose that the sop refactoring work be done in a branch rather than in the master branch, similar to what we did for the services refactoring. It works pretty well -- gives the refactoring devs peace of mind to leave things unstable and isolates the master branch from prolonged instability. Also, are there any suggestions for Adam before he starts doing this? He sent out a document some time ago, but there wasn't a lot of feedback or discussion. Are there any alternatives or wishes for his proposed work? Justin Clark-Casey wrote: Frisby, Adam wrote: I would like to start the SOP refactor fairly soon - what if once 0.7 is tagged for the RC process; I go and and make a new branch; we can sic testers on the presence-branch, while dev happens on the branch I tag? My concern with branching for 0.7 release candidates immediately after the presence-refactor merge is that we won't get everybody helping to iron out the inevitable hiccups since most people follow master. Waiting a couple of weeks for at least some of this to happen is the minimum, I feel. Ideally, I'd like that to be longer but I know that you and other folk want to press ahead. I guess some of this depends on how disruptive the refactor is. What do you think? I'm assuming there will be breakage but perhaps I'm wrong? Of course, I guess you could create a separate sop-refactor branch at any point and start work there, possibly merging back to master and continuing in master once 0.7 RC has been branched. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Status of presence refactor?
+1 Mic Bowman wrote: Can I make one request... Can we tag the current master as 0.6.9 (or something) prior to the merge? --mic On Mon, Feb 22, 2010 at 8:13 AM, d...@metaverseink.com mailto:d...@metaverseink.com wrote: We can, by this order: 1) merge presence-refactor into master 2) create a sop-refactor branch from master immediately after 3) create a 0.7 branch some time later I would like to propose that the sop refactoring work be done in a branch rather than in the master branch, similar to what we did for the services refactoring. It works pretty well -- gives the refactoring devs peace of mind to leave things unstable and isolates the master branch from prolonged instability. Also, are there any suggestions for Adam before he starts doing this? He sent out a document some time ago, but there wasn't a lot of feedback or discussion. Are there any alternatives or wishes for his proposed work? Justin Clark-Casey wrote: Frisby, Adam wrote: I would like to start the SOP refactor fairly soon - what if once 0.7 is tagged for the RC process; I go and and make a new branch; we can sic testers on the presence-branch, while dev happens on the branch I tag? My concern with branching for 0.7 release candidates immediately after the presence-refactor merge is that we won't get everybody helping to iron out the inevitable hiccups since most people follow master. Waiting a couple of weeks for at least some of this to happen is the minimum, I feel. Ideally, I'd like that to be longer but I know that you and other folk want to press ahead. I guess some of this depends on how disruptive the refactor is. What do you think? I'm assuming there will be breakage but perhaps I'm wrong? Of course, I guess you could create a separate sop-refactor branch at any point and start work there, possibly merging back to master and continuing in master once 0.7 RC has been branched. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Status of presence refactor?
d...@metaverseink.com kirjoitti: We can, by this order: 1) merge presence-refactor into master 2) create a sop-refactor branch from master immediately after 3) create a 0.7 branch some time later I would like to propose that the sop refactoring work be done in a branch rather than in the master branch, similar to what we did for the I also think a branch for it is a good idea, but don't know why wait - the sop-refactor branch can also be branched from presence-refactor right now if Adam wants to start already. Like Melanie suggested some days ago in this thread. AFAIK this won't be a problem with git, 'cause commits are commits and it doesn't matter from which repo they are from, a version being a set of commits. So sop-refactor could first pull from presence-refactor if work still goes on there, and then keep pulling from master when it lives there, etc. Perhaps this is not relevant anymore if 1) can be done now, might have been a good idea a couple of weeks ago when presence-refactor was pretty much done for parts that touch the scene(?). Also, I'm by no means a git expert, so am curious to know if have misunderstood it somehow and this idea wouldn't work .. Melanie did say in her post that it would. ~Toni services refactoring. It works pretty well -- gives the refactoring devs peace of mind to leave things unstable and isolates the master branch from prolonged instability. Also, are there any suggestions for Adam before he starts doing this? He sent out a document some time ago, but there wasn't a lot of feedback or discussion. Are there any alternatives or wishes for his proposed work? Justin Clark-Casey wrote: Frisby, Adam wrote: I would like to start the SOP refactor fairly soon - what if once 0.7 is tagged for the RC process; I go and and make a new branch; we can sic testers on the presence-branch, while dev happens on the branch I tag? My concern with branching for 0.7 release candidates immediately after the presence-refactor merge is that we won't get everybody helping to iron out the inevitable hiccups since most people follow master. Waiting a couple of weeks for at least some of this to happen is the minimum, I feel. Ideally, I'd like that to be longer but I know that you and other folk want to press ahead. I guess some of this depends on how disruptive the refactor is. What do you think? I'm assuming there will be breakage but perhaps I'm wrong? Of course, I guess you could create a separate sop-refactor branch at any point and start work there, possibly merging back to master and continuing in master once 0.7 RC has been branched. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Status of presence refactor?
How nice of you Mark! From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Mark Malewski Sent: Monday, February 22, 2010 4:01 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Status of presence refactor? Adam/Chris/Melanie/Diva, since I don't have any Linux machines at my disposal for mono testing (and my development servers will be going on shipping containers for a month in the very near future). If you need any hardware just let me know. I can set a box (or a few boxes) up for you, just let me know what you need. I have about 10 or 12 servers just sitting here not being used (Quad and Eight core Xeon Nehalem-based servers with 16+GB or 32+GB of RAM). Just let me know what you need, what you want installed on the boxes (Ubuntu, Windows Server 2008 R2, etc.) and I can get something setup for you that you can use for development/testing and sandbox purposes. Just let me know what you want, and I can get something built for you in a day or so. Then I'll give you a root login, and you can do whatever it is that you need/want to do (I can setup remote desktop, VPN, or SSH/FTP or whatever it is that you may want for remote access/administration). Just let me know what OS you want, and what version of Mono you want installed (or I can simply just install Ubuntu, or Windows Server 2008 R2 or even one server of each, and you can install whatever it is that you want on the box after that). This way you have a development box (or two) that you can use remotely, and you can share with others (if you want) for testing/development purposes. If it will help you, Adam, Melanie, Crista/Diva, by giving you a development sandbox for a 0.6.9 and 0.7 RC. This way you can just use the box for development, bug testing, bug fixing, refactoring and whatever you need to do to help with the upcoming 0.7 RC. I could setup a Ubuntu box with SQLite, and also setup a Windows 2008 R2 box with MySQL so you can test out both the 0.6.9 and future 0.7 RC (and use the hardware platforms for internal development, SQLite MySQL testing, sandboxing and bug testing purposes of the 0.6.9 and RC 0.7) I don't mind hosting the servers, I have the extra equipment and bandwidth for as long as you need them (indefinitely). Just tell me what you want, and give me a day to set it up. I have the hardware, and I'm offering... Just let me know, Mark On Thu, Feb 18, 2010 at 9:46 AM, Chris Hart ch...@codetorque.co.uk wrote: I had said I would look at SQLite but I honestly don't think I will have time, plus if there are significant mono-related issues then I am not best positioned to work on it in any case, since I don't have any Linux machines at my disposal for mono testing (and my development servers will be going on shipping containers for a month in the very near future). Personally, I have MSSQL code to finish for presence refactor branch (likely a few more days of work there), I would like to get that in if there's plans to move forward at some point, but my pieces shouldn't be too hard to plug in, unlike something like a core architecture refactor. I imagine the SOG refactor is going to take some time to work in since it's a major piece of work - if that scale of work starts before SQLite can be fixed then it will be many more months of waiting for consumers who like tagged revisions before a working revision emerges. Is there another option here? Suggest that SQLite users stick to 0.6.8 (even if it is semi broken I guess it is better than totally broken), push the presence refactor into trunk and continue to plead for more assistance on SQLite? Chris -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com Sent: 18 February 2010 3:16 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Status of presence refactor? Sigh. It's ready. It's been fully operational for several weeks, modulo buglets. It hasn't been merged because the SQLite connector hasn't been redone and at least Melanie doesn't want to merge without it. For me, the SQLite connector continues to be a big question mark. There's the show-stopper bug with mono 2.4.3+, which Teravus has been spending an enormous amount of time trying to fix, without success so far. And then there's writing the code for the new tables, which I might attempt doing if absolutely no one else comes forward; but if I do it, it won't be pretty, and that code risks going outdated again. I just don't know enough about SQLite to do it properly in the amount of time I have to OpenSim. Adam, I hate to suggest this, but you could start your SOG refactor in that branch already. John Hurliman is doing his other implementation of the resource services using that branch. Frisby, Adam wrote: Does anyone know what is the current status
Re: [Opensim-dev] Status of presence refactor?
* **How nice of you Mark!* No problem. I have plenty of extra hardware and bandwidth. If you need a couple of Linux boxes, or Windows Server boxes, just let me know what the dev's want, what they need, and I can get them setup with some hardware. Just tell me how many boxes you need, and what you want installed on each of them, and I can get them done. I have time this week, so depending on what you want installed, just give me a day (per box) to get them setup and configured. Just give me a list of how many boxes you want, and what you want installed on them. Thanks, Mark On Mon, Feb 22, 2010 at 3:03 PM, Kyle cre...@reactiongrid.com wrote: How nice of you Mark! *From:* opensim-dev-boun...@lists.berlios.de [mailto: opensim-dev-boun...@lists.berlios.de] *On Behalf Of *Mark Malewski *Sent:* Monday, February 22, 2010 4:01 PM *To:* opensim-dev@lists.berlios.de *Subject:* Re: [Opensim-dev] Status of presence refactor? Adam/Chris/Melanie/Diva, * since I don't have any Linux machines at my disposal for mono * * testing (and my development servers will be going on shipping* * containers for a month in the very near future).* If you need any hardware just let me know. I can set a box (or a few boxes) up for you, just let me know what you need. I have about 10 or 12 servers just sitting here not being used (Quad and Eight core Xeon Nehalem-based servers with 16+GB or 32+GB of RAM). Just let me know what you need, what you want installed on the boxes (Ubuntu, Windows Server 2008 R2, etc.) and I can get something setup for you that you can use for development/testing and sandbox purposes. Just let me know what you want, and I can get something built for you in a day or so. Then I'll give you a root login, and you can do whatever it is that you need/want to do (I can setup remote desktop, VPN, or SSH/FTP or whatever it is that you may want for remote access/administration). Just let me know what OS you want, and what version of Mono you want installed (or I can simply just install Ubuntu, or Windows Server 2008 R2 or even one server of each, and you can install whatever it is that you want on the box after that). This way you have a development box (or two) that you can use remotely, and you can share with others (if you want) for testing/development purposes. If it will help you, Adam, Melanie, Crista/Diva, by giving you a development sandbox for a 0.6.9 and 0.7 RC. This way you can just use the box for development, bug testing, bug fixing, refactoring and whatever you need to do to help with the upcoming 0.7 RC. I could setup a Ubuntu box with SQLite, and also setup a Windows 2008 R2 box with MySQL so you can test out both the 0.6.9 and future 0.7 RC (and use the hardware platforms for internal development, SQLite MySQL testing, sandboxing and bug testing purposes of the 0.6.9 and RC 0.7) I don't mind hosting the servers, I have the extra equipment and bandwidth for as long as you need them (indefinitely). Just tell me what you want, and give me a day to set it up. I have the hardware, and I'm offering... Just let me know, Mark On Thu, Feb 18, 2010 at 9:46 AM, Chris Hart ch...@codetorque.co.uk wrote: I had said I would look at SQLite but I honestly don't think I will have time, plus if there are significant mono-related issues then I am not best positioned to work on it in any case, since I don't have any Linux machines at my disposal for mono testing (and my development servers will be going on shipping containers for a month in the very near future). Personally, I have MSSQL code to finish for presence refactor branch (likely a few more days of work there), I would like to get that in if there's plans to move forward at some point, but my pieces shouldn't be too hard to plug in, unlike something like a core architecture refactor. I imagine the SOG refactor is going to take some time to work in since it's a major piece of work - if that scale of work starts before SQLite can be fixed then it will be many more months of waiting for consumers who like tagged revisions before a working revision emerges. Is there another option here? Suggest that SQLite users stick to 0.6.8 (even if it is semi broken I guess it is better than totally broken), push the presence refactor into trunk and continue to plead for more assistance on SQLite? Chris -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com Sent: 18 February 2010 3:16 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Status of presence refactor? Sigh. It's ready. It's been fully operational for several weeks, modulo buglets. It hasn't been merged because the SQLite connector hasn't been redone and at least Melanie doesn't want to merge without
Re: [Opensim-dev] Status of presence refactor?
Yeah, we could have done that in theory. In practice, we're all still fairly ignorant when it comes to using git, and we've all had close encounters with git disasters. Melanie is the one keeping branches in sync, she has spent a lot of time resolving conflicts by hand, helping out the messes we get into, etc. She can do that with one branch but not with many... so until several of us learn how to deal with git errors effectively, it's not wise to multiply branches. We'll learn as we go, and hopefully we'll get better at using git. On Feb 22, 2010, at 11:47 AM, Toni Alatalo wrote: d...@metaverseink.com kirjoitti: We can, by this order: 1) merge presence-refactor into master 2) create a sop-refactor branch from master immediately after 3) create a 0.7 branch some time later I would like to propose that the sop refactoring work be done in a branch rather than in the master branch, similar to what we did for the I also think a branch for it is a good idea, but don't know why wait - the sop-refactor branch can also be branched from presence-refactor right now if Adam wants to start already. Like Melanie suggested some days ago in this thread. AFAIK this won't be a problem with git, 'cause commits are commits and it doesn't matter from which repo they are from, a version being a set of commits. So sop-refactor could first pull from presence-refactor if work still goes on there, and then keep pulling from master when it lives there, etc. Perhaps this is not relevant anymore if 1) can be done now, might have been a good idea a couple of weeks ago when presence-refactor was pretty much done for parts that touch the scene(?). Also, I'm by no means a git expert, so am curious to know if have misunderstood it somehow and this idea wouldn't work .. Melanie did say in her post that it would. ~Toni services refactoring. It works pretty well -- gives the refactoring devs peace of mind to leave things unstable and isolates the master branch from prolonged instability. Also, are there any suggestions for Adam before he starts doing this? He sent out a document some time ago, but there wasn't a lot of feedback or discussion. Are there any alternatives or wishes for his proposed work? Justin Clark-Casey wrote: Frisby, Adam wrote: I would like to start the SOP refactor fairly soon - what if once 0.7 is tagged for the RC process; I go and and make a new branch; we can sic testers on the presence-branch, while dev happens on the branch I tag? My concern with branching for 0.7 release candidates immediately after the presence-refactor merge is that we won't get everybody helping to iron out the inevitable hiccups since most people follow master. Waiting a couple of weeks for at least some of this to happen is the minimum, I feel. Ideally, I'd like that to be longer but I know that you and other folk want to press ahead. I guess some of this depends on how disruptive the refactor is. What do you think? I'm assuming there will be breakage but perhaps I'm wrong? Of course, I guess you could create a separate sop-refactor branch at any point and start work there, possibly merging back to master and continuing in master once 0.7 RC has been branched. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Status of presence refactor?
d...@metaverseink.com wrote: Justin Clark-Casey wrote: Out of interest, why is this? Well, what I said isn't the only possible route. Here's the technical issue, then I'll explain the two ways to go at it. But then I have a question and a warning to whoever uses SQLite. Due to SQLite connection management constraints, the authorization data is being stored in a separate file than the user account data file. Different connections == different files, or things won't work. Conversely, one file == one connection, but that would mean having to merge the data layers for user accounts and authorization in SQLite, not pretty. Auth being on a separate file than the old userprofile db, data can't be copied over automatically. So, two ways to go at this: 1) Run without any pre-action, reset the password, then the right auth data will be placed in the right file. (this is what I meant in my previous email, runs without pre-action) 2) Use the old userprofiles.db as the basis for both the new useraccounts table and the auth tables. In other words, copy userprofiles.db to auth.db, then run. I have a migration in auth that will copy the auth data over to the auth table from the old users table. But now, the question. Why do you think that people running OpenSim over SQLite have multiple user accounts, like one expects from people running a real DB? Can you give me some rough numbers for who is doing that? You're right - I don't have any numbers so perhaps no-one is doing that. I took the liberty of copying this over to the users list to see if any hands are raised there. If SQLite is just being used for single person/demonstration installations then password reset sounds good enough. I agree that it's not worth wasting valuable time on a more complete solution. As long as it's brightly and loudly documented then I think that would be okay. I was under the impression that SQLite is being used for quick trials and for single-person worlds. I would *strongly* discourage people from using SQLite-powered OpenSims as if this was a sustainable multi-user configuration. It's not. It will bomb. Mantis #4437 is a good example of SQLite bombing on people. Had a bug like that affected MySQL, it would have been fixed in no time. It affecting SQLite, the issue has been open for over 2 months, and the fix is not in sight. More than SQLite performing poorly, which it does for large DBs, the main danger here is the lack of support for when things go wrong. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- Justin Clark-Casey (justincc) http://justincc.org http://twitter.com/justincc ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Status of presence refactor?
I think that a tag would be good but please _not_ anything that suggests 0.6.9. I would really like to see us reserve version numbers for proper releases that have undergone the release candidate procedure. d...@metaverseink.com wrote: +1 Mic Bowman wrote: Can I make one request... Can we tag the current master as 0.6.9 (or something) prior to the merge? --mic On Mon, Feb 22, 2010 at 8:13 AM, d...@metaverseink.com mailto:d...@metaverseink.com wrote: We can, by this order: 1) merge presence-refactor into master 2) create a sop-refactor branch from master immediately after 3) create a 0.7 branch some time later I would like to propose that the sop refactoring work be done in a branch rather than in the master branch, similar to what we did for the services refactoring. It works pretty well -- gives the refactoring devs peace of mind to leave things unstable and isolates the master branch from prolonged instability. Also, are there any suggestions for Adam before he starts doing this? He sent out a document some time ago, but there wasn't a lot of feedback or discussion. Are there any alternatives or wishes for his proposed work? Justin Clark-Casey wrote: Frisby, Adam wrote: I would like to start the SOP refactor fairly soon - what if once 0.7 is tagged for the RC process; I go and and make a new branch; we can sic testers on the presence-branch, while dev happens on the branch I tag? My concern with branching for 0.7 release candidates immediately after the presence-refactor merge is that we won't get everybody helping to iron out the inevitable hiccups since most people follow master. Waiting a couple of weeks for at least some of this to happen is the minimum, I feel. Ideally, I'd like that to be longer but I know that you and other folk want to press ahead. I guess some of this depends on how disruptive the refactor is. What do you think? I'm assuming there will be breakage but perhaps I'm wrong? Of course, I guess you could create a separate sop-refactor branch at any point and start work there, possibly merging back to master and continuing in master once 0.7 RC has been branched. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- Justin Clark-Casey (justincc) http://justincc.org http://twitter.com/justincc ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Status of presence refactor?
* we're all still fairly ignorant when it comes to using git, and * * we've all had close encounters with git disasters.* Why are we using GIT? I understand that it's supposed to be better than CVS/SVN, but it's still a dinosaur compared to Mercurial or Bazaar. Why aren't we using Mercurial? * Melanie is the one keeping branches in sync, she has spent * * a lot of time resolving conflicts by hand, helping out the * * messes we get into, etc. * That seems extremely insane, and that's the whole problem with Git. It would make more sense to use something like Mercurial. Much easier with the intelligent syncing feature of Mercurial (which Git doesn't have, so everything must be done manually with Git and wastes a lot of time). * She can do that with one branch but not with many... * It would really make much more sense to switch over to Mercurial (or Bazaar) for the development work. Mercurial (and Bazaar) are even faster than Git, plus Mercurial has the best intelligent merging and allows users to work only on one directory of the repository (to help limit damage, etc.). The Intelligent Merging features are nice (make commits easy on the dev's). Lots of great features in Mercurial, and it's probably by far the best (or at least much better than CVS, Subversion, or Git). Bazaar and Mercurial are probably the two best. http://versioncontrolblog.com/comparison/Bazaar/CVS/Git/Mercurial/Subversion/index.html I could setup a Mercurial or Bazaar repository on a server (for redundancy purposes) and then each of the Dev's can just use Mercurial on their desktop to collaborate peer to peer (and I can perform backups of the main Mercurial server, just so we have backup, snapshot and restore points). It will help with the intelligent merging (for numerous dev's all working together all at the same time) and we can always feed copies of the Merc repository back to the old Git and just use the old Git repository as a public archive. Mercurial is extremely easy to use: http://hgbook.red-bean.com/read/mercurial-in-daily-use.html#id496680 Merc is peer to peer, and supports backups/mirroring, and has lots of great features. I can just setup a master server (with a cron job) to automatically pull periodic changes from your local repositories every hour (for all the core dev's). Since Mercurial maintains a complete copy of history in each clone (every single peer), everyone who uses Mercurial to collaborate on a project can potentially act as a source of backups in the event of a catastrophe (since there is no real centralized server). If a central repository becomes unavailable, you simply just clone a copy of the repository from one contributer, and pull any changes they may not have seen from all the other contributers. Mercurial is extremely easy to perform off-site backups and remote mirrors. Plus I can set it up to perform traditional backups to tape or disk (for archival purposes). This way if there are any problems, we can always roll back, or undo or perform disaster recovery. To do backups, you just use hg clone -U myrepo myrepo.bak to create a clone of the myrepo repository and then just perform a nightly backup, that way automated nightly backups are being performed on the repository. This way you have something to roll back to, even if disaster does strike (a dev somehow hoses everything up, which is unlikely) but regardless it never hurts to have backups and consistent snapshots. Mercurial maintains a complete copy of history in each clone, so it creates numerous backups (and lots of redundancy). By having a dedicated server online, that will just act as a main peer at least all the other peers can feed/seed back to the main peer anytime they are online or connected to the internet. The main server will simply act as a seed, and all the other dev's computers (that may go on or offline) will simply act as peers for redundancy purposes. It's almost similar to a torrent type of architecture (P2P) which is good for speed of uploading/committing large updates since it can pull from any of the available online peers that are online. (Very similar to torrent). I could maintain a seed server, and just perform nightly backups onto a 2TB drive, and that way we could easily have 6 months, or even a year or two of nightly backups for disaster/archival purposes just in case any accidents do happen. Mark On Mon, Feb 22, 2010 at 4:01 PM, Cristina Videira Lopes lo...@ics.uci.eduwrote: Yeah, we could have done that in theory. In practice, we're all still fairly ignorant when it comes to using git, and we've all had close encounters with git disasters. Melanie is the one keeping branches in sync, she has spent a lot of time resolving conflicts by hand, helping out the messes we get into, etc. She can do that with one branch but not with many... so until several of us learn how to deal with git errors effectively, it's not wise to multiply branches. We'll learn as we go,
Re: [Opensim-dev] Status of presence refactor?
On Feb 22, 2010, at 2:32 PM, Justin Clark-Casey wrote: You're right - I don't have any numbers so perhaps no-one is doing that. I took the liberty of copying this over to the users list to see if any hands are raised there. If SQLite is just being used for single person/demonstration installations then password reset sounds good enough. I agree that it's not worth wasting valuable time on a more complete solution. There is a more complete solution: $ cp userprofile.db auth.db $ OpenSim.exe This will take care of migrating both the user account data and the authentication data. I just cringe at the thought of people using OpenSim+SQLite in ways that a simple password reset mechanism won't be enough. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Status of presence refactor?
There is also a nice TortoiseHG client (identical to TortoiseSVN) for mercurial, for both Windows and Linux users. It makes Mercurial extremely easy to use (in both Windows and Linux). http://mercurial.selenic.com/wiki/TortoiseHg It includes a nice Tortoise mercurial GUI and merge tools (and it's integrated with windows/file explorer). It would seem MUCH easier for the dev's to use Mercurial than Git. I can help with the backend work and helping with the transition/setting it up, but I do think Mercurial would make much more sense than Git. Mercurial is by far the fastest (other than Bazaar) and has a nice P2P architecture which is great for mobile (and laptop) users, or people that are not connected to the internet 24/7. Mark On Mon, Feb 22, 2010 at 4:41 PM, Mark Malewski mark.malew...@gmail.comwrote: * we're all still fairly ignorant when it comes to using git, and * * we've all had close encounters with git disasters.* Why are we using GIT? I understand that it's supposed to be better than CVS/SVN, but it's still a dinosaur compared to Mercurial or Bazaar. Why aren't we using Mercurial? * Melanie is the one keeping branches in sync, she has spent * * a lot of time resolving conflicts by hand, helping out the * * messes we get into, etc. * That seems extremely insane, and that's the whole problem with Git. It would make more sense to use something like Mercurial. Much easier with the intelligent syncing feature of Mercurial (which Git doesn't have, so everything must be done manually with Git and wastes a lot of time). * She can do that with one branch but not with many... * It would really make much more sense to switch over to Mercurial (or Bazaar) for the development work. Mercurial (and Bazaar) are even faster than Git, plus Mercurial has the best intelligent merging and allows users to work only on one directory of the repository (to help limit damage, etc.). The Intelligent Merging features are nice (make commits easy on the dev's). Lots of great features in Mercurial, and it's probably by far the best (or at least much better than CVS, Subversion, or Git). Bazaar and Mercurial are probably the two best. http://versioncontrolblog.com/comparison/Bazaar/CVS/Git/Mercurial/Subversion/index.html I could setup a Mercurial or Bazaar repository on a server (for redundancy purposes) and then each of the Dev's can just use Mercurial on their desktop to collaborate peer to peer (and I can perform backups of the main Mercurial server, just so we have backup, snapshot and restore points). It will help with the intelligent merging (for numerous dev's all working together all at the same time) and we can always feed copies of the Merc repository back to the old Git and just use the old Git repository as a public archive. Mercurial is extremely easy to use: http://hgbook.red-bean.com/read/mercurial-in-daily-use.html#id496680 Merc is peer to peer, and supports backups/mirroring, and has lots of great features. I can just setup a master server (with a cron job) to automatically pull periodic changes from your local repositories every hour (for all the core dev's). Since Mercurial maintains a complete copy of history in each clone (every single peer), everyone who uses Mercurial to collaborate on a project can potentially act as a source of backups in the event of a catastrophe (since there is no real centralized server). If a central repository becomes unavailable, you simply just clone a copy of the repository from one contributer, and pull any changes they may not have seen from all the other contributers. Mercurial is extremely easy to perform off-site backups and remote mirrors. Plus I can set it up to perform traditional backups to tape or disk (for archival purposes). This way if there are any problems, we can always roll back, or undo or perform disaster recovery. To do backups, you just use hg clone -U myrepo myrepo.bak to create a clone of the myrepo repository and then just perform a nightly backup, that way automated nightly backups are being performed on the repository. This way you have something to roll back to, even if disaster does strike (a dev somehow hoses everything up, which is unlikely) but regardless it never hurts to have backups and consistent snapshots. Mercurial maintains a complete copy of history in each clone, so it creates numerous backups (and lots of redundancy). By having a dedicated server online, that will just act as a main peer at least all the other peers can feed/seed back to the main peer anytime they are online or connected to the internet. The main server will simply act as a seed, and all the other dev's computers (that may go on or offline) will simply act as peers for redundancy purposes. It's almost similar to a torrent type of architecture (P2P) which is good for speed of uploading/committing large updates since it can pull from any of the available
Re: [Opensim-dev] Status of presence refactor?
Mic, It seems like a good request. I like the idea of a tag, but maybe we should create two tags? Use a 0.6.8.x tag prior to the merge, and a 0.6.9.x tag after the merge? Then save the 0.7 tag for the stable RC? * Can I make one request... Can we tag the current master as * * 0.6.9 (or something) prior to the merge? * Maybe just tag the current master as a 0.6.8.x prior to the merge, then just create a 0.6.9.x tag after the merge? That way we have two tags (a 0.6.8.x tag prior to merge and a 0.6.9.x tag after merge). Then we can work on bug testing, and bug fixing and then decide which of the two tags we'll use for the 0.7 RC. If the merge breaks too many things, or is too unstable we can just revert to the 0.6.8.x tag series. If the merge doesn't hurt/damage things too badly, and the fixes can all be done fairly easily, then we can use the 0.6.9.x tag to use for a 0.7 stable RC for the final release candidate (after it goes through the whole formal RC bug-testing/bug-fixing release candidate process). This way at least we have two separate tags (0.6.8.x and 0.6.9.x) that we can use as tagged reference points for testing, prior to the 0.7 RC? This way the current state could be tagged as a 0.6.8.x tag, then we can use 0.6.9.x for: 1) merge presence-refactor into master 2) create a sop-refactor branch from master immediately after Then depending on how much work needs to be done after the merge of presence-refactor into master, and the sop-refactor branch work that needs to be done. This way we can have two separate tagged releases that we can use for bug testing and bug reporting. Then depending on how much is broken (and what the timeline is to fix the bugs) then we'll either just use either the 0.6.8.x tag (pre-merge) or the 0.6.9.x tag (post merge) for the stable 0.7 RC. Mark On Mon, Feb 22, 2010 at 10:20 AM, Mic Bowman cmick...@gmail.com wrote: Can I make one request... Can we tag the current master as 0.6.9 (or something) prior to the merge? --mic On Mon, Feb 22, 2010 at 8:13 AM, d...@metaverseink.com wrote: We can, by this order: 1) merge presence-refactor into master 2) create a sop-refactor branch from master immediately after 3) create a 0.7 branch some time later I would like to propose that the sop refactoring work be done in a branch rather than in the master branch, similar to what we did for the services refactoring. It works pretty well -- gives the refactoring devs peace of mind to leave things unstable and isolates the master branch from prolonged instability. Also, are there any suggestions for Adam before he starts doing this? He sent out a document some time ago, but there wasn't a lot of feedback or discussion. Are there any alternatives or wishes for his proposed work? Justin Clark-Casey wrote: Frisby, Adam wrote: I would like to start the SOP refactor fairly soon - what if once 0.7 is tagged for the RC process; I go and and make a new branch; we can sic testers on the presence-branch, while dev happens on the branch I tag? My concern with branching for 0.7 release candidates immediately after the presence-refactor merge is that we won't get everybody helping to iron out the inevitable hiccups since most people follow master. Waiting a couple of weeks for at least some of this to happen is the minimum, I feel. Ideally, I'd like that to be longer but I know that you and other folk want to press ahead. I guess some of this depends on how disruptive the refactor is. What do you think? I'm assuming there will be breakage but perhaps I'm wrong? Of course, I guess you could create a separate sop-refactor branch at any point and start work there, possibly merging back to master and continuing in master once 0.7 RC has been branched. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Status of presence refactor?
I don't think we can survive another move. Also, I don't want to learn another toolchain, I want to develop. -1 Melanie Mark Malewski wrote: * we're all still fairly ignorant when it comes to using git, and * * we've all had close encounters with git disasters.* Why are we using GIT? I understand that it's supposed to be better than CVS/SVN, but it's still a dinosaur compared to Mercurial or Bazaar. Why aren't we using Mercurial? * Melanie is the one keeping branches in sync, she has spent * * a lot of time resolving conflicts by hand, helping out the * * messes we get into, etc. * That seems extremely insane, and that's the whole problem with Git. It would make more sense to use something like Mercurial. Much easier with the intelligent syncing feature of Mercurial (which Git doesn't have, so everything must be done manually with Git and wastes a lot of time). * She can do that with one branch but not with many... * It would really make much more sense to switch over to Mercurial (or Bazaar) for the development work. Mercurial (and Bazaar) are even faster than Git, plus Mercurial has the best intelligent merging and allows users to work only on one directory of the repository (to help limit damage, etc.). The Intelligent Merging features are nice (make commits easy on the dev's). Lots of great features in Mercurial, and it's probably by far the best (or at least much better than CVS, Subversion, or Git). Bazaar and Mercurial are probably the two best. http://versioncontrolblog.com/comparison/Bazaar/CVS/Git/Mercurial/Subversion/index.html I could setup a Mercurial or Bazaar repository on a server (for redundancy purposes) and then each of the Dev's can just use Mercurial on their desktop to collaborate peer to peer (and I can perform backups of the main Mercurial server, just so we have backup, snapshot and restore points). It will help with the intelligent merging (for numerous dev's all working together all at the same time) and we can always feed copies of the Merc repository back to the old Git and just use the old Git repository as a public archive. Mercurial is extremely easy to use: http://hgbook.red-bean.com/read/mercurial-in-daily-use.html#id496680 Merc is peer to peer, and supports backups/mirroring, and has lots of great features. I can just setup a master server (with a cron job) to automatically pull periodic changes from your local repositories every hour (for all the core dev's). Since Mercurial maintains a complete copy of history in each clone (every single peer), everyone who uses Mercurial to collaborate on a project can potentially act as a source of backups in the event of a catastrophe (since there is no real centralized server). If a central repository becomes unavailable, you simply just clone a copy of the repository from one contributer, and pull any changes they may not have seen from all the other contributers. Mercurial is extremely easy to perform off-site backups and remote mirrors. Plus I can set it up to perform traditional backups to tape or disk (for archival purposes). This way if there are any problems, we can always roll back, or undo or perform disaster recovery. To do backups, you just use hg clone -U myrepo myrepo.bak to create a clone of the myrepo repository and then just perform a nightly backup, that way automated nightly backups are being performed on the repository. This way you have something to roll back to, even if disaster does strike (a dev somehow hoses everything up, which is unlikely) but regardless it never hurts to have backups and consistent snapshots. Mercurial maintains a complete copy of history in each clone, so it creates numerous backups (and lots of redundancy). By having a dedicated server online, that will just act as a main peer at least all the other peers can feed/seed back to the main peer anytime they are online or connected to the internet. The main server will simply act as a seed, and all the other dev's computers (that may go on or offline) will simply act as peers for redundancy purposes. It's almost similar to a torrent type of architecture (P2P) which is good for speed of uploading/committing large updates since it can pull from any of the available online peers that are online. (Very similar to torrent). I could maintain a seed server, and just perform nightly backups onto a 2TB drive, and that way we could easily have 6 months, or even a year or two of nightly backups for disaster/archival purposes just in case any accidents do happen. Mark On Mon, Feb 22, 2010 at 4:01 PM, Cristina Videira Lopes lo...@ics.uci.eduwrote: Yeah, we could have done that in theory. In practice, we're all still fairly ignorant when it comes to using git, and we've all had close encounters with git disasters. Melanie is the one keeping branches in sync, she has spent a lot of time resolving conflicts by
Re: [Opensim-dev] Status of presence refactor?
Mark, Your offer is quite generous, however most of us already have test regions set up to facilitate development. On the subject of mercurial, we spent several developer-months switching over to git and several more months after that getting used to it and becoming productive again. I doubt you'll mind many of us willing to switch again to yet another revision control system and spending the time to familiarize ourselves with it. What may be more useful is coordinated independent testing *specifically for the purpose of testing* with properly designed and documented plans, goals, methods, and well documented results. If good quality tests can be run independently of development and these tests produce valid, repeatable results with little overhead required from the developers, and the results can be provided to developers in a timely manner, then I suspect it could significantly improve development efforts. If developers need to spend time setting up new test regions in addition to those they already have, then it's likely it will slow overall development down. -dahlia On Mon, Feb 22, 2010 at 3:27 PM, Mark Malewski mark.malew...@gmail.comwrote: Devs, I can setup 4 sandbox servers for tagged release bug testing: Server 1: Ubuntu Linux w/ SQ Lite Server 2: Ubuntu Linux w/ MySQL Server 3: Windows 2008 R2 w/ SQ Lite Server 4: Windows 2008 R2 w/ MySQL Then the dev's can decide which tagged versions they would like to install on which boxes. That way they can test the 0.6.8.x series (pre-merge) and 0.6.9.x series (post-merge). I could always bring another 4 servers online (and use four for 0.6.8.x and four for 0.6.9.x) if need be. But at least this way we have a wide range of platforms for testing. That way the dev's can just roll stuff out, and have sandboxes for bug testing/fixing things and development of the upcoming 0.7 RC. If we can't get the merge's working smoothly before the 0.7 RC, then we can always save the 0.6.9.x branch for a future 0.7.1 release (with updated merges). * We can, by this order: 1) merge presence-refactor into master 2) create a sop-refactor branch from master immediately after * This way we're not under the gun to get the merge fixed prior to the 0.7 RC. If too much is broken after the merge, then we can always just release the 0.6.8.x tag as the 0.7 RC Then just release the 0.6.9.x tag (after fixes) as a 0.7.1 release (an update to the 0.7 RC). If the fixes after the merge are easy, then we can always release the 0.6.9.x tag as the 0.7 RC. If the fixes after the merge are ugly (and too time consuming) then we can just revert back to the 0.6.8.x tag and release that as 0.7 RC, and then save the 0.6.9.x for the 0.7.1 RC update. This way we can have a 0.7 RC stable released fairly soon, and also have a 0.7.1 RC that follows shortly (with the merge). This would at least give the documenters and bug testers time to beat up the servers, and do bug testing, and also work on updating documentation (for the new upcoming releases) and get tutorial/manuals/documents written prior to the 0.7 RC getting released. With 4 servers dedicated to the 0.7 RC (two for 0.6.8.x and two for 0.6.9.x), that will at least give developers a nice sandbox platform for developing/working, and also give the bug testers the ability to move between boxes for documenting/mantis bug reporting/bug testing, and test everything thoroughly prior to the formal 0.7 RC release. Mark On Mon, Feb 22, 2010 at 5:09 PM, Mark Malewski mark.malew...@gmail.comwrote: Mic, It seems like a good request. I like the idea of a tag, but maybe we should create two tags? Use a 0.6.8.x tag prior to the merge, and a 0.6.9.x tag after the merge? Then save the 0.7 tag for the stable RC? * Can I make one request... Can we tag the current master as * * 0.6.9 (or something) prior to the merge? * Maybe just tag the current master as a 0.6.8.x prior to the merge, then just create a 0.6.9.x tag after the merge? That way we have two tags (a 0.6.8.x tag prior to merge and a 0.6.9.x tag after merge). Then we can work on bug testing, and bug fixing and then decide which of the two tags we'll use for the 0.7 RC. If the merge breaks too many things, or is too unstable we can just revert to the 0.6.8.x tag series. If the merge doesn't hurt/damage things too badly, and the fixes can all be done fairly easily, then we can use the 0.6.9.x tag to use for a 0.7 stable RC for the final release candidate (after it goes through the whole formal RC bug-testing/bug-fixing release candidate process). This way at least we have two separate tags (0.6.8.x and 0.6.9.x) that we can use as tagged reference points for testing, prior to the 0.7 RC? This way the current state could be tagged as a 0.6.8.x tag, then we can use 0.6.9.x for: 1) merge presence-refactor into master 2) create a sop-refactor branch from master immediately after Then
Re: [Opensim-dev] Status of presence refactor?
Devs, I can setup 4 sandbox servers for tagged release bug testing: Server 1: Ubuntu Linux w/ SQ Lite Server 2: Ubuntu Linux w/ MySQL Server 3: Windows 2008 R2 w/ SQ Lite Server 4: Windows 2008 R2 w/ MySQL Then the dev's can decide which tagged versions they would like to install on which boxes. That way they can test the 0.6.8.x series (pre-merge) and 0.6.9.x series (post-merge). I could always bring another 4 servers online (and use four for 0.6.8.x and four for 0.6.9.x) if need be. But at least this way we have a wide range of platforms for testing. That way the dev's can just roll stuff out, and have sandboxes for bug testing/fixing things and development of the upcoming 0.7 RC. If we can't get the merge's working smoothly before the 0.7 RC, then we can always save the 0.6.9.x branch for a future 0.7.1 release (with updated merges). * We can, by this order: 1) merge presence-refactor into master 2) create a sop-refactor branch from master immediately after * This way we're not under the gun to get the merge fixed prior to the 0.7 RC. If too much is broken after the merge, then we can always just release the 0.6.8.x tag as the 0.7 RC Then just release the 0.6.9.x tag (after fixes) as a 0.7.1 release (an update to the 0.7 RC). If the fixes after the merge are easy, then we can always release the 0.6.9.x tag as the 0.7 RC. If the fixes after the merge are ugly (and too time consuming) then we can just revert back to the 0.6.8.x tag and release that as 0.7 RC, and then save the 0.6.9.x for the 0.7.1 RC update. This way we can have a 0.7 RC stable released fairly soon, and also have a 0.7.1 RC that follows shortly (with the merge). This would at least give the documenters and bug testers time to beat up the servers, and do bug testing, and also work on updating documentation (for the new upcoming releases) and get tutorial/manuals/documents written prior to the 0.7 RC getting released. With 4 servers dedicated to the 0.7 RC (two for 0.6.8.x and two for 0.6.9.x), that will at least give developers a nice sandbox platform for developing/working, and also give the bug testers the ability to move between boxes for documenting/mantis bug reporting/bug testing, and test everything thoroughly prior to the formal 0.7 RC release. Mark On Mon, Feb 22, 2010 at 5:09 PM, Mark Malewski mark.malew...@gmail.comwrote: Mic, It seems like a good request. I like the idea of a tag, but maybe we should create two tags? Use a 0.6.8.x tag prior to the merge, and a 0.6.9.x tag after the merge? Then save the 0.7 tag for the stable RC? * Can I make one request... Can we tag the current master as * * 0.6.9 (or something) prior to the merge? * Maybe just tag the current master as a 0.6.8.x prior to the merge, then just create a 0.6.9.x tag after the merge? That way we have two tags (a 0.6.8.x tag prior to merge and a 0.6.9.x tag after merge). Then we can work on bug testing, and bug fixing and then decide which of the two tags we'll use for the 0.7 RC. If the merge breaks too many things, or is too unstable we can just revert to the 0.6.8.x tag series. If the merge doesn't hurt/damage things too badly, and the fixes can all be done fairly easily, then we can use the 0.6.9.x tag to use for a 0.7 stable RC for the final release candidate (after it goes through the whole formal RC bug-testing/bug-fixing release candidate process). This way at least we have two separate tags (0.6.8.x and 0.6.9.x) that we can use as tagged reference points for testing, prior to the 0.7 RC? This way the current state could be tagged as a 0.6.8.x tag, then we can use 0.6.9.x for: 1) merge presence-refactor into master 2) create a sop-refactor branch from master immediately after Then depending on how much work needs to be done after the merge of presence-refactor into master, and the sop-refactor branch work that needs to be done. This way we can have two separate tagged releases that we can use for bug testing and bug reporting. Then depending on how much is broken (and what the timeline is to fix the bugs) then we'll either just use either the 0.6.8.x tag (pre-merge) or the 0.6.9.x tag (post merge) for the stable 0.7 RC. Mark On Mon, Feb 22, 2010 at 10:20 AM, Mic Bowman cmick...@gmail.com wrote: Can I make one request... Can we tag the current master as 0.6.9 (or something) prior to the merge? --mic On Mon, Feb 22, 2010 at 8:13 AM, d...@metaverseink.com wrote: We can, by this order: 1) merge presence-refactor into master 2) create a sop-refactor branch from master immediately after 3) create a 0.7 branch some time later I would like to propose that the sop refactoring work be done in a branch rather than in the master branch, similar to what we did for the services refactoring. It works pretty well -- gives the refactoring devs peace of mind to leave things unstable and isolates the master branch from prolonged instability.
Re: [Opensim-dev] Status of presence refactor?
* **I don't think we can survive another move. Also, I don't want to* * learn another toolchain, I want to develop.* I know, but as an engineer (hardware/server/network administrator) it's my job to help SUPPORT you, by creating a nice environment for you to do your work. ;-) If you can spend 3 minutes reading this simple (and easy to use) tutorial for TortoiseHG (or if you've ever used TortoiseSVN), then you can easily use Mercurial: http://draketo.de/light/english/mercurial/short-introduction-mercurial-tortoisehg It usually takes less than 3 minutes for a developer to figure out how to right click, and how to click Synchronize or Create clone. You don't need to learn or memorize any commands, just use TortoiseHG. It's automatically embedded into Windows File Explorer (or Linux) so all you have to do is right click on a folder or file and you can rename, update, synchronize, commit or do whatever you want with just one simple click. Intelligent Synchronization really does make life easier for developers on large collaboration projects. We don't have to do an immediate transition to Mercurial, but I can setup both Git and Mercurial (concurrently) and then we can slowly move users over to Mercurial (once they feel comfortable) and I can create a nice online tutorial for the dev's that are unfamiliar with Merc, and also provide links and a tutorial for TortoiseHG (just so dev's can see how extremely easy it is, and it really requires NO learning at all). You just right click on a file, or right click on a folder, and then select merge and that's it. The easy-to-use GUI really makes life EXTREMELY simple on the dev's. I think Mercurial is much better than Git for mobile users, and a project like OpenSim. I can handle the backend work (server admin, backups, etc.). This way the dev's can just focus on developing (and writing code). I can run both a Git and a Mercurial on the same box, that way it doesn't even matter what the dev's are using, both will point towards the same folders on the server. This way as dev's slowly move (and transition) from Git over to Mercurial, it will make life easy on them. Once you start using Mercurial, I really do think you'll love it (and will wonder how you ever did without it). Mercurial has the nice user GUI from TortoiseSVN (TortoiseHG for both Windows and Linux) but has the speed and advanced tools (intelligent merging/synchronization) of Mercurial/Bazaar. This way we can have plenty of branches, and it takes the headache of maintaining/doing manual conflicts (merges) out of the question. This way you can spend your time developing, and not dealing with the headaches of merging/conflicts. I can help with the implementation (and setting up a repository server, that will handle both Git and Mercurial, and I supposed I could even setup a Bazaar server as well if anyone really wants/needs Bazaar) but Mercurial really should be the de facto choice for most of the Devs. Once the server is setup, and I can write a nice tutorial on using Mercurial, it would be so much easier for the dev's (especially mobile users that are using laptops, or are not connected to the internet 24/7). Plus the speed of doing large commits is about 800-1000% faster (depending on how many peers are currently online). Since large commits are sent to various peers, and then fed back to the main server (similar to a torrent/peer/seed type of architecture). This way the one main server acts as a seed for the developers, and it's ALWAYS online, and it seeds the network, but transfers are done P2P and also fed back to the main seed. That way the seed always has an up to date version (that is archived and backed up nightly). It may sound like a lot of work, but really it's not. I can get it done in about a day or two. Then maybe another day for writing up tutorials. Then the dev's can transition to Mercurial at their own pace. This way there is no pressure, but the advantages of Mercurial (and intelligent merging) really are what would be best for a collaborative project like this. * **I don't think we can survive another move. * * * You just focus on developing, I can do the server build, setup Merc and Git and also handle the move. We can save the old Git for archival purposes (just leave it where it's at). I can just use the new box for Git and Mercurial (for the dev's) and then feed the new repository back to the old Git (for an extra online archival as well). This way the dev's can move over to the new Mercurial (at their own will), and the new repository server will handle everything (and the old Git will just be used for archival purposes). * * * Also, I don't want to learn another toolchain, I want to develop.* With TortoiseHG you don't have to learn anything. You just point, and right click. You don't need to know any commands, don't need to do any packing/repacking of Git, and don't need to do anything. As a user/developer Mercurial is by far the easiest to use
Re: [Opensim-dev] Status of presence refactor?
Let's bring the focus of this thread back. We're about to merge the presence-refactor branch into the master branch, and then we'll need testers, some of us will be working overtime to fix the bugs, and hopefully Fly-Man- will update Wiredux sometime soon. Then a big effort in documentation will start. There's a lot of work to do. The last thing we need is switching development tools. On Feb 22, 2010, at 4:58 PM, Mark Malewski wrote: I don't think we can survive another move. Also, I don't want to learn another toolchain, I want to develop. I know, but as an engineer (hardware/server/network administrator) it's my job to help SUPPORT you, by creating a nice environment for you to do your work. ;-) If you can spend 3 minutes reading this simple (and easy to use) tutorial for TortoiseHG (or if you've ever used TortoiseSVN), then you can easily use Mercurial: http://draketo.de/light/english/mercurial/short-introduction-mercurial-tortoisehg It usually takes less than 3 minutes for a developer to figure out how to right click, and how to click Synchronize or Create clone. You don't need to learn or memorize any commands, just use TortoiseHG. It's automatically embedded into Windows File Explorer (or Linux) so all you have to do is right click on a folder or file and you can rename, update, synchronize, commit or do whatever you want with just one simple click. Intelligent Synchronization really does make life easier for developers on large collaboration projects. We don't have to do an immediate transition to Mercurial, but I can setup both Git and Mercurial (concurrently) and then we can slowly move users over to Mercurial (once they feel comfortable) and I can create a nice online tutorial for the dev's that are unfamiliar with Merc, and also provide links and a tutorial for TortoiseHG (just so dev's can see how extremely easy it is, and it really requires NO learning at all). You just right click on a file, or right click on a folder, and then select merge and that's it. The easy-to-use GUI really makes life EXTREMELY simple on the dev's. I think Mercurial is much better than Git for mobile users, and a project like OpenSim. I can handle the backend work (server admin, backups, etc.). This way the dev's can just focus on developing (and writing code). I can run both a Git and a Mercurial on the same box, that way it doesn't even matter what the dev's are using, both will point towards the same folders on the server. This way as dev's slowly move (and transition) from Git over to Mercurial, it will make life easy on them. Once you start using Mercurial, I really do think you'll love it (and will wonder how you ever did without it). Mercurial has the nice user GUI from TortoiseSVN (TortoiseHG for both Windows and Linux) but has the speed and advanced tools (intelligent merging/ synchronization) of Mercurial/Bazaar. This way we can have plenty of branches, and it takes the headache of maintaining/doing manual conflicts (merges) out of the question. This way you can spend your time developing, and not dealing with the headaches of merging/conflicts. I can help with the implementation (and setting up a repository server, that will handle both Git and Mercurial, and I supposed I could even setup a Bazaar server as well if anyone really wants/ needs Bazaar) but Mercurial really should be the de facto choice for most of the Devs. Once the server is setup, and I can write a nice tutorial on using Mercurial, it would be so much easier for the dev's (especially mobile users that are using laptops, or are not connected to the internet 24/7). Plus the speed of doing large commits is about 800-1000% faster (depending on how many peers are currently online). Since large commits are sent to various peers, and then fed back to the main server (similar to a torrent/peer/seed type of architecture). This way the one main server acts as a seed for the developers, and it's ALWAYS online, and it seeds the network, but transfers are done P2P and also fed back to the main seed. That way the seed always has an up to date version (that is archived and backed up nightly). It may sound like a lot of work, but really it's not. I can get it done in about a day or two. Then maybe another day for writing up tutorials. Then the dev's can transition to Mercurial at their own pace. This way there is no pressure, but the advantages of Mercurial (and intelligent merging) really are what would be best for a collaborative project like this. I don't think we can survive another move. You just focus on developing, I can do the server build, setup Merc and Git and also handle the move. We can save the old Git for archival purposes (just leave it where it's at). I can just use the new box for Git and Mercurial (for the dev's) and then feed the new repository back to the old Git
Re: [Opensim-dev] Status of presence refactor?
Hi, rant skipped _everything_ from the first mention of Tortoise Apparently, you don't know much about the people you are so eager to support. I use Linux, and work exclusively on the command line. I don't use any Windows OS at all. Also, I'd sooner be found dead that be found using a development GUI/IDE. Everyone here knows that. I'm vocal enough about it. /rant Outside of that, your generosity is appreciated, but I, for one, am not interested in Mercurial at this time. Also, I don't believe that we would be happy to see an external contributor manage our repo. It is on our own servers and currently managed by myself, an OpenSim core member. I could probably install Mercurial myself, but I am, as already stated, not interested in learning yet another DVCS's semantics and toolchain. The dust on the git migration has barely settled and we're happy for now, even I, as the merge mistress. I believe further treatises on Mercurial are not required at this time. Melanie Mark Malewski wrote: * **I don't think we can survive another move. Also, I don't want to* * learn another toolchain, I want to develop.* I know, but as an engineer (hardware/server/network administrator) it's my job to help SUPPORT you, by creating a nice environment for you to do your work. ;-) If you can spend 3 minutes reading this simple (and easy to use) tutorial for TortoiseHG (or if you've ever used TortoiseSVN), then you can easily use Mercurial: http://draketo.de/light/english/mercurial/short-introduction-mercurial-tortoisehg It usually takes less than 3 minutes for a developer to figure out how to right click, and how to click Synchronize or Create clone. You don't need to learn or memorize any commands, just use TortoiseHG. It's automatically embedded into Windows File Explorer (or Linux) so all you have to do is right click on a folder or file and you can rename, update, synchronize, commit or do whatever you want with just one simple click. Intelligent Synchronization really does make life easier for developers on large collaboration projects. We don't have to do an immediate transition to Mercurial, but I can setup both Git and Mercurial (concurrently) and then we can slowly move users over to Mercurial (once they feel comfortable) and I can create a nice online tutorial for the dev's that are unfamiliar with Merc, and also provide links and a tutorial for TortoiseHG (just so dev's can see how extremely easy it is, and it really requires NO learning at all). You just right click on a file, or right click on a folder, and then select merge and that's it. The easy-to-use GUI really makes life EXTREMELY simple on the dev's. I think Mercurial is much better than Git for mobile users, and a project like OpenSim. I can handle the backend work (server admin, backups, etc.). This way the dev's can just focus on developing (and writing code). I can run both a Git and a Mercurial on the same box, that way it doesn't even matter what the dev's are using, both will point towards the same folders on the server. This way as dev's slowly move (and transition) from Git over to Mercurial, it will make life easy on them. Once you start using Mercurial, I really do think you'll love it (and will wonder how you ever did without it). Mercurial has the nice user GUI from TortoiseSVN (TortoiseHG for both Windows and Linux) but has the speed and advanced tools (intelligent merging/synchronization) of Mercurial/Bazaar. This way we can have plenty of branches, and it takes the headache of maintaining/doing manual conflicts (merges) out of the question. This way you can spend your time developing, and not dealing with the headaches of merging/conflicts. I can help with the implementation (and setting up a repository server, that will handle both Git and Mercurial, and I supposed I could even setup a Bazaar server as well if anyone really wants/needs Bazaar) but Mercurial really should be the de facto choice for most of the Devs. Once the server is setup, and I can write a nice tutorial on using Mercurial, it would be so much easier for the dev's (especially mobile users that are using laptops, or are not connected to the internet 24/7). Plus the speed of doing large commits is about 800-1000% faster (depending on how many peers are currently online). Since large commits are sent to various peers, and then fed back to the main server (similar to a torrent/peer/seed type of architecture). This way the one main server acts as a seed for the developers, and it's ALWAYS online, and it seeds the network, but transfers are done P2P and also fed back to the main seed. That way the seed always has an up to date version (that is archived and backed up nightly). It may sound like a lot of work, but really it's not. I can get it done in about a day or two. Then maybe another day for writing up tutorials. Then the dev's can transition to Mercurial at
Re: [Opensim-dev] Status of presence refactor?
* Your offer is quite generous, however most of us already have test regions set * * up to facilitate development.* Ok, I was just offering. So at least we'd have various platforms that the dev's (and alpha testing community) could use for sandboxing and bug reporting platforms. * On the subject of mercurial, we spent several developer-months switching over * * to git and several more months after that getting used to it and becoming * * productive again. I doubt you'll mind many of us willing to switch again to yet * * another revision control system and spending the time to familiarize ourselves * * with it.* Ok, I was just pointing out that Git is a headache to maintain, and it lacks intelligent merging. The housekeeping that Git requires is quite time consuming. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Status of presence refactor?
Very cool! Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com Sent: Sunday, 21 February 2010 9:43 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Status of presence refactor? News: the SQLite connector is done and working in the presence-refactor branch. UserAccount data is automatically migrated into the new table. People using SQLite-powered OpenSims will have to reset the passwords manually before they are able to login (with console command reset user password). This does not affect MySql-powered opensims, only SQLite. Hopefully Melanie_t will finish Friends today. We'll be ready to merge any time now. Frisby, Adam wrote: I would like to start the SOP refactor fairly soon - what if once 0.7 is tagged for the RC process; I go and and make a new branch; we can sic testers on the presence-branch, while dev happens on the branch I tag? Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey Sent: Friday, 19 February 2010 3:25 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Status of presence refactor? Melanie wrote: I would not like to see the refactor start in the branch, because that would postpone a merge indefinitely. Yes, please whatever happens, do not start any sog refactoring in Master until presence-refactor has been merged and we've started a branch for 0.7. In fact, when presence-refactor is merged with Master I think that we should wait at least 2 weeks before branching for 0.7 in order for all active developers to iron out any significant bugs associated with the merge. At a minimum, the 0.7 branch itself would be subject to the same release candidate and bug triage procedure as was 0.6.8. Only after this would 0.7 be tagged. I think that this is the very minimum we need to do in order to be a credible project. This would also give us an opportunity to get the documentation into a shape where at least super-intelligent pandimensional mice can understand it :) At the same time as 0.7 is branched, I also think that it would be prudent to branch for a potential 0.7.0.1. If all goes well with the sog refactor this will never see the light of day. But I think we should give ourselves a means of working with the old sog code in case the refactor encounters trouble. The sog refactor is far from trivial. However, the refactor caould be started in a NEW branch that is based off the current presence-refactor. The friends and SQLite functionality could be merged back to that new branch when they are completed. Git allows this easily. That sounds like a good idea. Melanie d...@metaverseink.com wrote: I could, but I'm hesitant to make diva distro releases from branches that aren't the master branch. Plus, so far the differences between the two branches are purely internal; there is no functional difference, or new bug fixes, or anything like that. The new architecture will allow for lots of exciting things to happen, but, again, I'm hesitant in making them happen in the branch. I'd rather merge this to master. Robert Martin wrote: On Thu, Feb 18, 2010 at 10:15 AM, d...@metaverseink.com wrote: Sigh. It's ready. It's been fully operational for several weeks, modulo buglets. It hasn't been merged because the SQLite connector hasn't been redone and at least Melanie doesn't want to merge without it. could you release a copy of Diva with the updated code (since Diva of course does not use SQlite)? ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- Justin Clark-Casey (justincc) http://justincc.org http://twitter.com/justincc ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Status of presence refactor?
I would like to start the SOP refactor fairly soon - what if once 0.7 is tagged for the RC process; I go and and make a new branch; we can sic testers on the presence-branch, while dev happens on the branch I tag? Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Justin Clark-Casey Sent: Friday, 19 February 2010 3:25 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Status of presence refactor? Melanie wrote: I would not like to see the refactor start in the branch, because that would postpone a merge indefinitely. Yes, please whatever happens, do not start any sog refactoring in Master until presence-refactor has been merged and we've started a branch for 0.7. In fact, when presence-refactor is merged with Master I think that we should wait at least 2 weeks before branching for 0.7 in order for all active developers to iron out any significant bugs associated with the merge. At a minimum, the 0.7 branch itself would be subject to the same release candidate and bug triage procedure as was 0.6.8. Only after this would 0.7 be tagged. I think that this is the very minimum we need to do in order to be a credible project. This would also give us an opportunity to get the documentation into a shape where at least super-intelligent pandimensional mice can understand it :) At the same time as 0.7 is branched, I also think that it would be prudent to branch for a potential 0.7.0.1. If all goes well with the sog refactor this will never see the light of day. But I think we should give ourselves a means of working with the old sog code in case the refactor encounters trouble. The sog refactor is far from trivial. However, the refactor caould be started in a NEW branch that is based off the current presence-refactor. The friends and SQLite functionality could be merged back to that new branch when they are completed. Git allows this easily. That sounds like a good idea. Melanie d...@metaverseink.com wrote: I could, but I'm hesitant to make diva distro releases from branches that aren't the master branch. Plus, so far the differences between the two branches are purely internal; there is no functional difference, or new bug fixes, or anything like that. The new architecture will allow for lots of exciting things to happen, but, again, I'm hesitant in making them happen in the branch. I'd rather merge this to master. Robert Martin wrote: On Thu, Feb 18, 2010 at 10:15 AM, d...@metaverseink.com wrote: Sigh. It's ready. It's been fully operational for several weeks, modulo buglets. It hasn't been merged because the SQLite connector hasn't been redone and at least Melanie doesn't want to merge without it. could you release a copy of Diva with the updated code (since Diva of course does not use SQlite)? ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- Justin Clark-Casey (justincc) http://justincc.org http://twitter.com/justincc ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] Status of presence refactor?
Does anyone know what is the current status of the presence refactor - is there any date on when that is going to hit trunk? I'd really like to see 0.7 get tagged soon, so we can begin the big object model refactor. Thanks! Adam ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Status of presence refactor?
Sigh. It's ready. It's been fully operational for several weeks, modulo buglets. It hasn't been merged because the SQLite connector hasn't been redone and at least Melanie doesn't want to merge without it. For me, the SQLite connector continues to be a big question mark. There's the show-stopper bug with mono 2.4.3+, which Teravus has been spending an enormous amount of time trying to fix, without success so far. And then there's writing the code for the new tables, which I might attempt doing if absolutely no one else comes forward; but if I do it, it won't be pretty, and that code risks going outdated again. I just don't know enough about SQLite to do it properly in the amount of time I have to OpenSim. Adam, I hate to suggest this, but you could start your SOG refactor in that branch already. John Hurliman is doing his other implementation of the resource services using that branch. Frisby, Adam wrote: Does anyone know what is the current status of the presence refactor – is there any date on when that is going to hit trunk? I’d really like to see 0.7 get tagged soon, so we can begin the big object model refactor. Thanks! Adam ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Status of presence refactor?
On Thu, Feb 18, 2010 at 10:15 AM, d...@metaverseink.com wrote: Sigh. It's ready. It's been fully operational for several weeks, modulo buglets. It hasn't been merged because the SQLite connector hasn't been redone and at least Melanie doesn't want to merge without it. could you release a copy of Diva with the updated code (since Diva of course does not use SQlite)? -- Robert L Martin ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Status of presence refactor?
I could, but I'm hesitant to make diva distro releases from branches that aren't the master branch. Plus, so far the differences between the two branches are purely internal; there is no functional difference, or new bug fixes, or anything like that. The new architecture will allow for lots of exciting things to happen, but, again, I'm hesitant in making them happen in the branch. I'd rather merge this to master. Robert Martin wrote: On Thu, Feb 18, 2010 at 10:15 AM, d...@metaverseink.com wrote: Sigh. It's ready. It's been fully operational for several weeks, modulo buglets. It hasn't been merged because the SQLite connector hasn't been redone and at least Melanie doesn't want to merge without it. could you release a copy of Diva with the updated code (since Diva of course does not use SQlite)? ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Status of presence refactor?
I had said I would look at SQLite but I honestly don't think I will have time, plus if there are significant mono-related issues then I am not best positioned to work on it in any case, since I don't have any Linux machines at my disposal for mono testing (and my development servers will be going on shipping containers for a month in the very near future). Personally, I have MSSQL code to finish for presence refactor branch (likely a few more days of work there), I would like to get that in if there's plans to move forward at some point, but my pieces shouldn't be too hard to plug in, unlike something like a core architecture refactor. I imagine the SOG refactor is going to take some time to work in since it's a major piece of work - if that scale of work starts before SQLite can be fixed then it will be many more months of waiting for consumers who like tagged revisions before a working revision emerges. Is there another option here? Suggest that SQLite users stick to 0.6.8 (even if it is semi broken I guess it is better than totally broken), push the presence refactor into trunk and continue to plead for more assistance on SQLite? Chris -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com Sent: 18 February 2010 3:16 PM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Status of presence refactor? Sigh. It's ready. It's been fully operational for several weeks, modulo buglets. It hasn't been merged because the SQLite connector hasn't been redone and at least Melanie doesn't want to merge without it. For me, the SQLite connector continues to be a big question mark. There's the show-stopper bug with mono 2.4.3+, which Teravus has been spending an enormous amount of time trying to fix, without success so far. And then there's writing the code for the new tables, which I might attempt doing if absolutely no one else comes forward; but if I do it, it won't be pretty, and that code risks going outdated again. I just don't know enough about SQLite to do it properly in the amount of time I have to OpenSim. Adam, I hate to suggest this, but you could start your SOG refactor in that branch already. John Hurliman is doing his other implementation of the resource services using that branch. Frisby, Adam wrote: Does anyone know what is the current status of the presence refactor - is there any date on when that is going to hit trunk? I'd really like to see 0.7 get tagged soon, so we can begin the big object model refactor. Thanks! Adam ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.733 / Virus Database: 271.1.1/2683 - Release Date: 02/17/10 22:30:00 ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Status of presence refactor?
It's not fully there, I still haven't finished friends. RL, the need to produce immediate revenue, and the absence of SQLite support, all contributed to that. I'm wrestling with the client on that, because OpenSim has some badness there. Specifically, if you are missing an online friend (that even happens in the LL grid!), as soon as you IM them, they IM you, or you enter the sim they're in, they change to online in the LL grid. In OpenSim, they do not. You can be standing next to a person while your FL claims they're offline, and receive IM that come in as offline IM (with time stamp) while they are actively talking to you online. Right now, I don't see a way to let the client update that without annoying AgentAlerts (bottom eight hand box XXX is online) for EVERY friend on sim entry. So, I'll probably have to attach at least a simple list of online friends to the agant data for interregion, and I HATE that thought! That stuff really SHOULD be stateless! Well, that is the status there. I would not like to see the refactor start in the branch, because that would postpone a merge indefinitely. However, the refactor caould be started in a NEW branch that is based off the current presence-refactor. The friends and SQLite functionality could be merged back to that new branch when they are completed. Git allows this easily. Melanie d...@metaverseink.com wrote: I could, but I'm hesitant to make diva distro releases from branches that aren't the master branch. Plus, so far the differences between the two branches are purely internal; there is no functional difference, or new bug fixes, or anything like that. The new architecture will allow for lots of exciting things to happen, but, again, I'm hesitant in making them happen in the branch. I'd rather merge this to master. Robert Martin wrote: On Thu, Feb 18, 2010 at 10:15 AM, d...@metaverseink.com wrote: Sigh. It's ready. It's been fully operational for several weeks, modulo buglets. It hasn't been merged because the SQLite connector hasn't been redone and at least Melanie doesn't want to merge without it. could you release a copy of Diva with the updated code (since Diva of course does not use SQlite)? ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Status of presence refactor?
Honestly Adam I think if were ever going to be able to get to 0.7 we are going to have to upgrade the memory in the OpenSimulator.org hardware, GIT is so slow right now that it could take forever to do testing if we needed to do alot of patching/fixing. Until thats done I would not expect anything to move very fast on this project. On Thu, Feb 18, 2010 at 4:52 AM, Frisby, Adam a...@deepthink.com.au wrote: Does anyone know what is the current status of the presence refactor – is there any date on when that is going to hit trunk? I’d really like to see 0.7 get tagged soon, so we can begin the big object model refactor. Thanks! Adam ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- Michael Emory Cerquoni - Nebadon Izumi @ http://osgrid.org ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
