Dosbox-staging: How to keep in sync with SVN?

All great points @LowLevelMahn.

We are all here because we love DOSBox, DOS games, (even if we code 99% of the time and play 1% ,😅) and want to see DOSBox thriving and healthy for the foreseeable future.

We do not understand upstream's goals, time frames, plans on how to get there, and resource needs/wants to support those plans. @dreamer has laid those our for dosbox-staging, however you can see the responses from the upstream maintainers.

There is no discussion offered; no _"hey, great, here's what we want to accomplish, here are areas we need more help with. Oh, and your suggestions on doing X, Y, and Z are great - can you help us with them?"_, and so on. Zero.

Open source lives and dies on momentum and community. The fire in @dreamer and myself to make progress is a tenuous proposition, and something that shouldn't be squandered.

My health will surely worsen and make what little time I do spend on this impossible or kill my motivation/ability. Personal interests wax and wane; family or other commitments can take over.. so "slowing down" isn't an option.

However, overflowing upstream also doesn't have to happen. The commits are all reviewable and mergeable on by one, and the process championed and followed by @dreamer allows upstream to absorb it at their pace, layer by layer; regardless how fast we run ahead.

For the three points you're asking about (if upstream wants them); my best estimate is _no_ simply based on actions and the absence of direct feedback and plans on those topics.

"slowing down" isn't an option.

so true

so there is just hope to get the mainline developers into the boat - seems to be enough

Talking about community, which I consider all of us here part of the potential DOSBox community (ie: trying to prevent further fragmention) - there's a fantastic study done on open source communities (no one is paid, no one is your boss, structures must form on trust, respect, and members granting authority to leaders) and the fascinating insights into how they form, grow, fragment, and fizzle.

https://link.springer.com/article/10.1007/s10664-018-9659-9

I agree with everything said in this thread so far :)

what is the current svn stance on the big 3:

1. getting more C+11 into the code base: that will break SVN compatibility very fast and hard

It's not that bad - we are not making sweeping changes, and SVN does not receive that much/any activity in the areas we are touching. The single place where we had conflicts so far was trivial things in cpu emulation code - we just stopped meddling in this area for now - I don't know if jmarsh is watching our warnings limits/static analysis findings or not, but his recent changes improve code quality and remove warnings. We'll just stay away from that area of code for now, and if we'll want to implement something in there we're going to ask for confirmation our changes are ok (I saw a couple of micro-optimizations that could be implemented ;)).

1. remove of OS/2 code? is seems possible to use gcc4.9 and SDL2 (from main repo) according to "josch"

Yeah… someone still needs to actually try it and not only claim, that it works "for sure". It was high time to merge it in, as it is a prerequisite for SDL2. With OS/2 code still in, we would have a version that maybe even compiles (who knows?), but definitely wouldn't start (all SDL initialization code was basically rewritten for SDL2, and originally before ArcaOS even existed).

1. remove of win95/98 support (ScummVM still got it having both SDL1 and SDL2)

Similar story to OS/2… Also, users of Win9x on real hardware, who enjoy retrocomputing can boot their machines to real MS-DOS, so there's no real need for DOSBox in there… Unless they want emulate 286 era games or something - and in that case, my question would be: why? Anyways, they will still be able to use DOSBox 0.74-3 branch for years to come.

On the other hand, support for those systems slows down development - not only because of old compilers, we can't test if our .EXEs built for i686 even start in there - even today I read this feature was not implemented because it was impossible to make it work correctly on Win9x.

For next patch series, I think I'll also reorder the patches a little bit - not all our changes require C++11, perhaps if we moved some of them to the front of the queue, we could make the upstream catch up a little bit :)

[edit]
As for sync SVN->Git - I think on average we have all changes from SVN merged in under 6h after they happen upstream (as soon as I see a notification about new commits - I have an idea how to automate it a little bit more).

[another edit]
Also, I can't emphasize enough how helpful Git is in automatically merging changes coming in from SVN. Git has many merge scenarios implemented, and can handle quite complicated edge-cases all on its own. The way we merge these changes (as in having svn/trunk as a separate branch) makes it easier for Git to resolve various situations.

@LowLevelMahn ; has your question been answered by @dreamer? Hopefully we can close this.

I think the question has been thoroughly addressed in the good discussion here in this issue; so closing this.