abma wrote: ↑14 Feb 2023, 11:07
thats not possible: 106+ dropped a lot of code which the fork still has.
Bringing back that code is one of the major points of the fork, because dropping it broke a lot of gameside rendering. Yes, it's not possible to merge the code in the technical git sense of a merge. But it's entirely possible to designate the fork as the new official development branch, or any of similar measures that essentially amount to dropping the commits that drop useful code from the main official branch.
abma wrote: ↑14 Feb 2023, 11:07
A lot of game devs and people wanted opengl4 thats what spring 106+ is.
Yes, game devs wanted GL4, but
also most of them never gave a carte blanche to break existing Lua interfaces.
Some game devs enthusiastically agreed despite the risk of breakage, hoping they would just take code from more mature games. This didn't work out, because mature games haven't completely migrated so far, so these people didn't get what they wanted from 106 (but they can follow mature games on the fork).
Some game devs
were promised a transition branch that would help them smooth out the migration. They didn't get what they wanted from 106, but they are getting what they want from the fork.
Some game devs were promised help migrating or led to believe the breakage would not come sooner than the migration. This didn't work out, so these people didn't get what they wanted from 106, but they are getting what they wanted from the fork.
Some game devs maybe were both willing and capable to migrate to GL4. But
they aren't exactly getting what they wanted from 106.
Some people with no stake at all wanted it and were willing to throw games under the bus. I have no way to know how much weight this carried, but regardless, that specific post wants GL4 to "see a modern version of spring" and "make spring popular again". Not getting what what was wanted from 106, but games on the fork tend to look more modern.
Lastly,
engine devs wanted to drop GL3 so that the engine would not slowly stagnate and die, new possibilities could revitalize it. This was actually legitimate reasoning given the assumption games would migrate. But that assumption wasn't fulfilled, and the reasoning should be reevaluated. Engine devs didn't get what they wanted from 106, but they (both the currently active engine devs doing anything, and most historical ones) are getting what they wanted from the fork which is more alive than Spring has ever been.
Regardless of my points above, what a lot of game devs and people
really wanted is evidenced by most of them switching to the fork.
abma wrote: ↑14 Feb 2023, 11:07
It requires to drop a lot of old opengl code, without breaking stuff thats not possible IMHO.
Yes, eventually old GL3 code should be dropped. This should happen when games making an effort to do it are ready for it, not arbitrarily at somebody's whim. It is entirely possible to advance to GL4 in steps, as evidenced by the fork.
abma wrote: ↑14 Feb 2023, 11:07
Creating a fork and not trying to get it merged upstream
What is
https://github.com/spring/spring/pull/559 if not an attempt to get it merged upstream? How would you have preferred to see this go instead? That PR waited half a year for a review that would not come and they even kept a relatively clean branch so the goalpost wouldn't move. What more could you ask of them? The only thing they didn't do is wait an eternity for a review or merge which was never going to come. There was a month of inactivity before the close during which absolutely nothing happened from the official Spring's side. Even after closing, you could still take the early commits that were reviewed and had no issues raised, or even keep slowly trickling them in. I see a lack of trying but not on the fork's part.
abma wrote: ↑14 Feb 2023, 11:07
(not trying to) beeing integrated into the existing infrastructure
Being integrated into infrastructure would only make sense if the branch was merged, but that is not to say there was no trying. Check
the back-and-forth starting around this post. How would you rather see infra handled? Do you expect somebody to also fix infra as a precondition for accepting major engine work? This doesn't sound viable.
Which guidelines listed on that page were ignored? Being aware of synced/unsynced, code comments, and things like avoiding needless CPU usage obviously aren't what you mean. One thing listed there is "if your changes change gameplay it might be a good idea to make it optional", which sounds like it would apply to dropping half the rendering interfaces, but that's a rule the fork follows well (it's the most important rule by far! It's why anybody is using the fork!).
The rule I assume you probably mean is the one for git branches? But the fork started as just a large feature branch PR, so follows the rule decently (specifically, on that graph it's represented by the leftmost pink commit chain). It's larger than a typical feature branch but that's the nature of the work involved. More importantly, it's just a continuation of the maintenance/transition branch that existed just before the fork did, which had official engine endorsement, and which is more recent than an obscure wikipage that nobody knows about. How else do you expect to handle branches with large amounts of connected changes?
abma wrote: ↑14 Feb 2023, 11:07
All of this was AFAIK agreed / discussed / voted.
As far as I can tell
it was initially voted in 6 years ago in the circumstances and assumptions appropriate to that time. Note that this is before the full emergence of BAR as a separate game, and with basically no gamedev input. It was then
discussed, 2-3 years ago, by game devs who, as I described above, were somewhat cluelessly agreeing on something else than what they were getting after all. This is plenty time to gather enough feedback to decide that this turned out to have been a bad idea and is still a bad idea. This doesn't mean GL3 cannot ever get dropped. It just means that at the moment that GL3 code does more good than harm to the engine and should be brought back. Doing it by wholesale replacing the current main branch with the fork is the ideal way to do this because it saves the most work (the fork is well-tested, major games are already compatible with it, it contains multiple non-GL related improvements, etc).
abma wrote: ↑14 Feb 2023, 11:07
I don't see why this should be changed.
What would be enough to convince you?