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

Luiji Maryo | Wed, 07 Oct 2015 18:39:35 UTC

Let's see if this works...

Hey all, I was talking with Quintus in IRC and he asked me to put my
thoughts into the mailing list thread.

I'm pretty far on Quintus's side. This is a unique problem that needs
unique handling. The SFML port is major because it changes a huge
number of files. It's a fundamental change between drawing APIs.

However, it is one that can be done systematically, since OpenGL and
SFML code can be intermixed. It's also one that needs coordination,
since two people working on the same code can happen pretty easily and
waste time.

A feature-freeze is also pretty acceptable for the core team, since
the longer the SFML port changes, the longer the core base will
change, and after a certain amount of time we may end up in a place
where the SFML port needs to be redone because the code bases are too
far out of sync.

I would also like to note that the GUI change is likely more minor,
since it effects a smaller part of the code base (though it does still
effect a significant chunk).

I hope I'm all clear. I made sure to reread the thread right before
writing this so I didn't fall off-page, so hopefully I was successful
in that matter.

- Luiji

On Wed, Oct 7, 2015 at 8:16 AM, Quintus <…s@q…> wrote:
>
>
> --
> #!/sbin/quintus
> Blog: http://www.guelkerdev.de
>
> GnuPG key: F1D8799FBCC8BC4F
>
>
> ---------- Forwarded message ----------
> From: Quintus <…s@q…>
> To: …l@l…
> Cc:
> Date: Tue, 06 Oct 2015 18:23:35 +0200
> Subject: Re: [tsc-devel] SFML and further development process
> 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
>
>