It is currently Wed Dec 11, 2019 1:06 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, 7 ... 11  Next
Author Message
 Post subject:
PostPosted: Wed Apr 14, 2010 10:09 pm 
Offline

Joined: Thu Aug 03, 2006 10:55 pm
Posts: 625
DarK wrote:
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


I still think the best way to do that is peer review and consensus. Whatever forum that takes place in is more or less irrelevant - the same set of well-versed Plasma hackers will still be the initial set of knowledgeable people to help judge patches.

Also, the GoW is not a large development team - its a collection of small development teams that share info and help each other out.

EDIT: added a quote for context because this was a page topper.


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

Joined: Sun May 21, 2006 11:51 am
Posts: 510
PaladinOfKaos wrote:
I still think the best way to do that is peer review and consensus.


Agreed

PaladinOfKaos wrote:
Whatever forum that takes place in is more or less irrelevant.


Agreed - but I personally would prefer it to take place on a bug tracker to aid in better organising outstanding work

PaladinOfKaos wrote:
the same set of well-versed Plasma hackers will still be the initial set of knowledgeable people to help judge patches.


Would I have to annoy a seasoned developer to get a spelling mistake changed in the KI for example?

Can someone else with the simple knowledge of logging into the game and viewing the relavent change confirm this?

Again a Bug Tracker aids development with this feedback, running multiple trackers for the overall product is counter productive, you will end up with duplication.

As well Uru will have a massive testing base, it would be a shame to exclude all that feedback.

PaladinOfKaos wrote:
Also, the GoW is not a large development team - its a collection of small development teams that share info and help each other out.


All good, but those small teams might be bigger than poor old Joe Bloggs :D,


Last edited by DarK on Wed Apr 14, 2010 10:27 pm, edited 1 time in total.

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

Joined: Tue May 09, 2006 12:22 am
Posts: 1092
Location: On the bluff
PaladinOfKaos wrote:
I still think the best way to do that is peer review and consensus. Whatever forum that takes place in is more or less irrelevant - the same set of well-versed Plasma hackers will still be the initial set of knowledgeable people to help judge patches.

"Consensus" is an ambiguous term, and impossible to assess in abstract spaces such forums.

Whether or not a change "works" is something that has a chance of being defined and assessed objectively. Where it's done is less important than how and by whom, the latter simply because the work will require bodies.

Whether or not a change is the "best stuff" is something that has NO chance of being defined and assessed objectively, so we may as well resign ourselves to some method that is grossly imperfect. Either that or get Chogon to accept that Cyan will be in the best position to judge the "best stuff" from among those changes that "work."


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

Joined: Thu Aug 03, 2006 10:55 pm
Posts: 625
Zardoz wrote:
"Consensus" is an ambiguous term, and impossible to assess in abstract spaces such forums.

Whether or not a change "works" is something that has a chance of being defined and assessed objectively. Where it's done is less important than how and by whom, the latter simply because the work will require bodies.

Whether or not a change is the "best stuff" is something that has NO chance of being defined and assessed objectively, so we may as well resign ourselves to some method that is grossly imperfect. Either that or get Chogon to accept that Cyan will be in the best position to judge the "best stuff" from among those changes that "work."


Other open-source projects do fine, partly through a "If it doesn't break anything that exists, its good" mentality. Breaking changes require a much stronger consensus, obviously, but even those have been managed well for years. One typical system "as long as one person with commit access (or 'direct-to-cyan' access) likes it, it will be added by that person". When it comes to code patches, any new feature is "good stuff", IMO, so for the most part I don't think that should be an issue.

Ages are another matter, and will require tighter guidelines when the time comes. I think there's going to be no choice but to have fan experts/judges of some sort, but they will have to work under clearly defined and publicly stated guidelines.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Apr 15, 2010 12:21 am 
Offline
Obduction Backer

Joined: Tue May 09, 2006 2:00 am
Posts: 1669
Location: Lakewood, WA
dnidaz wrote:
1. Expert advice: snip…

2. Test beds. Snip…

To use dnidaz’s quote –

#1 we all ready have. Most will come forward when the need arises I predict. :wink:

#2 this is the real biggy and will decide most of what is to happen and how. Those that come forward and offer shard hosting will decide what is run on their servers, how it is run on their servers and lastly who is allowed on their server. Most shard owners will have their own forums where shard discussions are held. From there I see some sort of cooperative developing to channel fixes & etc. to Cyan. Something has simple as shard A & B & C say this item passes muster. The less Cyan has to do in all this the easier they can delegate resources to affect change. :wink:


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Apr 15, 2010 12:30 am 
Offline

Joined: Tue May 09, 2006 1:04 am
Posts: 4134
There are only two criteria which any serious evaluation should use: Legality and Stability. Not "best of" not "consensus." Two questions people would ask themselves during any review.

Does this violate the Terms of Service? (obviously to be changed to allow code modification)
Does this crash the game for a person who meets the system requirements?

Anything more than that is only there to create drama and nonsense.

_________________
-Whilyam
Cavern Link:My IC Blog


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Apr 15, 2010 12:41 am 
Offline
Obduction Backer

Joined: Tue May 09, 2006 12:22 am
Posts: 1092
Location: On the bluff
Whilyam wrote:
Does this violate the Terms of Service? (obviously to be changed to allow code modification)
Does this crash the game for a person who meets the system requirements?

Anything more than that is only there to create drama and nonsense.

If the changes that warrant a Yes for those two questions amount to less than "tons" [Chogon: "Obviously, Cyan doesn't have the staff to look at *tons* of changes (such as for the KI, etc.) and apply them to MOULagain."], then those are the only two questions that need be asked.

If not, then additional questions need be asked, unless your response to Chogon is that it all qualifies as the "best stuff" [Chogon: "... and then the best stuff is what is submitted for inclusion into the next build of MOULa."], in which case I presume Cyan would choose the bestest stuff to include in its own build(s).


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Apr 15, 2010 12:46 am 
Offline

Joined: Tue Mar 02, 2010 4:01 am
Posts: 180
Location: The Northeast
Whilyam wrote:
There are only two criteria which any serious evaluation should use: Legality and Stability. Not "best of" not "consensus." Two questions people would ask themselves during any review.

Does this violate the Terms of Service? (obviously to be changed to allow code modification)
Does this crash the game for a person who meets the system requirements?

Anything more than that is only there to create drama and nonsense.


Agreed. Ironically enough, things tend to work the best when all of these "formalities" are put to a side. So long as the "patches" meet your two requirements, as well as making a positive change on the game and not providing for any future problems, I don't see why anything beyond that needs to be truly "addressed."


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Apr 15, 2010 1:54 am 
Offline
Obduction Backer

Joined: Wed May 10, 2006 5:28 am
Posts: 2266
Here is where I think (operative word "think") there is some consensus, some tool and process stuff. Let me know if I got this right. Don't be shy about telling my I'm all wrong -- it's been millenium since I was involved in programming (the dim past. do other stuff nowadays) and I was never involved in open source stuff:

The idea, as far as I can tell, is that everything gets tracked, even if some paths, thread, revisions, go nowhere. As a part of doing this you create versions of code that get pulled together later. I like it!

I'll use other people's words:
1. Use a form of DVCS - distributed revision control. One of the big three is suggested: Bazaar, Mercurial or Git. EMS really like Bazaar

feeds into:
2. BuildBot
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.

BuildBot .......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.

3. Public Bug Tracker -- somewhere.

That looks like some flavor of consensus to me. Is that right?

_________________
mszv, amarez in Uru, other online games, never use mszv anymore, would like to change it
Blog - http://www.amarez.com, Twitter - http://www.twitter.com/amareze


Last edited by mszv on Thu Apr 15, 2010 1:58 am, edited 1 time in total.

Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Apr 15, 2010 1:55 am 
Offline
Obduction Backer

Joined: Mon Jan 15, 2007 6:03 pm
Posts: 96
@Nalates and others -- Perhaps my stance on "not entrusting this to a subcommunity" is going too far. I take the argument that putting it somewhere "neutral" will just make another subcommunity. My only remaining concern is this reputation thing. You rightly argue that I should be taken seriously only if I am actively submitting code. My concern was just that even if I did submit code, I might not be taken seriously because I'm not well known in, say, the GoW community. Not sure how to solve this.

Christian Walther wrote:
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.

But if you read my suggested workflow above, I have suggested an extra step. Your model is:
1. Decentralised branches, which anyone can create, with "test" code.
2. Official Cyan-run trunk. Cyan decides what to pull from decentralised branches.

Believe me, that decision making and merging is a LOT of work. I don't think Cyan have signed up for this job.

My model has an extra step:
1. Decentralised branches, which anyone can create, with "test" code.
2. Official community-run trunk. Community decides what to pull from decentralised branches.
3. Official Cyan "production branch". Cyan decides what to pull from the official trunk (potentially "all of it" as long as they like what they see).

In this approach, some trusted community group does all the hard work of arguing over what should be accepted, and doing the actual merging. There are also "official test servers" run by the community, which run trunk code. All of this happens without Cyan's approval.

Then at Cyan's discretion, they selectively (or completely) pull from the trunk onto their servers, which then go into the official game. This means that a) Cyan does not need to look at individual branches, only look at the trunk, b) Cyan has some level of trust in the group managing the trunk, and c) Cyan employees can get a feel for the current state of the game by playing on the official test servers. Given enough trust from Cyan in the maintainers (who they could even hand-pick), their job is as simple as doing a weekly peruse over the commits to trunk and a play on the test server, and doing a merge from trunk onto their branch.

Christian Walther wrote:
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.

It isn't quite that simple. The "big three" do interop somewhat with each other, but not nearly as well as I'd like. I'm told a major issue here is that Git doesn't store metadata on commits, which means that while it's possible (though not very easy at the moment) to use Git as a Bazaar client, it is and always will be impossible to use anything other than Git as a Git client. Just one reason I don't recommend Git ;) It's true that they all interop with Subversion, but that implies we're using Subversion -- which I strongly don't-recommend.

So I think in general, we need to decide on a DVCS and stick with it. It should probably be Cyan's decision. Yes, these arguments can go on forever (I've been in them) -- so we shouldn't argue about it. Someone just needs to decide.

Whilyam wrote:
There are only two criteria which any serious evaluation should use: Legality and Stability. Not "best of" not "consensus." Two questions people would ask themselves during any review.

Does this violate the Terms of Service? (obviously to be changed to allow code modification)
Does this crash the game for a person who meets the system requirements?

Anything more than that is only there to create drama and nonsense.

Whoa ... you're suggesting that every single change which is legal and doesn't crash the game should be accepted outright? So I could write a patch which immediately unlocks all Relto pages, or make star-wipe transitions on all Ki screens, and we shouldn't have a debate about whether those changes are worthwhile? (Someone in another thread suggested we add Facebook and Twitter integration into the Ki ... surely we should think twice before we make such a feature!!)

Much more so than normal open source "software", Uru is a game. Therefore, each change needs to be finely questioned for gameplay and aesthetic. In other words, adding a feature into a video editing tool is probably a good thing; adding any random feature into Uru will and should be met with a lot of skepticism.

One thing I do not want to see in the first month of open source release is Uru immediately contracting a million useless bells and whistles, just because someone things they are a good idea.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Apr 15, 2010 2:18 am 
Offline

Joined: Tue May 09, 2006 12:33 am
Posts: 1182
Location: British Columbia, Canada
For what it's worth, Cyan internally uses Subversion (as of 2004, after switching from Visual SourceSafe). A former Cyan employee contributed code to the AnkhSVN plugin for Visual Studio.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Apr 15, 2010 2:50 am 
Offline
Obduction Backer

Joined: Sun Feb 14, 2010 7:53 pm
Posts: 157
OHB wrote:
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)


As a diff (machine-readable format):

Code:
5052a5053,5054
>         if ageName.find("(null)") != -1:
>             ageName = ageName.replace("(null)", "")
5103,5104d5104
<             if ageInfo.getAgeFilename() == "Personal":
<                 return 0

_________________
Have Ages, and link to them without bindings. [Words 1:13]
Seltani


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Apr 15, 2010 2:59 am 
Offline
Obduction Backer

Joined: Wed Feb 10, 2010 12:28 am
Posts: 1247
Pavitra wrote:
As a diff (machine-readable format):


Thx...I'm lazy. That'll work assuming you're checking against the original :)

_________________
Image
Click here to change my signature!


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Apr 15, 2010 3:07 am 
Offline
Obduction Backer

Joined: Sun Feb 14, 2010 7:53 pm
Posts: 157
(Post moved here.)

_________________
Have Ages, and link to them without bindings. [Words 1:13]
Seltani


Last edited by Pavitra on Thu Apr 15, 2010 3:27 am, edited 1 time in total.

Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Apr 15, 2010 3:17 am 
Offline
Obduction Backer

Joined: Mon Jan 15, 2007 6:03 pm
Posts: 96
Can we have feature requests and patches submitted to a different thread? This is already convoluted without having diffs flying around.

In fact, it might be good to open up a new forum "Open Source Myst Online - Bugs, Feature requests and patches". That could serve as a makeshift bug tracker while we get organised.


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, 7 ... 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: