Re: [tsc-devel] SFML and further development process

datahead | Tue, 06 Oct 2015 13:32:27 UTC

Post via forum by datahead <…9@x…>:
Reposting in the forum (in the correct thread this time):

> The SFML port is so complex nobody is going to work on it voluntaryly, but it needs to be done.

No, it will probably not be easy to get people to volunteer, but I just tend to be very hesitant about forcing options on contributors when they are volunteering time.

There is no getting around merge issues if there are major conflicts. I was thinking we could lock down devel and create a delayed-features branch, but, ultimately, the delayed-features branch much be merged back into devel after the SFML port, which just delays the same nasty issues. It is unrealistic to expect the coders of the features will be available then, and discarding individual changes will be virtually impossible.

What does everyone else think? We need input from more people before making a decision on something like a lock down.

Also, there will always be something like this that "needs" to be done. Before this it was release 2.0 (which went for a long time) , and after this it will either be the SFGUI port or CEGUI upgrade. I fully understand massive things have to be done, but I'm a little concerned we may hop from major priority to major priority honestly. Thus this question will arise again later.

On one last note, my Doom Larry feature was ready before any such lock down started. I would at least like to put it in devel. We can discuss what is done with other features from there. This feature also should not be likely to create major conflicts with the SFML branch.

-datahead

-- 
Sent by Chessboard.