Marten wrote:
JWPlatt wrote:
I don't think Branan's comment about "Cyan's arms-length open source approach " and Marten's wanting "OU to become the master repository" are consistent.
Wut? Please look at these two statements.
Paradox wrote:
The OpenUru repository should be the master repository, and Cyan should be seen as a fork just as much as any other developer.
Marten wrote:
I, like Paradox, would like to see OU to become the master repository.
What isn't consistent here? 
Well, for starters, your quoting of Paradox when I was referring to Branan.
Branan's "arms length" appears to mean Cyan's taking compatible updates from OpenUru.org instead of directly from h'uru (or others). Well yeah, relieving Cyan of the burden, and the community of the costs (CAVCON), are major aspects of making Open Uru possible. Judging by the work involved for our part, Cyan wouldn't have the time. Contrast that with your wish which does align with Paradox's. Reading the terms in Branan's posts again, I'm still not clear if I'm understanding it correctly anyway which is why I added "I'll need to think on this more," which you removed from the context of a larger post where I addressed many things as quickly as I could in limited time. Also, as I mentioned, I was referring to Branan's term, and you quoted Paradox. Wut?
Marten wrote:
Mac_Fife wrote:
I don't know that Cyan are prepared to release details of their build engine
JWPlatt wrote:
About Cyan's build environment: Consider what it means if MQO, or some other Cyan product, and MOULa are released through the same build engine process. How do you think an upgrade to the build environment affects things? Who absorbs the costs? What does it mean to the continued maintenance of all? What is Cyan's responsibility when considering fan requests that could affect the commercial products of other clients? I don't know all the answers to that. Do you?
Cyan just has to tell us if fan-originated changes are going to create a problem for them, and explain what we need to do to stay compatible if that is a concern. If Cyan can't do that, I don't see why open source devs should be forced to treat the build system like a booby trap, terrified that the slightest change will bring destruction. I'm sure nobody wants to be the person who broke everything for Cyan, but your questions honestly feel like you're pointing at a lush meadow and whispering, "Can't go that way. Might be a minefield." We can't live in fear of the unknown. We have to forge forward and make it known.
About the build system, I am not saying what can or can't be done. At the time, there seemed to be a clinging misperception that OU supports only the VS2003 environment when in fact we can automate any build environment, including h'uru's. I was suggesting that folks try to understand that what they think is easy for Cyan might not be so easy if they stop to consider and understand the consequences. We'll do our best to relate the challenges from what we understand of it, but clearly MOULa is not Cyan's only concern in terms of their build system.
_________________
OpenUru.org: An Uru Project Resource Site : Twitter : Perfect Speed Is Being There.
