Client compile status

[JWPlatt]

I am going to merge the CWE-work changes to CWE real soon. I should probably ask first if there are any plans to make any more changes to CWE-work.

?

[a'moaca']

No more changes incoming, but I did ask for a code review. I know it's all backwards, a developer asking for a code review...

- a'moaca'

[JWPlatt]

Not really. I ask for them. They just don't happen. The problem is always time, cost and deadlines. But being free here, it's more likely to get done.

Btw, I did look through all the diffs. It's all mostly compiler directives set to ignore missing stuff (e.g., not in the external client) and some new code to support libraries, like JPGs, that were replaced. Very straightforward in appearance, but I'll admit I didn't read fully through the logic. I noticed no Russian Water Tentacles. I need to go find that review on Foundry...

[a'moaca']

Well, I did not actually initiate a bunch of reviews in fisheye because rarified expressed concern we were spamming Mark. But I certainly can. OTOH I am fine with statements like here where the diffs were inspected outside fisheye. As long as it gets done we can work on process improvements next time.

I did decide to make a review for the jpeglib changes. I have to put the diff somewhere, so might as well use fisheye. I found that I can change the Moderator away from "Cyan Worlds" so if we do that we shouldn't have to worry about spam. I figured I'd see if JW gets notes. But, when I try to upload the patch, either uploading from a file, or copying the contents into the text box, it says "Error adding patch: null".

- a'moaca'

[Mac_Fife]

I moved a bunch of posts related to Review problems into the ToDo: Code Review Integration thread, to keep this thread about the compile status.

[JWPlatt]

CWE-work has been pushed to CWE. Hope I did it right.

I didn't have any time to think about CWE-work and how to work reviews into the structure of things before I went away last weekend. Suddenly there was a client ready to get built. Wow! So we had to think fast and get it done. We've at least fleshed out a bit more of a review plan (developers --> CWE-review --> CWE). Had I to do it over, I think it's right for a'moaca' and cjkelly1 to have had commit rights on CWE. But sometimes people don't actually want that. So a'moaca' and cjkelly1, please PM rarified and me with your preference for read or read/write.

[a'moaca']

A CWE project lead/cwe-administrator (TBD) would merge them into CWE. At least, that's the current plan. I hope there will be time for community input to gather leaders. If it's me doing merges initally, I'll likely need advice. I'd ask nicely, "a'moaca' could you take a look at this?" Or maybe you and cjkelly1 should have r/w to CWE directly, if you'd like it.

I've thought some about this problem, and how we're going to bridge the gap between now and the wider community "choice" for gatekeepers (gatekeeper: do reviews and commit patches). We certainly do have to bridge that gap. Plus, if the criteria for acquiring write access for anything, including gatekeeper work, includes contributing usefully first, this interim period must be covered by us, so that others can do their required contribution.

If you want me to be a gatekeeper, I am willing to do it with the following rules:

• I do not really want this job. I am just willing to do it because someone needs to in the short term. I record this fact here for all future comers.
• As such, I will retire in the future. We should be able to get others on board soonish, but if I have to I will forcibly retire.
• I will not make functionality decisions. If, in the interim period, we receive patches that change functionality, I won't accept them. We can review them, and if some kind of group consensus is reached, then we can commit them.
• What I will accept is bug fixes, adding back what was removed (e.g. something equivalent to the libjpeg addition I did), or something I haven't thought of yet which is obviously in this class of changes.
• I want it to be clear to everyone who comes looking that I am a very overcommitted person, especially until tax day. If I have not reviewed your patch, I simply have not reviewed it yet. No commentary is NOT a statement about your patch. I will say something, even if it is a reason why the patch needs to wait until later.

Hopefully, for our sanity (our = the five of us here now), there won't be too much action until the process gets defined and some others get access.

If you don't want me to do it and will just consult me when required, that's fine too!

- a'moaca'

[rarified]

Some requests for clarification on the Wiki instructions. I'll add to these as I go along on my second machine setup (the build system):

• Build Steps:(1) Add "if installing on Win Server, needs CoreSDK-common*.cab and CoreSDK-x86*.cab files"
• Build Steps:(2) Clarify "from the SDK" with the pathnames. Possibilities include ...\Program Files\Microsoft SDK\Lib or ...\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Lib. May also note ...\Program Files\ on older versions of windows, and ...\Program Files (x86)\ on newer versions.

Still having some trouble linking in PhysX, will document that in a while.

_R

[JWPlatt]

Your rules are eminently reasonable, 'amoaca', and even generous, as we discover who emerges from the community to participate in this project. In the text I wrote for the CWE wiki page, I've proposed that even bug fixes to CWE are beyond the bounds for now. "Adding back what was removed" would be Phase One. Moving on to bug fixes - Phase 2 to some quantified limit. Functionality - Phase 3 and beyond. That's just for CWE. But MOSS is already operational, so bug fixes (if any!) are in order.

[a'moaca']

I am of the opinion that bug fixes are almost always fair game. I think the only rational reason to delay bug fixes would be if they conflict with some other impending change, and we want to get the other change in first, then resolve the conflict. The only other case I can come up with would be at some kind of major release time, and we're not going to hit that one while in your Phase 1.

What if someone says, "Well, on my machine with weird setup XYZ, the driver returns this thing and the client does a NULL pointer dereference. We should test for NULL first." You would tell them, "Well, you can fix it for yourself, but not in the mainline, because nobody has gotten around to replacing Bink yet"?

Obviously there is a continuum between "if (!foo) return false" and a major fix that requires changing APIs or whatnot, but to just say "no bugs" rejects the first without prejudice.

I think it is fine to state that the focus in Phase 1 is returning functionality, but to state that all else is excluded is kind of chilling to potential interest. I don't think there will be some giant pile of major bug fixes changing everything while someone is toiling away doing merges three times a day while they replace Bink. I would rather see people get a good response on reasonable, manageable things they need than tell them to go away for an indeterminate amount of time.

Maybe you could strike a middle ground and say "no bug fixes that change function signatures during Phase 1", or maybe "public methods" or something. If you're more concerned than me about the potential content of bug fixes in the near term.

- a'moaca'