It is currently Tue Dec 10, 2019 11:12 am

All times are UTC




Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 163 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6 ... 11  Next
Author Message
 Post subject:
PostPosted: Wed Apr 14, 2010 4:13 pm 
Offline

Joined: Thu May 11, 2006 5:22 pm
Posts: 1814
Location: California
Eat_My_Shortz wrote:
Nalates wrote:
Seems we should be making this as painless as possible in the initial stages and work up to approval and inclusions as things are refined. […]

I disagree with this. It seems to reflect the old view of revision control […]

In other words, I agree with the above quote (work at home and test it out, push it up to a fan test station, then get approved for the current trunk, and finally get Cyan approval), except that I am saying it should be in revision control at all times, and those four "phases" are merely merges into more and more "official" branches.

I think I know what you mean by "top heavy" -- too much process. I used to think that way, but once you've used DVCSes, you realise that they relieve processes, rather than adding to them. […]

I think I see your point. Part of what I’m going for is avoiding most of start-an-idea-but-never-finish processing the main trunk manager has to deal with. If we give everyone access and let everyone start their revision, I imagine it getting cluttered. At some point someone has to control what can be committed to the main trunk. If the system can handle this chaos without overloading the managers, my point is moot.

Eat_My_Shortz wrote:
[…] Put it on a generic open source hosting site (Launchpad, Google Code, GitHub, etc), the third option seems desirable. […]

I think many in the community like this idea. It seems to presuppose there will only be one system. It also seems to ignore dealing with who will manage it, which brings us back to the same problem. I think it is clear Cyan will maintain their own code base and they expect fans to do the same. So, we are already at 2 revision systems. Fans are never unanimous so we will probably have more than 2.

Christian Walther wrote:
Why do people keep thinking of the guilds as some sort of humongous entities that have any kind of power or authority of their own? The guilds are nothing more than groups of individuals that congregate in one place because they like to do and talk about the same things.

In some former life they must have done something really bad… Actually people make the assumption because of their experience in other games. Frustrating.

Christian Walther wrote:
A problem that would be neatly solved by using mailing lists/newsgroups instead of web forums.

True. The RSS feed allowed considerable material be recovered when a db accident happened.

BAD wrote:
[…] can assure everyone here that the GOW does not have any stigma or membership criteria to meet.

The word stigma seems to be misused in that sentence…

BAD wrote:
The GOW has always been a loose affiliation of like minded creators and it intends to be that way for the entirety of it's existence. Any differing description of the group should be disregarded.

True. That is also true of several other guilds.

BAD wrote:
I do not believe that any current fan group should run anything for Cyan. I think that Cyan should hire* fans […]

It seems odd to me that Cyan tells us they don’t want to do the management, can’t affort the time to do the management, asks us how we might handle it, and people continue to try and put things back on Cyan… and we say Cyan doesn’t listen to us…

Cruzcoda’s example of WoW is probably how things will develop in our community. Shortz point about a smaller Cyan management participation means our will likely look different and be structured differently.

Eat_My_Shortz wrote:
However, that's still a barrier to entry. You hit the nail on the head when you said "The only way to have people grant you a say in their matters is to build a reputation by contributing".

I like to include people. However, in an open source movement a ‘contribution’ requirement is a good thing. In open source why should anyone that is not contributing code have a say over someone that is? Feedback, suggestions, opinions, are good. But, a say about what another can do or the direction to go… no.

My ‘inclusion’ thing is handled when we allow anyone to contribute and do their thing. The only time rep starts to kick in is when one is trying to influence others to adopt a change. I don’t see ‘say’ as having much influence when one is supplying code. If it works, is handy, enhances game play or meets some need, and fans like it… someone’s say about it doesn’t mean much. A shard operator is likely to decide to include or not based on merit of the code.

I don’t see someone’s rep or ‘say’ in the community means much. Example: RAWA says play nice… right… that really put an end to bickering… influence yes, control no. Provide code and people can do things. Don’t provide code, people can’t do those things. That is control.

Suggestion
As said by others previously, before we can tell Cyan how we will control the submission process to reduce their workload and adoption process, they tell us what we will have to test with and what the licenses will be for that use. I don’t see that anyone other than Cyan can do those tasks.

Once we know how we will test and what our licensing limits are we can know who wants to play and they can say how they are willing to work with the scenario. Until then we are trying to devise a system that those who will actually do the work will or won’t adopt. We can’t really speak for others in the community. Until someone or groups steps up and says ‘I’m willing to do this and provide such and such with these requirements for those participating…" we are only speculating.

_________________
Nalates - GoC - 418 - MOULa I: Nal KI#00 083 543, MOULa II: KI#00 583 875Nalates 111451 - Second Life: Nalates Urriah
Guild of Cartographers Image


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Apr 14, 2010 4:46 pm 
Offline
Obduction Backer

Joined: Tue May 09, 2006 8:06 pm
Posts: 703
Location: Virginia, US
If Cyan releases the file/game server binaries, one or more members of the fan community can set up a test server. However, these fan-run servers will need the ability to redirect the client from Cyan's servers in order to try out changes to existing URU files (e.g. KI Python files, new avatar emotes) that reside on the fan-run servers.

Communities can be built around each fan-run server that would test the submitted changes and provide feedback. It would be up to Cyan to decide which communities provide the best feedback in order to trust their judgement and roll those changes (or not) into the files on Cyan's master server.

_________________
KI #: 1299


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Apr 14, 2010 4:47 pm 
Offline

Joined: Fri Feb 19, 2010 5:04 pm
Posts: 115
Location: England
MercAngel wrote:
first off no one other then Cyan should have a say in what is or is not good.


Except, Cyan aren't going to have the time to read every patch and every suggestion. In all probability, there will be a handful of people who have the ear of someone within Cyan; if you want to get your patch accepted, you'll need to persuade someone who is in a position to persuade someone at Cyan. That way, Cyan's developers don't have to waste their time reading patches containing obvious bugs or which implement features which have been deliberately rejected.

MercAngel wrote:
as far at the Guilds go they should not have a say in anything at all they are fan run. and as it has been tried before any time you have a fan run group try and say what is right and what is not right there will be a war. as many of the old Until UrU shard admins know too well.

Whether or not the players like it, Cyan's staff don't have the time to deal with everyone without some kind of intermediation. Specific people who have a reputation for not being idiots, for having followed previous discussions, for being able to take "no" for an answer, etc, will have a better shot at getting listened to than someone who is unknown.

MercAngel wrote:
i think Cyan should setup a forum or something with a Rating system where devs can post links to there changes and let all the fans vote on what is good and not good.

That assumes that all opinions are equal. They aren't. When it comes to actual code, it either has bugs or it doesn't, it either has security holes or it doesn't, etc. When it comes to proposals, some things are easier than others; some things just require changes on the client, others will require changes to the server as well.

Most users aren't going to want to apply patches and re-compile the source code. And they're probably not going to download executables from an unknown source either.

In terms of making a change, the easiest case is if only the client needs to be changed, you are writing the code yourself, and the change is mainly for your own personal use. In that case, you don't need support or agreement from anyone else; just modify your client and use it.

If you want your change to become widely used, you need to either persuade users to use a client which you supply, or persuade someone who distributes modified clients which are widely used.

If your change also requires changes on the server, you have to write that code as well, and persuade server operators to make use of it.

And in all cases, if you're not writing the code yourself, you need to find someone to write it, in addition to any other requirements.

So: people who can write their own code have more control than those who have to find someone else to do it for them, people who operate servers have more control than those who have to find a servers operator willing to run server-side code, people who have established a reputation and can persuade users and server operators to run their code have more control than those who need to either establish a reputation or argue their case without having done so.

IOW, software development tends not to be particularly democratic. There are all kinds of (entirely legitimate) reasons why some people have more influence than others.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Apr 14, 2010 5:18 pm 
Offline

Joined: Sun May 21, 2006 11:51 am
Posts: 510
Great posts EMS!

There may be a way to bring everything together, from the many smaller repos into a final "community" build (again this is half baked so input it welcome)

http://buildbot.net/trac/wiki/ScreenShots

BuildBot, allows automatic builds of code from distributed repos, and various branches. It is a great system whereby after a commit or other action, the BuildBots automatically builds a new version of the code and reports breakage/success.

One of the features is the ability to show which commit broke the build, which can prevent a developer from pushing a half baked patch up stream, BuildBot produces consequence to not peer reviewing work successfully by naming and shaming.

Other developers can then help fix and assist where needed, or the patch can be simply de-merged.

Naming an shaming also has an added effect of giving people a level playing field, everyone can submit patches. but after a while if you continue to submit crappy patches upstream, limits can be placed on you to manage the issues of possible abuse and additionally your reputation as a developer is tarnished.

If people are willing to provide hardware, buildbots can be installed and running on community servers for testing, this giving people the opportunity to see, use and test the new ideas going into Uru before submitting to cyan.

This gives us base line development and test platform, and allows players to contribute as well.

I think this solution ties up player, shard owner and developer up quite nicely for the community to be able to deal with.

As discussed Age building should be separate to this system, and seek their own system for submissions, but they could maybe bolted on to the Buildbot system if needed.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Apr 14, 2010 5:56 pm 
Offline
Creative Kingdoms

Joined: Tue May 09, 2006 8:06 pm
Posts: 6231
Location: Everywhere, all at once
DarK wrote:
...BuildBot, allows automatic builds of code from distributed repos...

Continuous Integration. OpenURU.org can do this now. rarified got this going for us sometime last year. It detects the change and does the build. It's been waiting for Uru...

See our Building & Testing project:
http://forums.openuru.org/viewforum.php?f=20

_________________
OpenUru.org: An Uru Project Resource Site : Twitter : Make a commitment.
Image


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Apr 14, 2010 7:31 pm 
Offline

Joined: Sun May 21, 2006 11:51 am
Posts: 510
JWPlatt wrote:
DarK wrote:
...BuildBot, allows automatic builds of code from distributed repos...

Continuous Integration. OpenURU.org can do this now. rarified got this going for us sometime last year. It detects the change and does the build. It's been waiting for Uru...

See our Building & Testing project:
http://forums.openuru.org/viewforum.php?f=20


I see your using Hudson, rarified points out some things in that thread which I see as technical flaws in that particular Integration System.

One of which is the need to actually connect to an exported file system, which is a lot of overhead for a WAN system.

BuildBot just depends on the ability to connect to the DVCS and detect new commits, the local machine then pulls down from the DVCS and builds, then the Bot Reports back to the Master Build Bot the status and errors.

Is there any public facing information from Hudson or is it all password protected?

Ideally we are looking for something that is as open to everyone as possible, and as soon as you start putting names/control into the picture, people around here usually get very uppity.

Ideally there would be nothing to stop you from running an Open Uru branch with its own repo that other people work from, and push upstream to your Build System, which in turn pushes to another final submission system

However we need to be able to allow Joe Blogs to come in and commit to the overall source without the need to jump through "social" hoops.

Crossing a few ideas here:

Cyan publish gold tree branch

Community marks out bugs and features to a cyan controlled tracker, marking priority where appropriate.

Developers work from gold tree, build and apply fixes and develop features featured in tracker.

Dev Pushes build to a testing branch at cyan for Buildbot approval

If build is successful, for patches to be marked for submission to cyan, approval is needed by another peer for High priority jobs (Show stoppers, bug fixes), or rated/voted by players for feature inclusion or lower priority jobs (adding new features etc)

Cyan applies approved patches they want to include to the gold branch.

Cycle continues

I know I have said that cyan needs to be taking a back seat, but I can’t see who in the community could control the Bug Tracker or the final testing repo without someone making a fuss about it.

However it’s the best solution I can come up with which is low management from cyan, but allows everyone to participate.

Abuse is easily hunted out as everything is available for public consumption.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Apr 14, 2010 7:33 pm 
Offline
Obduction Backer

Joined: Mon May 15, 2006 2:02 pm
Posts: 818
Location: Switzerland
Eat_My_Shortz wrote:
My attitude is that these are sub-communities. I'm sure if I went over to GoW I could get an account and start "being a member" right away. i.e., there's no "membership test" to get in. However, that's still a barrier to entry. You hit the nail on the head when you said "The only way to have people grant you a say in their matters is to build a reputation by contributing". See, I have somewhat of a reputation here, on the official Myst forums, because I've been around awhile. I do not have a reputation in the GoW, or any other guild, because I don't participate in those sub-communities. So my point is, the guilds shouldn't get to say what goes in, or get to manage the codebase, because then the decisions will be biased in favour of those sub-communities. It should instead be in some "neutral" space such as the Myst official forums, or the Cyan site, or Launchpad.

OK – perhaps I underestimate the fragmentation of the community. Could be that there exists someone who is a well-known contributor in some part of the community, in a field that I’m interested in, and yet I don’t know about it and would treat them as a newcomer because they don’t post on the forums I read. What to do against that (assuming it is even a problem)? Read even more forums? It takes way too much time already…

One potential danger I see with such “neutral grounds” that are chosen instead of established venues is that they just end up creating another subcommunity. I think this has happened to some degree to OpenURU.org, which was founded explicitly as such a “neutral ground”. But I guess places like the mentioned open source hosters that are run by someone unaffiliated with our community are less susceptible to that. If they provide all we need and we can have the discussion in the same place as the code is hosted, all the better.


Nalates wrote:
If we give everyone access and let everyone start their revision, I imagine it getting cluttered. At some point someone has to control what can be committed to the main trunk. If the system can handle this chaos without overloading the managers, my point is moot.

Assuming that by “main trunk” you mean Cyan’s repository, then that someone is Cyan. The key thing to understand is that in the decentralized version control workflow we are likely to adopt here, contributors do not push (commit) to Cyan’s repository, but Cyan pulls from them – at their discretion and at their own pace. The main question at this point is, how do they decide what to pull with a minimum amount of QA work on their part.

Nalates wrote:
Eat_My_Shortz wrote:
[…] Put it on a generic open source hosting site (Launchpad, Google Code, GitHub, etc), the third option seems desirable. […]

I think many in the community like this idea. It seems to presuppose there will only be one system. It also seems to ignore dealing with who will manage it, which brings us back to the same problem. I think it is clear Cyan will maintain their own code base and they expect fans to do the same. So, we are already at 2 revision systems. Fans are never unanimous so we will probably have more than 2.

I think you are mixing up two things here.

First, Cyan’s code base and the fans’ code base, i.e. two or more repositories. The whole point of decentralized version control is that there are not two, but dozens or hundreds of repositories – every participant has one, or several, of their own. Decentralized version control systems are designed to manage this complexity with ease.

Second, the choice of which hosting service and accordingly which version control system to use – Launchpad and therefore Bazaar, or GitHub and therefore Git, or Google Code and therefore Mercurial, etc. It’s true that we’ll never be able to agree on that, but I think the three are pretty interoperable (may be wrong – I do know that all three interoperate well with Subversion), so I don’t see a big problem here. Some will find they can work with any tool and use the same one as everyone else uses for simplicity, even if it’s not their favorite, others will use their favorite tool and live with some interoperability inconvenience in return.


Keikoku wrote:
Cyan aren't going to have the time to read every patch and every suggestion. In all probability, there will be a handful of people who have the ear of someone within Cyan; if you want to get your patch accepted, you'll need to persuade someone who is in a position to persuade someone at Cyan. That way, Cyan's developers don't have to waste their time reading patches containing obvious bugs or which implement features which have been deliberately rejected.

That is the model used to develop the Linux kernel, and I think it could work well here.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Apr 14, 2010 8:07 pm 
Offline

Joined: Tue May 09, 2006 2:10 am
Posts: 372
This is already starting to get out of hand. :\

Let me try to make this as clear as possible. The GOW has no hierarchy. A person who joined 5 years ago and a person who creates an age, writes some server code, draws a picture, writes an age story, or makes some other mod today are on equal footing. Even if someone doesn't join the forum, they can consider themselves a member of the GOW if they want to.

The forum and web space of the GOW is only for supporting age creation and creating tools for modding Uru. Most of the official guilds are like this these days because it has turned out to be the most effective way to gain members and make OOC and IC relations easier.

This is the last I will say on it. If you want to assume the guilds are a bunch of evil dictators knock yourself out.

Back on topic:

I realize I am not being completely clear with my thoughts.

I am not suggesting Cyan do the work to approve mods and fixes for Uru. I am suggesting that Cyan use community members (or outsiders) directly to work on setting up, maintaining, and moderating the repository for submissions within Cyan's own web space.

Whatever kind of trunk is decided to be used, I believe someone should be picked to do this who has a lot of experience with running a repository. So probably the best idea for us all right now is to leave this thread alone and let those with experience advise Cyan on what kind of system to set up.

Right now I see people already trying to add a bunch of unnecessary issues to this that will only serve to distract the actual development of any ideas to make this work.

So this is it for me. I'll be leaving this thread alone as I said how I feel as clearly as possible.

:wink:

_________________
BAD is as good as BAD can be.

Visit our new site!

SOUP!


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Apr 14, 2010 8:47 pm 
Offline

Joined: Sun May 21, 2006 11:51 am
Posts: 510
BAD wrote:
This is already starting to get out of hand. :\

Let me try to make this as clear as possible. The GOW has no hierarchy. A person who joined 5 years ago and a person who creates an age, writes some server code, draws a picture, writes an age story, or makes some other mod today are on equal footing. Even if someone doesn't join the forum, they can consider themselves a member of the GOW if they want to.

The forum and web space of the GOW is only for supporting age creation and creating tools for modding Uru. Most of the official guilds are like this these days because it has turned out to be the most effective way to gain members and make OOC and IC relations easier.

This is the last I will say on it. If you want to assume the guilds are a bunch of evil dictators knock yourself out.

Back on topic:

I realize I am not being completely clear with my thoughts.

I am not suggesting Cyan do the work to approve mods and fixes for Uru. I am suggesting that Cyan use community members (or outsiders) directly to work on setting up, maintaining, and moderating the repository for submissions within Cyan's own web space.

Whatever kind of trunk is decided to be used, I believe someone should be picked to do this who has a lot of experience with running a repository. So probably the best idea for us all right now is to leave this thread alone and let those with experience advise Cyan on what kind of system to set up.

Right now I see people already trying to add a bunch of unnecessary issues to this that will only serve to distract the actual development of any ideas to make this work.

So this is it for me. I'll be leaving this thread alone as I said how I feel as clearly as possible.

:wink:


BAD ...

I don't think that this is getting out of hand, the discussion so far has been quite slow and nothing is set in concrete until some form of consensus is reached and approval from cyan occurs.

I and others can throw ideas around until we are blue in the face for now.

Forgive me for my following bluntness and cynical opinion, But the guilds once where ivory towers, and the past charters and various rules that where built up prove they where once and area where people fought for power.

They have since become redundant as they possess nothing of interest to control, my thoughts are thought that if we move something of interest back into the guilds, they will be ripe for pickings again.

The last thing I want to see is the source closed off to me or others because they are not in the power clique that might end up controlling the GoW or GoMa etc.

I'm not against the idea of the guilds been the calling point for code submissions, as long as it comes with guarantees of continued openness.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Apr 14, 2010 9:26 pm 
Offline
Obduction Backer

Joined: Tue May 09, 2006 7:52 pm
Posts: 1671
Location: Seattle, WA
The technical aspects of this are beyond me, but I think we might be reinventing the wheel if we get too complicated.

We've already got Open Uru, GoM and GoW in place, and if we start tippietoeing and assuming power struggles and cliques, then they WILL happen. (Insert rant about community allergy to project management here)

I see something like a (lopsided) pyramid. The code is out there, anyone can grab it and fuss with it. They can go to the GoW or OpenUru for ideas and support, and then they can go to the GoM for hard core QA and bug testing.

I would REALLY suggest that Cyan put together a QA panel of their own, made up of people they know will keep any buggy bleh from Cyan's servers, as the last filter for approval.
Beyond that, we've already got some very good resources. Sure they might need to tighten up their structure now that there is actual work to do, but that's what makes things run smoothly.

_________________
Storyteller, Creatrix, and maker of general mayhem
Unwritten RPG: http://www.unwrittenrpg.com/
KI#00001498
Officially bonked R.E.B.E.L.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Apr 14, 2010 9:31 pm 
Offline

Joined: Thu Aug 03, 2006 10:55 pm
Posts: 625
One thing to make clear here... I don't think anyone is suggesting the guilds be given control over the source, or be given any sort of official power structure here. Such things were tried in the past and it was an unmitigated disaster.

It's really a matter of practicality to use the existing forums, IRC channels, and groups. If Cyan establishes a new group, guess who's gonna be there? All the same folks who are already in the GoW. They're also quickly going to become known as the ones who know what they're talking about w/ regards to the Plasma engine. How is that different from just using the GoW forum?

The point is that we already have gathering places for discussion and community vetting. Why reinvent the wheel?


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Apr 14, 2010 9:43 pm 
Offline

Joined: Sun May 21, 2006 11:51 am
Posts: 510
PaladinOfKaos wrote:
The point is that we already have gathering places for discussion and community vetting. Why reinvent the wheel?


On the one hand I'm been told we already have a solution ...

BAD wrote:
The GOW has always been a loose affiliation of like minded creators and it intends to be that way for the entirety of it's existence. Any differing description of the group should be disregarded.


On the other I'm been told not ...

Which one to believe?


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Apr 14, 2010 9:48 pm 
Offline

Joined: Thu Aug 03, 2006 10:55 pm
Posts: 625
DarK wrote:
PaladinOfKaos wrote:
The point is that we already have gathering places for discussion and community vetting. Why reinvent the wheel?


On the one hand I'm been told we already have a solution ...

BAD wrote:
The GOW has always been a loose affiliation of like minded creators and it intends to be that way for the entirety of it's existence. Any differing description of the group should be disregarded.


On the other I'm been told not ...

Which one to believe?


Those two aren't mutually exclusive. Cyan can say "We suggest people go to the GoW for that", and it's still an open community, and still loosely affiliated. The GoW manages to find bugs in each others' ages and code without having a formal structure, it can continue to do so with more contributors (who are not only creating new bugs, but also helping find bugs in other people's ages and code).


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Apr 14, 2010 9:48 pm 
Offline
Obduction Backer

Joined: Wed Feb 10, 2010 12:28 am
Posts: 1247
Having spent a grand total of about 10 minutes looking at the code, here's two things I'd like changed. Someone can incorporate them perhaps wherever ya'll are putting the code. I've got other ideas, but now this is just two tiny ones:

In xKI.py:

Find def IFilterAgeName(self,ageName):

Add if ageName.find("(null)") != -1:
ageName = ageName.replace("(null)", "")

(to fix the (null) issue. It's not the CORRECT fix...but it's a quick and dirty one.

Find def ICanAgeInviteVistors(self,ageInfo,link):

Remove if ageInfo.getAgeFilename() == "Personal":
return 0

(This would allow us [i think] send invites to our Reltos...not a bug fix...just something I'd quite like to be able to do)

To what that what you will!

/me returns to other projects.

_________________
Image
Click here to change my signature!


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Apr 14, 2010 9:59 pm 
Offline

Joined: Sun May 21, 2006 11:51 am
Posts: 510
PaladinOfKaos wrote:
Those two aren't mutually exclusive. Cyan can say "We suggest people go to the GoW for that", and it's still an open community, and still loosely affiliated. The GoW manages to find bugs in each others' ages and code without having a formal structure, it can continue to do so with more contributors (who are not only creating new bugs, but also helping find bugs in other people's ages and code).


Ok but on point again, how does the final patch get to cyan?

Are 50 people going to randomly submit patches to cyan who have to spend time verifying each one, or can something be put in place that is seen to be open and is agreeable to everyone?

Take into account Job blogs has to be able to submit patches on the same grounds as larger developer teams like the GoW etc


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 163 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6 ... 11  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to: