Toffo wrote:The way development seems to work is, people with commit access ("the devs" we keep referring to) review patches, and if they see someone contributing enough patches with enough quality, and personalities are not a clash, that patch contributor might get given commit access and become part of this devs group.
It helps a lot if you are discussing the idea, eg at IRC. Actively working to get it accepted helps loads too. That generally implies rewriting your patch 2 times or so, just like I do while hacking OpenTTD (I think I am around rewrite 5 for the scenario thingie currently, and I am not even close to done, but so often is an exception, due to the scale and the number of areas it touches.) While it seems a waste of time to rewrite functionality, in my experience, every rewrite improves the code. Every review improves the code. Stick with it, and at the very least you'll learn how to write proper code, and very likely you'll also get it into trunk.
Just dumping a patch onto FS and wait (what almost every patch author does) is a very risky strategy if you want it accepted, especially if it's real functionality instead of a small 10 line bugfix.
Toffo wrote:Well that's it, isn't it? Life gets busy, people get busy. So if the devs are too busy to review patches, or have standards that are so high that no patch contributor can or will meet them, eventually the current crop of devs get will too busy with life and the new crop of devs don't get accepted. No one gets to contribute, the project dies, and those in charge at the time will have overseen that death.
The standards are what they are, because we believe it's the best approach. You are free to disagree. At some point this becomes a difference in project direction, and a reason to fork, eg like Cirdan has done.
Forking is always possible. You don't have to wait until OpenTTD is dead, devs are not in control like you sketch it.
If you want to have the current devs aboard, then yes, you will have to convince us, but it's not required to continue the project.
Toffo wrote:I can see how many might think that. But when I check out the OpenTTD Development forum, I see JGR's patch pack, NotRoadTypes, Spring 2013 Patch Pack, New map features (cirdan's work), etc... There's tons of cool stuff happening in NewGRF-world too. There are people out there, doing stuff. It's just the stuff isn't ending up in trunk because those who can put it in there, don't. From what I've read, it sounds like the right decision at this point not to commit all these patches, but either way it's just not ending up in trunk.
JGR does submit patches, and they get into trunk. NRT isn't ready afaik, Spring patch pack I don't know, cirdan has decided to go his own way a long time ago. Everything NewGRF doesn't need to go in trunk, simply because it is already in OpenTTD. I don't know of any other serious NewGRF extensions than NRT but I doubt it exists. (To me that means having a GRF spec for it, an NML patch, and a OpenTTD patch, ie at the level that all NewGRF authors can actually use the new extension.)
Toffo wrote:My personal view is also the "build first, refine later" view - but granted, this view of mine has never been applied to software development. OpenTTD is already refined though
Not by a long shot. Do the "start new game" and "autorenew vs autoreplace" exercises I suggested. There is a lot more unrefined crap below the hood which is much more challenging to get right. Most of my commits is refactoring, ever since I became dev, and there is still plenty. Consider yourself invited to experience consequences of your view in reality.
Toffo wrote:Is it possible to meet part-way for the good of the project? Would meeting part-way be good for the project? Is there any way contributing to trunk could become satisfactory? What would need to change so that it becomes satisfactory? These rhetorical questions (that I think are worth answering) are for you and others with your coding ability and commitment to OpenTTD.
I think it means to code while having merging to trunk into mind. Even then, likely lots of work has to be done to make the merge to trunk really happen. It might mean rewriting large parts of the patch. Be available for discussion, be willing to change things (or not change things!), and deliver high quality.
Toffo wrote:JGR wrote:Alberth wrote:... re-organizing [OpenTTD's code] basically means taking everything out, and rewrite it from scratch, thus throwing away years of work, while spending even more years of work to fix the thing and get a solid foundation for the next features.
Iterative refactoring of the the existing codebase (with or without extra features applied) is quite achievable.
So which is it? Pointless/too painful, or achievable/worthwhile? Will it be worth the pain in the end? And is there a group of people willing to try, and stick it out until the end?
These views are not mutually exclusive. We need backwards compatibility, so my description "take stuff out and rewrite from scratch" is a very simplistic view on reality (although true at a higher level of view). In reality, I do what JGR says, making small rewriting steps to push the code base into the right shape for the next fix or feature. Have a look at all "-Codechange" commits which outnumber "feature" or "fix" by a factor 5-10 or so. In the end however, all my rewrites effectively replace/amend old code with new code.
Toffo wrote:By all measures, OpenTTD is a remarkable project. But I think we're at a turning point where for OpenTTD to remain remarkable and to stand the test of time, things need to change at a fairly fundamental level, and big decisions need to be made. These decisions, or lack thereof, will rest on the shoulders of the few.
This is a false assumption as I said, you don't have to wait and do nothing.
There is a second reason I think. You can't expect devs to fundamentally change in how they do things, just like we can't force patch writers to only provide patches that we completely agree with. If you want to change the direction of the project, you must either convince devs to change opinion (which is going to be very very hard, as they are grounded on technical foundations and experience of the last 10 years), you must become a dev yourself (fight the system from within
), or you must fork and take over as the main OpenTTD version.
At least, I see no other way, or did I miss something?
EDIT: Oh, and "fork" is not the solution I think, it's the start of the same problems, but for the person(s) forking.
Being a retired OpenTTD developer does not mean I know what I am doing.