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

Chris Jacobsen | Tue, 06 Oct 2015 13:08:55 UTC

> 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

 


     On Tuesday, October 6, 2015 7:11 AM, Quintus <…s@q…> wrote:
   

 datahead <…r@f…> writes:
> think we should just highly
> encourage people to work on the SFML port, perhaps going so far as to
> ask someone who is contributing features if they would be willing to
> work on the SFML port.

I have doubts that this is enough. The SFML port is so complex nobody is
going to work on it voluntaryly, but it needs to be done. Thus, I think
it is required to systematically cut it down into pieces and then
resolve it step-by-step. If it is not tackled systematically, it will
take eternity to complete, with parts of it being overaged while others
still need to be written. Doing it all in one continuous effort will
prevent that. The usual, casual “I work on this or that” will not
suffice to get the SFML port completed.

Vale,
Quintus

-- 
#!/sbin/quintus
Blog: http://www.guelkerdev.de

GnuPG key: F1D8799FBCC8BC4F