Sign in to follow this  
Followers 0
SigFLUP

To fork or not to fork, that's my question

4 posts in this topic

So as far as I can tell SDL 1.2 gobbles up ConfigureNotify events when they relate to windows being moved. It's a small patch to make it not gobble this up and pass it as an SDL_SysWMEvent instead. THE PROBLEM IS the unstable SDL 1.3 is adding lots of new window-aware features and 1.3 is actually making use of ConfigureNotify upon window movements events. SDL 1.3 is probably not going to be stable for awhile, right. So do you think it would be better to force people to get using 1.3 prematurely or fork over SDL 1.2 with the appropriate changes? The fork, of course, will only be alive until 1.3 becomes stable and we can throw it away. What do you think? To fork or not to fork? To fork would simply be a matter of including the patched 1.2 with your source. Not to fork would be to tell everyone they're fucking n00bs and they should upgrade the the unstable release already.

Edited by SigFLUP
0

Share this post


Link to post
Share on other sites

fork it in the ass. if they cant find it here or wherever then they can deal with 1.3

0

Share this post


Link to post
Share on other sites

Having forked a project myself (rdesktop forked as FreeRDP), I can tell that you must be absolutely sure that you're going to be successful. SDL is quite a big project already, so you must have a very good reason to fork it to avoid just wasting your time and nobody joining or using your forked project. What I suggest however is that you maintain a set of patches that fix the problems you are talking about until 1.3 is out and stable. Also, as you said, the fork would probably only last until 1.3 is out, so there is no point in putting that much effort to fork the project in the first place. I don't recommend that you fork SDL if these are the only reasons you want to do it, and that you expect the fork to last until SDL 1.3 stable.

In my case, the developers of rdesktop are simply putting big breaks on contributions and are not very actively developing anything. This is why rdesktop only supports old versions of RDP and lacks a lot of the new features that have been introduced over the years. The guy owning the project own a company that makes a proprietary front-end to rdesktop, and they do not accept contributions unless they're really small patches that only fix a problem. The major problem is that in order to support the new features of RDP, major changes in the design of rdesktop are required, which is something they would never accept. Forking was the only solution to be able to make all those changes.

Also, forking takes a lot of time and energy. If you do not have a lot of time and energy to spend on a fork, don't do it.

0

Share this post


Link to post
Share on other sites

You're probably better off building SDL statically and applying your patch to whatever you're working on or submitting the patch upstream and trying to get it pushed into the next release of 1.2.x. There really isn't a reason to fork the project over a few lines of code, especially since you'll have to maintain all the rest of the changes that are done upstream.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0