• Welcome to Final Fantasy Hacktics. Please login or sign up.
 
March 28, 2024, 04:05:59 am

News:

Don't be hasty to start your own mod; all our FFT modding projects are greatly understaffed! Find out how you can help in the Recruitment section or our Discord!


Move to Git?

Started by Pickle Girl Fanboy, February 15, 2012, 04:49:37 pm

Pickle Girl Fanboy

Should the FFTPatcher source code be moved from SVN to Git, or should it remain SVN?  And should the source code for all the different FFT editing tools be at the same place?

What made me think of this:
http://board.byuu.org/viewtopic.php?f=8&t=2119&start=75
I think the lack of co-development has several reasons that can all be fixed if co-development is a true goal.

TL;DR

1. This project is set-up like a single player game, other developers are like the guy sitting next to you screaming "press jump!"
2. Besides the self-documenting code there is very little documentation on the how and why of this project
3. The emulation scene has a bad name in general and bsnes and byuu specifically in some scenes, it doesn't help that one of the projects main goals, rom hacking, has a community where byuu is banned (afaik)

Now in more detail.

1.
For a project to see collaboration from multiple developers it has to be set up in a way that naturally attracts them and keeps them happy once attracted.
Here are 2 videos on how to run projects specifically with collaboration and quality in mind and a book written on the subject by an industry expert:

http://www.youtube.com/watch?v=ARtkLcVx ... yL9_BY_KTh

http://www.youtube.com/watch?v=mpLHm5sS ... Kcq76lu8iR

http://producingoss.com/

2.
The above links explain how important documentation is, but i want to make one point explicit.
In my experience the philosophy and coding style behind bsnes is fairly unique in general, not just in the emulation scene.
I would love to read an essay on this philosophy aimed at programmers and a simplified version aimed at the general public.
Note: this would not be about the accuracy part per-se but more about the how and why of bsnes in general, like the before mentioned importance of audio and video sync
This document could potentially be a good way to reach out to the community and attract new developers and end users

3.
By doing all the things mentioned in the links the image bsnes and byuu resonate can change considerably. What i do know for sure is that rom-hackers are probably the main source of new users and developers so some kind of out-reach program would have to be thought up.


P.S. I don't assume or even think its a good idea for byuu to do this all on his own, its probably best if someone he can trust joins the project as a kind of project manager, e.g. someone who does nothing or very little with the code itself but makes sure the whole infrastructure keeps running, outreach programs are put into effect and new develpers are given a warm welcome. Also some else yet again needs to handle the first line filtering of bug reports so only real emulation bugs get pointed out to developers.
Also a continually updated wiki with things like a bugs that are not bugs lists etc.. will help a lot.

tl;dr Git is awesomesauce and tarballs and patches are so old school

I think the biggest reason with "lack of co-developers" is that bSNES has no official repository of any kind, closest thing being Screwtape's mirror Git repo, but it's still one commit per release. This makes it very hard for any aspring developer to hope contributing except minor bug fixes here and there. It's hard to encourage co-developers when they are not given a friendly environment.

This is all about development style ofc. Having a public repository means everyone can see every little commit. Some authors would probably be afraid of this, as their "humanity" would be more exposed, dunno. This also means others can more clearly see the authors intent. Seeing a big +5000/-5000 diff every month of something is not helpful for understanding what's going on in a project.

Now, you have two kinds of repositories: SVN/CVS-style and Git/Mercurial-style.
I would argue that SVN/CVS is a pretty bad idea.

First, using these would mean a central repository.
This leaves the question: Who has repo write access? (politics?! gaaaaaaah)

You'd be extremely careful about who you'd ever let into your repo like that, naturally, and the whole point is gone.
Other developers can't write to the central repo, so their work is not mergable at all, and not even commitable either! It's tarballs/patches all over again, very lame.
You'd be a second-class citizen. Noone likes being that. I certainly hate it, and committing anything other than one-liners to such a project is a huge pain.

Now the model that does work arguably better is a distributed model like Git/Mercurial. In this model, a repo is just a repo. There is no "central" one. Just by convention is it so.
This means developers can work on their own copy of the main repo. Commit their work to it locally, with full support of tools. While working on a new feature X, you can pull down from master's new commits to keep up to date with a simple git/hg pull to make sure stuff does not break. The developer can do great stuff or stupid stuff. Doesn't matter. The master repo doesn't have to know or care at all.

If the other developer feels happy about his changes, he can issue a pull request to master, telling "hey, look at this stuff, wouldn't this feature be nice?". Masters response to this would usually be:
- "I don't want that feature because blah/foo/politics" (do this often enough, and noone will ever want to work on the project. why make it public to begin with?)
- "Nice! However, you should probably fix x and y to match better with code style/guidelines, blah" (great. Most developers gladly do this, as they feel recognized. I certainly do at least.)
- "Great, looks good, I'll merge it" (Hopefully after #2 and a new pull request.)

No need to give write access. Pull in on per-request basis. This is great, and probably the reason why several projects have moved from archaic SVN to Git lately.

This pull/request cycle is obviously made trivial by hosting sites such as GitHub, Gitorious, etc. These sites also have decent issue trackers built in, yay for that.

Glain

Well... honestly, right now, we don't have a repository. I don't intend on ever modifying melonhead's. Doesn't seem right.

We might be able to take our (modified) code and put it in another repository, but so far, I don't know if anyone has expressed interest in actually editing FFTP except me.

The FFTP suite basically already has everything in the same place (same solution, even), including Patcher, ASM, Tactext, and Shishi. Not sure what else you could really put in there.
  • Modding version: Other/Unknown