Is there any chance of all of QZDoom going back into ZDoom as mainstream?
Up to Randi. I doubt Graf would have a problem with it, but Randi doesn't want it and I don't blame her. She has her way of doing things and QZDoom is a bit avant garde in its approach. It's stirring the pot that's tasted fine for 18 years. Also as time passes it will become more and more stuck with GZDoom features. I think Graf is far more likely to merge QZDoom himself for GZDoom than Randi ever will and even that's not a great chance of happening. Honestly? Talk to Randi. Get her thoughts on it. She probably has a lot more insight into this issue than I can provide, and my guess is she's dealt with similar systems before in the past.
I can tell you that my personal experience with the LLVM merge hasn't been all rainbows and unicorns and happiness and optimism. There have been multiple issues with LLVM that have made me want to get rid of it. They aren't an issue now, though, so it's fine where it is. But I doubt I've seen the last of them.
But my concern is just... what if one day either of you (or all of you) decide to call it quits? We'd then be stuck with a QZDoom that is so detached from ZDoom with no hope of anyone knowing how to merge the features back into ZDoom?
Things like that happen. For this very reason I've tried keeping the ZDoom base as consistent as possible. dpJudas wanted to rewrite the palette drawers for readability and for expandability but when I expressed my concern about future ZDoom merges it stopped him in his tracks.
Part of the reason QZDoom even exists is because at the time the fork was conceived, the TrueColor branch had already been abandoned for some time. It wasn't hard to merge in the latest ZDoom code and get things going again, but merging in GZDoom is what proved to be difficult.
My repository is forkable. You can clone my master and create a branch inside your own ZDoom fork - in Git, the refs matter more than the names given to your branches and/or tags. This will also allow you to open pull requests (just clone your new branch, or use my repo's HEAD commit number)
And lastly, correct me if I'm wrong but is LLVM the only reason this had to be forked?
LLVM had nothing to do with the fork. The fork was created because for 5 months no one responded to or merged the pull request. The work was essentially abandoned at that point. The fork was made to resurrect and continue it, with or without Randi's involvement. (I would've preferred for it to have been merged into ZDoom before that happened, actually, but Randi was inactive at the time and that was impossible).
Why was it decided that "LLVM won't go into ZDoom, so it looks like QZDoom has to be a separate program"... ?
I won't speak for Randi on this. But my guess is - bloat. Including LLVM expanded the size of the executable by a factor of 3. It had some advantage, though - assembly code is compiled on-the-fly (during startup) tailored to a user's specific processor and taking advantage of every available extension LLVM provides and the processor supports - including things like SSE2.
Thing is, ZDoom's assembly drawers have worked just fine since they were there. They may have been an impediment for other coders touching the software renderer, but they have served their purpose and continue to do so well. This really is something that, if Randi wants to change, she's going to be changing a lot of how ZDoom works and has always worked now for a very long time. She will be abandoning lots of hard work that she had done with those assembly drawers that most of us who look at the code hate (despite how sleek and great they are). The cost of having LLVM doesn't currently outweigh the benefits except purely from a programmer's perspective before you reach for the "Compile" button.
I don't fully see the justification in having these as separate programs
Having a fork gives it autonomy. Like how Graf is able to operate GZDoom independently of ZDoom and do his own releases on his own schedule, QZDoom works similarly. Also, it allows me and dpJudas to work on the port directly instead of submitting code patches to Graf and Randi hoping they will accept it and always being unsure of when/if. I have given write access to a few key developers, and even offered it to Graf (though he has not accepted it yet). If me and dpJudas disappear as you are concerned of, there's no way this can completely die unless you just let it.
dpJudas even today still has pull requests pending in GZDoom, and I had one pending that you took over. Neither have been accepted yet. This kind of system doesn't work well for us, in terms of moving forward and innovation. That's why QZDoom went to its own fork.
--- Conclusion:
Sorry this post is so long. Basically what it comes down to is this - you want this merged into ZDoom and GZDoom? Please - talk to Randi and Graf. They both have to be involved - and quite heavily so. The code needs to be sorted out for what goes where. Managing the merge is going to be difficult (well, easier for GZDoom really, but not quite as much for ZDoom itself).
Right now, they are working on perfecting ZScript, so nothing is going to happen until they reach a stopping point in that project.
First things first though - you do need to PM Randi and ask about the dev forum. Then, you should bring up the topic in that forum so that it can be discussed.
I can tell you one thing - if this goes back to ZDoom, I doubt LLVM is going to survive the transition. The LLVM code is likely going to be rewritten with actual assembly drawers, and as a result QZDoom will lose its ability to expand as quickly and as easily as it has over the past few weeks. QZDoom is also directly responsible for a few software renderer bug fixes - without the existence of this project, I doubt the bugs that were present with mirrors and skyboxes would now be fixed.
)
