Submitting changes to Cyan

Montgomery · **Posted:** Fri Apr 16, 2010 7:12 pm

DarK wrote:

Basically the “I’m Spartacus” principle!

"I'm Brian and so's my wife!"

mszv · **Joined:** Wed May 10, 2006 5:28 am **Posts:** 2266

I do this for my own amusement, but some of you may find it useful

What we appear to agree on, mostly -- never an absolute, but there seems to be more or less agreement on the following 5 points.

1, Development tools: DVCS (distributed revision control) - exact flavor to be decided
2. Development tools: Something to pull a release together, like BuildBot
3. Some flavor of open source licenses. See the KI thread for a very interesting technical and business (not a bad word) discussion.
4. Public Bug Database -- unsure if it will also contain RFEs - request for enhancement.
5. There will be a set of changes (enhancements, fixes) that get back to the Cyan version of the client and server. I don't know if you want to call this the "official" Uru source code, or, better, the Cyan version.

What there is some agreement on - operative word is "some". Let me know if you think there is enough agreement on any of the following and I'll move it into the "General agreement" section.

1. Everything developers change can't get back into one thread, one release, for both technical reasons and design considerations. Lots of technical discussions on this (I'm convinced), some design discussions. My conclusion: for both reasons, not everything proposed and coded by developers can make it into a single new version of the client and the server code.
2. Need a way to review changes and recommend what goes into the Cyan release -- the how and what of this is somewhat contentious.
3. 2 flavors of changes: patches, things that go back in the Cyan release, forks -- things that don't go back, get into a new version of the client and the server code. The patches go back into the Cyan version of Uru. The forks mean that there is another version of the client and server code. Personally, I don't think that's a bad thing.
4. Desire for at least one version of Uru that seems like Uru, not necessarily canon strict, but it still seems like the Uru world. That's my take on where a lot of people (not all!) are with regards to Uru -- they aren't experts on the lore, but they want it to still seem like Uru. Yes, this is fuzzy, but there you are.

Very interesting and productive discussions.

Whilyam · **Joined:** Tue May 09, 2006 1:04 am **Posts:** 4134

DarK wrote:

Whilyam wrote:

We are literally watching our community grow old and die

I find your comment to be in bad taste sir.

I find no sense in yours.

Quote:

Additionally we are talking about how to get patches to cyan and how cyan should distribute code.

You seem to be talking about something that would not actually happen. You would not be stopped from working on what ever you see fit.

Except that, if it didn't survive the Gerousia, no one would see it. It freezes creativity and the urge to do voluntary work when that work can be discarded like this.

Quote:

So far the consensus seems to be that cyan selects people from the community, who it feels will best carry out cyans wishes

Do you have anything to add to this particular discussion?

That is not the consensus, that is your desire. And I am contributing to the discussion.

DarK · **Joined:** Sun May 21, 2006 11:51 am **Posts:** 510

Guess it’s time to hit your panic button.

Whilyam wrote:

I find no sense in yours.

It was highly insensitive to people who have been well known in this community and have passed on, I am sure in actual face to face conversation you would not have said that to someone you have only a passing knowledge of.

Whilyam wrote:

Except that, if it didn't survive the Gerousia, no one would see it. It freezes creativity and the urge to do voluntary work when that work can be discarded like this.

Ok...

FACT: Cyan have said they need help in vetting patches to their source

Chogon wrote:

Obviously, Cyan doesn't have the staff to look at *tons* of changes (such as for the KI, etc.) and apply them to MOULagain. So, fan help is needed!

FACT: Cyan want player’s vetting patches to their source

Chogon wrote:

I think that some kind of peer review of changes (peers as in other fans) might work and then the best stuff is what is submitted for inclusion into the next build of MOULa.

FACT: Cyan wants us to throw out patches

Cyan does not want *tons* of patches from many players
Cyan wants players to vet *tons* of patches

FACT: Cyan need to tell us what to throw out

You’ve said:

Anything that does not crash the game
Anything that is not illegal

Generally In most projects you could count the number of patches on one hand that would meet that criteria.

Additionally under your rules: I could create a loop that calculates Pi for 2 hours before you link into relto. I can claim it’s by design.

So: Cyan needs to specify what we need to keep and what we need to throw out for the official cyan source.

We already have some guidelines on what that might be with the age builder’s guidelines, but we can ask cyan to confirm any other rules they think they need.

Systems Analysis – Specification & Design: Please look this up.

Whilyam wrote:

It freezes creativity and the urge to do voluntary work when that work can be discarded like this.

.

FALSE: Nothing is stopping you from forking from cyan’s code base and making your own version of plasma (plasmuru if you like)

Your work is only a waste if people do not use it. If you have a fear of that, there may not be a use for the change you are planning in the first place.

Systems Analysis – Feasibility: Please look it up.

FACT: if you want to submit code back into the cyan code base you have to submit it through a yet to be decided process.

Hence this discussion

See chogons original post

Whilyam wrote:

That is not the consensus, that is your desire

Well it’s actually consensus, because the few people who are responding to the original post seem to have the same or similar ideas to mine.

Whilyam wrote:

And I am contributing to the discussion.

Nalates · **Posted:** Fri Apr 16, 2010 10:28 pm

Christian Walther wrote:

Any fears that being taken seriously in the GoW would require one to gain access to an exclusive elite of ancient wizard hackers are unfounded. The atmosphere I see is that everyone is welcome, and respect is given to those who get things done, no matter where they come from.

Several of us would debate the finer points of that statement… I do consider it fact that anyone can join a ‘guild’ forum and participate. I consider it fact that new people will be welcomed. The respect part and getting things done is more subjective and situational.

The biggest problem with guilds is people coming from other games and applying their past experience with other guilds on the Uru related guilds. Most of our guilds are not highly organized or controlled. They are mostly a testament to how well chaotic systems work. Anarchy has its problems but it also has lots of benefits. Especially freedom of independent action…

So…
Has anyone gotten tired of this discussion on gone off and set up the KI code in a system to implement what they think will work?

aloys wrote:

we still have to solve the more pressing core question: How to decide what to submit.

I still think once we have a testing server setup where people can test and experience the various changes, fixes, and additions then and only then will the majority of the community be able to understand the process and make intelligent comments. Until then it is all speculative.

So, for now that question seems to be answered as; someone will, or several different people will, run a code management system. They will decide who can contribute and I expect that to pretty much open. From the flood of ideas and code they will decide what makes it into their main fork. Code please being the main filter on ideas. The main forks will be run on testing servers. Fans will be able to see the affects and decide what they like. The server techs will be able to see performance problems and errors. From all that information those managing the code can then make submissions to Cyan. Cyan reads the forum to some extent. They can pick up on the popular changes, fixes, additions. Or we can run polls on the forum. Cyan can pick and choose.

Everything happening here is about trying to tell those that will run the code management systems what to do and fearing what they may decide to do. They have not told us what they will do. So this is all imagined speculation. Well whatever they do we have no control over them. Cyan is insistent they are not going to manage the open source community. So, if we don’t like what one code manager does we use another or do our own.

Whilyam is EXACTLY right, the community has never unanimously agreed on anything ever… with the exception of liking Uru and we can’t even agree on why we like it… so that doesn’t count. So, there is no chance all the code is going into a single management system. Cyan will manage what they call their main trunk and add to it from others. Then all the others will draw from Cyan's updated base code and go from there. Wash, rinse and repeat.

Does anyone really think the community will do anything else?

DarK · **Joined:** Sun May 21, 2006 11:51 am **Posts:** 510

Nalates wrote:

Does anyone really think the community will do anything else?

What cut its nose off despite its face?

It’s done it so many times already I think there is nothing left to worry about

Whilyam · **Joined:** Tue May 09, 2006 1:04 am **Posts:** 4134

DarK wrote:

Guess it’s time to hit your panic button.

Whilyam wrote:

I find no sense in yours.

It was highly insensitive to people who have been well known in this community and have passed on, I am sure in actual face to face conversation you would not have said that to someone you have only a passing knowledge of.

It's insensitive to mention that people died? Sorry, it's the truth. The game has been around for somewhere around 12 years (I have been around for 6 of them). We need to be open to new ideas. Not just because the community is growing old an dying, but because doing so allows people to enjoy the game in different ways.

Quote:

Whilyam wrote:

Except that, if it didn't survive the Gerousia, no one would see it. It freezes creativity and the urge to do voluntary work when that work can be discarded like this.

Ok...
FACT: Cyan have said they need help in vetting patches to their source
FACT: Cyan want player’s vetting patches to their source
FACT: Cyan wants us to throw out patches
Cyan does not want *tons* of patches from many players
Cyan wants players to vet *tons* of patches

Exactly. No objection there.

Quote:

FACT: Cyan need to tell us what to throw out

Objection here. Cyan needs US to tell THEM what to throw out. What we disagree on is by what criteria we throw things out. I think:

Quote:

Anything that does not crash the game
Anything that is not illegal

is perfect. Two objective criteria. Either something is legal (or violates the ToS) or not, crashes the game or not.

Quote:

Generally In most projects you could count the number of patches on one hand that would meet that criteria.

In most projects you have illegal, crashing patches? Which ones? Every project I see has legal, stable patches.

Quote:

Additionally under your rules: I could create a loop that calculates Pi for 2 hours before you link into relto. I can claim it’s by design.

No, that would violate the ToS. Specifically the part about harming game experience that was recently incorrectly referenced in regards to OHBot.

Quote:

So: Cyan needs to specify what we need to keep and what we need to throw out for the official cyan source.
We already have some guidelines on what that might be with the age builder’s guidelines, but we can ask cyan to confirm any other rules they think they need.

Wrong. This increases Cyan's workload. We need to objectively look at patches and send the list to Cyan for implementation. The patches are implemented and people decide whether to install them or not.

Quote:

Whilyam wrote:

It freezes creativity and the urge to do voluntary work when that work can be discarded like this.

.
FALSE: Nothing is stopping you from forking from cyan’s code base and making your own version of plasma (plasmuru if you like)
Your work is only a waste if people do not use it. If you have a fear of that, there may not be a use for the change you are planning in the first place.

Except people will want to develop something for Cyan's Uru shard (although there will certainly be those who don't care one way or the other). If it doesn't go onto Cyan's shard, it's likely not to be seen by as many people, if at all. Also, no one wants to fork the code just so they can have a Twitter plugin when some dunces declare it "not what Uru stands for" or "not needed."
That is a stupid reptilian criteria of wants and needs, not an open environment of creativity and experimentation.

Quote:

Whilyam wrote:

That is not the consensus, that is your desire

Well it’s actually consensus, because the few people who are responding to the original post seem to have the same or similar ideas to mine.

Dictionary.com describes consensus as the majority of opinion or general agreement of a group. You have the minority opinion of a small segment of the community and are attempting to claim that as the majority.

Quote:

Whilyam wrote:

And I am contributing to the discussion.

See, it's not actually a discussion if you are the only one talking. If it's a bunch of people agreeing on something and saying what a good idea it is, that's called a support group.
But what am I saying, discussion isn't allowed on forums. :lol:

To reiterate: The fans CAN filter the patches. They MUST do this through objective criteria. If not, we repeat the Liaisons. Plain and simple.

Marten · **Posted:** Sat Apr 17, 2010 3:49 am

Whilyam wrote:

To reiterate: The fans CAN filter the patches. They MUST do this through objective criteria. If not, we repeat the Liaisons. Plain and simple.

And that is why I've thrown my support behind Whilyam's recommendation - because it is the only one that won't result in finger pointing, crying, and drama.

It is entirely possible that some people will band together to "endorse" particular patches. Cyan may or may not choose to pay attention to such endorsements. But anyone outside of Cyan who says "yea" or "nay" to patches based upon subjective measurements will be subject to castigation and ridicule by whichever part of the community takes offense - and I have no doubt that someone WILL take offense when this happens.

Cycreim · **Joined:** Wed May 10, 2006 10:37 pm **Posts:** 661

mszv wrote:

What there is some agreement on - operative word is "some". Let me know if you think there is enough agreement on any of the following and I'll move it into the "General agreement" section.

1. Everything developers change can't get back into one thread, one release, for both technical reasons and design considerations. Lots of technical discussions on this (I'm convinced), some design discussions. My conclusion: for both reasons, not everything proposed and coded by developers can make it into a single new version of the client and the server code.
2. Need a way to review changes and recommend what goes into the Cyan release -- the how and what of this is somewhat contentious.
3. 2 flavors of changes: patches, things that go back in the Cyan release, forks -- things that don't go back, get into a new version of the client and the server code. The patches go back into the Cyan version of Uru. The forks mean that there is another version of the client and server code. Personally, I don't think that's a bad thing.
4. Desire for at least one version of Uru that seems like Uru, not necessarily canon strict, but it still seems like the Uru world. That's my take on where a lot of people (not all!) are with regards to Uru -- they aren't experts on the lore, but they want it to still seem like Uru. Yes, this is fuzzy, but there you are.

1. Agreed, and if we try to do that then it'll just be a headache. Makes total sense to me.
2. Perhaps some sort of rollout system of patches/changes could be hosted on a testing server for the Guild of Maintainers to go over? Debate is healthy where practical changes can be made, so having a place to actually see changes implemented so their practical concerns can be discussed would be fine, with (maybe) monthly rollouts to either a Cyan server or other(s) or both once all the kinks are worked out.
3. Agreed!
4. I am a huge fan of staying close to canon, but I also think there's a lot of value in not completely alienating people from the server that serves to sort of "continue" Cyan's Uru vision. Not being too strict, and allowing for some space around the seams, and taking things on a case-by-case basis in a very fluid, organic way will probably allow for the most creativity while still keeping a modicum of control over the chaos. I'm not a huge fan of rules in these sorts of situations, beyond "Don't violate the TOS" and "Don't do anything harmful to players". Having a Guild of Maintainers whose MO is something along the lines of "don't be boring" might be able to act as a forking agent for the wibbly-wobbly bits that are balanced on the edge of canon and whatever's cool but non-canonical.

EowynCarter · **Joined:** Wed Dec 20, 2006 4:19 pm **Posts:** 1161

When live was on it's way I though hey cool, so we have until to have fun, do silly things, and live, more IC and "cannon". Then, much to my dismay, until went down.

There should be no problem in have having two server rather than one.
One with more strict rules trying to stay IC, and one where almost anything goes. (Then, we should be wary of splitting further than that, we don't have enough numbers for that.)

mszv · **Joined:** Wed May 10, 2006 5:28 am **Posts:** 2266

Expanding on what I said before --

From what I read here, you can't turn every code change into a mod that can be installed separately. I don't even know if you can do that with any code change to the Cyan client and server code! Many (all?) code changes have to be bundled into a release. Also some code changes will break other code changes and then the developers have to to decide what to do. This doesn't mean that personal choice goes away. What this means is that some code changes won't make it into a release on the Cyan system. When that happens, some developers may elect to make a fork in the code road (I know, bad analogy), and develop a separate version of Uru, one they will run in a different server/shard. One can want whatever one wants, but I don't see any way around it. What this means to me is that, if enough people care about a change that didn't make it, and you have group of fans that are willing, we get a fork in the road, separate client and sever versions, and different shards running different versions of the code. I think that's ok.

Let's talk about having several different versions of the client on the same server. Most of the online games I'm familiar with don't let you do that. If you don't have the right version of the client, you either get an automatic upgrade or you have to do it yourself. This is done for practical reasons, so everything works as anticipated, so nothing breaks. And we are just talking about different versions of the client. You can't run different versions of the server(s) as far as I know!

So -- I would say that, due to technical reasons, every code change won't get into a release. It doesn't mean that players won't have choices, but it seems to me that they won't have choices on everything. If people feel strongly about something not getting into a release, that's where you get the fork and fans running their own servers, their own versions of Uru.

---------------------
Those are technical considerations. Let's consider design considerations.

-- I'd like to be able to fly in Uru. I can't remember how it was done (think it was done!) on some of the UU shards -- don't remember if it was actual flying or the physics changing so it was really high jumping! Anyway, this is a design change that affects everyone in the public ages. What I want will affect every other players experience. Even if I don't fly I'd see other people flying around.

Personally I like flying in a game, very much. But -- you could also say it doesn't seem in tune with Uru. In this scenario I can see separate servers/shards. One one server (possibly the Cyan one) -- no flying. On other fan run servers, you can fly. I'm not talking about the technical implementation (don't know how it's done) but on design considerations. If what you do changes everyone's experience in the game, in a fundamental way, then you have to decide if you want to implement it. That's where the "more than one server/shard" thing starts to look good.

-- Camera views. Uru likes to keep control of the camera. I can't swing it around to look at what I want, including looking at how I appear in the game -- it's really hard to get a good screenshot of my avatar, in game. I'd like that changed. I'd like to have more control of the camera view, like I've experienced in other games. This is a change that affects individual players; if I change my camera view it doesn't affect how other people view the game. So, from a design consideration, maybe it's something we could implement in Uru, and make it optional. You can change your camera view, or not. But --- that's from my player perspective, not from a technical perspective. I don't know if that's possible, technically - if you can make it so some players can change their camera view, but all players don't have to. If you can, maybe that's a design change that we could implement on the Cyan run version of Uru. If we can't and if some players want to keep the old camera views, then that's another fork in the road, and we might have a server/shard running where players can switch their camera views around.

----------------
Who gets to decide?

This depends on the roles, on what we are asked to do, also Cyan telling us how much they can do. From a technical perspective, does Cyan want a working client and server submitted to them, of a bunch of changes that may or may not work, may be incompatible with each other. Does Cyan want do to their own integration testing, their own regression testing? Do they want to run test versions of the game, have players submit bug reports, have the fan developers fix the bugs and push their change back to Cyan for integration and further testing?

If Cyan wants more work done on the fan side, technically, then some fans, or groups of fans, are going to have to have decision making roles. I can't see anyway around this.

From a design perspective -- that's interesting. For a change that affects everyone, someone has to decide if it can go on the Cyan run version of Uru. Do you want every design change going to Cyan (fly mode, 7 different versions of the KI, for example). What if, for example, Cyan says -- I only want to review two different versions of the KI, not 17 different versions. Who gets to pick those versions?

Ian Atrus · **Posted:** Sat Apr 17, 2010 5:40 pm

I'm not really getting the canon problem when applied to codebase changes. Canon is something related to game/story content, and will fall in the FCAL area (or future equivalent); code does stuff, and powers the content, but is not it.

To use the Twitter example: you made generic code that allows OpenPlasma (or PlasmUru, if I got Tweek's terminology right) to send content to Twitter. Sweet. Sure, you can send your patch for review, and it might eventually be included in the trunk - or it might be rejected, but you want it so much that you start your own branch (or even a fork) where OpenPlasma can tweet. OK.

Now, you want the KI to use that code to send tweets? That's out of your hands. It's game content and, specifically, it's Cyan's content and it's their job to approve or deny modifications.They can do it actively, by checking every request, or passively, by making guidelines and waiting for others to report violations, but if they don't want the in-game KI to send messages to Twitter, it never will.

Of course you can decide to work outside of those limitations, make your own fork, replace all the assets, make your own server, and *there* put a KI-lookalike that sends messages to Twitter. But, canon wise, that's just the same as making up your fan story where you hacked the KI to do so, which is basically where we already are now, aka a non problem.

OHB · **Joined:** Wed Feb 10, 2010 12:28 am **Posts:** 1247

Ian Atrus wrote:

To use the Twitter example: you made generic code that allows OpenPlasma (or PlasmUru, if I got Tweek's terminology right) to send content to Twitter. Sweet. Sure, you can send your patch for review, and it might eventually be included in the trunk - or it might be rejected, but you want it so much that you start your own branch (or even a fork) where OpenPlasma can tweet. OK.

Since it was mentioned...Twitter in URU is already a reality...it's being testing now...and it'll soon be released. I get all my Tweets in-cavern already

Stay tuned...

Bellerophon · **Joined:** Wed Apr 14, 2010 2:46 am **Posts:** 34

Oh lordy.

Okay, high priority after handover, getting optional per-player UI mods into the game, stat.

It'll cut down on a lot of arguing.

Nalates · **Posted:** Sat Apr 17, 2010 6:48 pm

mszv wrote:

From a design perspective -- that's interesting. For a change that affects everyone, someone has to decide if it can go on the Cyan run version of Uru. Do you want every design change going to Cyan (fly mode, 7 different versions of the KI, for example). What if, for example, Cyan says -- I only want to review two different versions of the KI, not 17 different versions. Who gets to pick those versions?

I think we will find Cyan will be the only ones to ever decide what goes in their main trunk and game server.

Every change being submitted to Cyan may happen… but that will just bog Cyan down and delay updates to the game. Also, it is not like “what if Cyan says”, they said they want the fans to pair down the stuff they have to go through.

So, who does get to decide what gets submitted to Cyan? I think it is obvious. First, those who write new code and ages are the first level deciders/enablers. Until they write something no one has a choice.

Once enough material is created, like ages presently, that it takes time to go through it, some selection process gets started. Since we are currently discussing code the one deciding what gets submitted is the one running a code management system. Consider. People will want to read the code before running it. So, it has to be published somewhere and will most definitely be a code management system. Whoever is running that gets to decide what comes into the system and what gets adopted to that systems trunk.

Before code can be a candidate for Cyan’s use, it will need to be tested. That means someone or group will have to run a testing server. I don’t see that Cyan has given us information for how that may work. But whoever runs a testing server then gets to decide whose code or age is run. Until it is tested I don’t see how Cyan can adopt it without taking on a testing and feedback chore.

Once it is in a test server the operator also gets to decide who can log in. Those allowed to login will have experience with the change and can voice knowledgeable opinions on how well, or not, it works and what they think of it. The test operator gets to gather performance data and error messages. That information would need to go back to a bug tracking system, which may or may not be run by the same people running the code management.

When code or an age makes it through that process a finalized, working version of the code will be in the system. Someone can then recommend it to Cyan. With it running in a test server somewhere it will be easy for Cyan to see it in action and make a decision whether they want to add it to their main trunk.

So, it would seem the one running the code management system has the most control. We, as in the community, really have no say over who runs the management system, nor even if it is one system or multiple systems. Nor do I see we have any control over them.

It’s not like we get to pick who these people will be. I run a 3 region OpenSim server because I want to and can. Not because I was picked to. I think it is going to be the same with code management and testing servers. Individuals will decide if they run one or join a group that does. If one wants to be in control of that process, they need to step up and get a management system going and pursue getting a testing server. I think most of the fans will work in cooperation and form groups to manage code and run testing servers.

At some point fans may have more of a vote or say. But, at this point we really don’t and trying to tell those that may run a code management system how to run it… seems rather foolish.

As to picking who it is that actually submits a recommendation to Cyan… why not skip that part. The code is all going to be transparent and testing reports and player opinions are likely to be well known too. Someone might step up and build a rating system where everyone can vote on changes and additions. But, whether or not that happens, Cyan can pick and choose from what we publish. So, rather then worry about who… why not work on a system where people have input and things get rated by the community. Give Cyan a community top ten picks.

Submitting changes to Cyan

Who is online