Blockhead wrote: ↑Tue Apr 11, 2023 02:25
orwell wrote: ↑Mon Apr 10, 2023 18:43
- All tracks that have >2 conns will need to add an additional definition table, detailing the turnout/crossing layout
It would be nice to provide templates in the core that Train Track will use, just like the templates that were added for the crossing shapes when I did that work. That way only odd shapes need to be written out in full.
orwell wrote: ↑Mon Apr 10, 2023 18:43
I will take care of porting advtrains_train_track accordingly, this includes the crossing nodes. I will try to keep the preset-based track registration intact. Also, LUA ATC getstate/setstate will remain compatible.
Do you see any issues in this regard with your current mods?
Mods that are forks of AdvTrains Train Track will need updating, so that is at least
linetrack and
tieless tracks. They may continue to work in-place but if not, it would be good to PR it.
I think it should be possible to change the conns definition in the way orwell described while allowing other mods to continue using the template.
I think that AdvTrains master has moved too slow which encourages forks, [...]
I think that AdvTrains needs to make some moves to fix some quick easy things that have been sitting stagnant in the mailing list, which has a chilling effect on contribution.
+1. The patches on the mailing list is piling up. I spent some time looking at some of them, but ultimately these need to be merged upstream to be useful.
On the topic of mailing lists, we are still not performing CI on patches.
new-ks, route programming rework and so on are good projects for the future but they take a long time. Part of good project leadership is taking contributions and merging them quickly enough to keep people interested.
Well, I started new-ks mainly to improve Ks/German signals. That turns out to be the part of new-ks that takes the least amount of time, as certain.
The main thing that kept me back from working on other parts of Advtrains is that there are enough times for me where small patches became worthy of a dedicated branch, and (especially recently) I do not have much time to work on all these ideas myself.
Then there are the l10n and doc branches where
something is always missing and have (even for me) lower priority. These also happen to be things that more or less need to be updated constantly. Even with less changes recently, there is a lot of work based on what we already have, and things on these branches are only further complicated by new-ks and the route programming rework.
Look, I am here to help, and I could take it upon myself to go and merge a heap of patches into a personal fork today. But unless I could guarantee that upstream would accept that as the new master, it would be a waste of time. So I'll only do something like that if I can get buy-in from orwell.
Have you consider asking orwell whether you can become a maintainer? IMO you would do very well, considering your existing experience in both Advtrains and Supplemental projects.
56independent_actual wrote: ↑Tue Apr 11, 2023 11:18
Blockhead wrote: ↑Tue Apr 11, 2023 02:25
But unless I could guarantee that upstream would accept that as the new master, it would be a waste of time. So I'll only do something like that if I can get buy-in from orwell.
There is a solution, but i'm not sure if you or the community will like it. I, myself, have taken it up myself due to circumstances surrounding me and the project.
You could open your own fork of Advtrains.
By making tons of patches, improvements, and other things, you can then manage the "upstream" and make a better Advtrains. Using this fork, you can then compete against Advtrains and maybe win over the userbase and fix the problems yourself.
I do not think Blockhead or orwell have anything against forking, especially considering that Blockhead forked many of mbb's mods himself to work on them during mbb's absence.
IMO the main thing to consider when forking mods is maintenance. It does not take much effort to
merge patches: this can easily be done with
git am. However, maintaining a fork requires dedication, and things can get relatively messy if you want to sync it with upstream and the latter is focused on introducing large changes. I have had a few merge conflicts a few times during my time working on the HUD and new-ks, and that involves only a small part of the Advrains codebase.
If we have three seperate forks of Advtrains fighting each other, the main advtrains can then get to a competitive level. If all three forks merge together later on, all three communities combine into one and the total power may be extrodanary, nothing ever seen before in Minetest. [...]
The future looks grim with the stagnation of Advtrains to a halt [...]
The stagnation of Advtrains itself does not necessarily make the community around it stagnant. DlxTrains, Doxy's Minitram, and Supplemental show this quite well IMO.
I do not see competition as a way of making upstream Advtrains more competitive. The reason that the development of Advtrains stagnates is that it is limited by the free time of its developers, and more people forking Advtrains will not make them have 26 hours a day.
[...] (there were only four commits to master in 2022! FOUR! Even my fork has already made more then that in the first week alone!)
It is the changes that matter. The number of commits
itself is irrelevant - sometimes I (during the process) mark some minor commits as "fixups" when rebasing, which reduces the number of commits that end up in the master branch.
The other thing is that this ignores the work put into feature branches. The commits are not pushed directly to master because a lot of work is involved.
That said, the development of Advtrains was not in its best state, as you mentioned earlier.
But, even if the forks stay seperate, there is still hope. By co-ordinating efforts and preventing feature duplication and agreeing on some middle ground fork which merges all three features, we can achieve a simialr effect, but in a more human-conflict-based way, the way that works for humans.
... in which case separate forks are not seriously needed long-term as the middle ground becomes the de facto upstream; or let's hope the best for the poor guy that tries to merge everything together.