I'm largely parroting what's been said else where, but another voice of consent can only help.
I’d get behind building future clients from H-uru, just for the build being generally easier to deal with.
I’ve been hacking out PhysX for Bullet, and initially after several hours of attempting to do things with the CWE-OU client and not getting very far, I moved to H-uru.
I got a built client in a couple of hours, and after setting up a local DirtSand Shard, I was gleefully ripping out PhysX from the client not too long after.
The ease of getting setup came from the active development, it shows, and as the CWE-OU client is so far behind H-uru in terms of development. I think it makes sense to remove CWE-OU as the upstream and focus efforts on H-uru.
1. Mismatching developer Attitudes
a) I agree there needs to be some control, but OU seems overly committed for the actual scale of the development and with so few people involved this possibly has hindered development on this version of the client.
I think the “seat of the pants” development is helping development for H-uru, as when developers have limited time to code, they want to code.
The development process Hoikas has outlined looks good as there are only a good handful of developers involved at this time.
The +1 rule protects, but does not hinder and defacto owners can give veto on troubled commits when there is contention and reasoned discussion has taken place without a resolution being found.
It’s easy to fork/branch a stable build tree, debian style, and impose a rule to only commit to stable when a release goes out. This seems a quick and easy method to maintain stability, and a tried and tested method.
b) As new code/widgets come out with more efficient methods of doing things, we should move with those changes, especially if it frees up a developers time, provides advantages up-stream to people such as builders, and improves a player’s experience.
I think change is something people need to get used to, as maintaining legacy code for the sake of a few people is not productive development, particularly where available time is a large factor.
An example is maintaining an XP Build, if there is enough people with a need to warrant a developer’s time it will likely be a cause for concern for the main client. Otherwise anyone wanting to develop an XP client should be encouraged to fork.
Research Points
a) Testing Shards, I would consider how many we need, as fewer is better. You want to be able to have the largest amount of testers working on a single set of code to confirm suitability, with rotation of the code on test being high.
Developers do testing themselves on their local code, and with a +1 also confirming testing, this should be enough to move code to a mass testing shard and from there to release.
Personally I would say one is the max to officially run, with of course the ability for anyone else to set something up too if they wish to invest their time.
b) I would hope there will be divergences between MOUL and H-uru as this shows progress
There really should be no thought given to branching and moving down other routes, it should just be done, but with an aim to have it pulled to a stable build in the future.
As community builds are being used on MOUL, there is hopefully a case for consideration for the “official” MOUL client to look very different in the future, particularly if community server builds become part of the equation too.
2. MOUL server compatibility
See above 1b) – Most of this can be avoided by having the correct pull structure, and where MOUL breaking changes are occurring, don’t push them up-stream.
3. Code Removal
I don’t think this needs further discussion as getting rid of legacy code is only a good thing
4. Windows XP Compatibility
As a desktop specialist, I have very strong feelings on people who still use XP due to it causing me pain professionally
so the following is very biased!
First, the OS is 14 years old and anyone who is still using it should have some form of expensive scientific instrument attached to their computer to warrant still having windows XP (I do still support some Windows 3.1 and DOS 6 systems for this reason). Please for the sake of technical people’s sanity, look at upgrading if you can!
I support expanding the client’s telemetries for OS version creeping to assist with number gathering to see if XP builds are still warranted.
On the other side of things, getting the engine as open and free as possible, to improve portability and compatibility should be a main aim.
As a stop gap, it looks as though the XP Build is something that we don’t immediately have to deal with thanks to Marein’s and Hoikas’s recent work
5. Mac compatibility
There are two ways to do this, wine, or a native client.
Wine is generally good when you are in a fix, but say the client starts to use something not available in wine it might stop implimentation of a feature or bug fix while wine catches up. Wine's priorities are also diffrent so we could be waiting for a long time for something to apear, if at all.
A native client has more scope as this brings in possibilities for a Linux client as well due to the similarities between the two OSes.
There is progress in H’uru to remove dependency on DirectX and replace it with an agnostic pipeline (and another reason to look at H’uru as a replacement for CWE-ou), and looking at Bullet as a replacement for PhysX should remove the need for anything windows specific.