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

Quintus | Tue, 06 Oct 2015 16:23:35 UTC

datahead <…r@f…> writes:
>> 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.

I think “forcing” is the wrong word. I am not going after anyone here if
he doesn’t code, or code something different from what I suggested. But
I deem it necessary to get a structured co-operation model set up that
yields more than “everyone does whatever he feels like now”. It is a
well-known fact that if multiple people work on the same thing, this
thing gets finished more quickly, and usually better, as if only one
works on it. If everyone just does whatever he wants, there is the high
danger of unfinished stuff lying around.

Let be clarify on my previous posting, because I think you misunderstood
an important detail of my suggestion. I was not meaning to impose our
internal co-operation model to occasional filers of pull requests,
i.e. casual contributors. These will always be considered, regardless of
what they choose to work on. What I am referring to is only the
co-operation model of the TSC core team, i.e. those people who devote
their time regularyly to the game.

> 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)

The SFML port is a fairly unique effort that will not show up in this
nature again for years to come. A task of such dimensions is not going
to reappear soon.

However, you are of course correct that there’s always something that
“needs” to be done. I think we should set up a more systematic
co-operation model for these ordinary tasks also, but it shouldn’t look
like the one I was suggesting for the SFML stuff. This model is more of
an “emergency” model for the really pressing issues, and I could imagine
that its activation should be subject of vote.

> and after this it will either be the SFGUI port or CEGUI upgrade.

You’ll grant me that this is so closely related to the SFML porting that
I didn’t draw the difference. I think I could have labelled it “wiping
out the 10-year old base code from TSC”, but “SFML port” was more terse
:-)

I do not think that this issue (it actually is only one, as they’re
exclusive to one another) is so large as exchanging all our
input handling code. We can return to our usual, more liberal
co-operation model for these.

> 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.

You are absolutely free to do that. I mentioned previously already that
we have to make up all the SFML tasks in the tracker first anyway, so
until that is done you have of course time to merge everything relevant
into devel.

Valete,
Quintus

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

GnuPG key: F1D8799FBCC8BC4F