More agile development process

[redhound]

Exploring PlaneShift project pages on the SourceForge, I've personally missed some basic things (after some experience with GitHub), like ability to fill an issue and propose a code change for it - and start thinking...
 
I understand PS have it's own long history, development infrastructure, and there is much more than just client / server code that makes The Game, but... Is there any plans to make the contributing process more simple and development process more open -  make things more "agile"?

To be more specific, I name some things (most are CI-flawored):

1. Switch to SVN to git.
2. Separate repositories for client / server applications, libraries (like Cal3D), game content (restricted?), website, related projects (dev tools, default skins, etc.) - the smaller, the better.
3. Issue tracker, integrated with code repositories.
4. Unit tests, at least for some code parts.
5. Automatic build system for main development platforms (simplifies testing).

It's just outsider's look and I've probably missed The Main Thing, but I'm almost sure what any item from this list, if adopted or implemented, could greatly influence project future.

[verden]

Thats great! Sounds like it will be a great help. How soon do you plan to start?

[redhound]

I'm not a member of development team, verden 

[Eonwind]

Hi redhound, thank you for your ideas

I will try to address the issues you point at:

To be more specific, I name some things (most are CI-flawored):
1. Switch to SVN to git.

Personally I don't see the need to move from SVN to GIT, but I've also noticed when it comes to speak about one or the other some "religious" arguments arises because somebody favours one and someone else the other.

2. Separate repositories for client / server applications, libraries (like Cal3D), game content (restricted?), website, related projects (dev tools, default skins, etc.) - the smaller, the better.

Repositiries for cal3d and CS are separated, about client/server repo separation I personally find it handy to be able to update both of them with a single SVN command, also there are specific jam commands to build only the client or the server so it's not necessary to recompile them both all the time.

3. Issue tracker, integrated with code repositories.

Ok I admit I don't know what you're talking about (but I'm not engine dev at least  ), can you tell me more?

4. Unit tests, at least for some code parts.

These would definitely be handy, but they are not high in our (long) priority list. Is there someone able and willing to code them for us?

5. Automatic build system for main development platforms (simplifies testing).

we have 2 testing environment (servers) one which mirrors the production server and one with nightly builts of the latests code, of course both fulfils different purposes (data testing & setup/code testing).

[redhound]

Thanks for your answers, Eonwind!

1. Well, maybe the only killer feature of git is easy branching - but it is something what will be required in case there will be a plans to accept code contributions directly.

2. Separating client and server repositories may not be primary thing, but with smaller repos it will be easy to delegate their management to various developers / contributors.

About Cal3D and CS - I meant it would be nice to have a forks of them, compatible with current PS version and supported by the PS team (but maybe a cost of maintaining them will be too high?)

3. Under integration issue tracker with core repositories I meant ability to link commits / branches / pull requests with issues directly, and also using tracker to do some project management (set milestones, link issues with them, see what should be done to get to the new release, etc.) It should make development process more transparent.

4. I'd be grad to help, if my ten-years-forgotten C++ coding skills could produce something useful, in testing or other parts. Could you provide a link to that long priority list?..   

5. Do those testing environments and nightly builds are public?

[Serneum]

If I may chime in:
I use Git at work. It is really easy to create branches and I usually create a local branch to handle a bug fix and then tie that back to the main branch I'm working on. It makes it easier to manage small changes and I can switch branches without creating a series of dependent commits. Like Eonwind said, it does come down to a personal preference.

I work in enterprise software and I can say having everything split out into smaller "libraries" is much, much easier to manage, especially when some of the code doesn't need to be changed very often. That being said, I work in Java and we use Ant/Maven to handle dependencies and the building of source, so it's just generally a lot easier. If it's easier to just leave PlaneShift source as it is, that's a fair enough assessment.

An issue tracker integrated with the repositories sounds a lot like Rational Team Concert or even Pivotal. You set up Epics or Milestones and put all of the bugs or work items in their specific milestone or epic. Even better would be adding in Gerrit (if using Git) for Code Reviews. Code gets submitted, someone higher up looks at it and approves or denies it. If it gets approved, it gets merged into the main branch.

Once I finally get everything set up and working, I can help a tiny bit with unit tests. I'm used to Java so I'd have to figure out what C++ uses for it all and learn it.

Would an automated build system be something like Jenkins? I've worked with that and I actually work on a build tool on a daily basis. They're really nice because they compile the code, run tests, upload the reports, and send out notifications if something fails.

[Eonwind]

About Cal3D and CS - I meant it would be nice to have a forks of them, compatible with current PS version and supported by the PS team (but maybe a cost of maintaining them will be too high?)

Nope having forks of CS would not be good at all. We work along the CS team to make sure PS can always compile with latest CS revision. Sometimes it's not possible due to the fact that CS must continue its development process and it may take time to find out where the problems are. Forking CS will only lead to PS unable to use the latest CS features on the long run.

4. I'd be grad to help, if my ten-years-forgotten C++ coding skills could produce something useful, in testing or other parts. Could you provide a link to that long priority list?..

We would be glad to receive any help
Best way to help us is finding us at #planeshift-prospects and asking for a task. Usually the list of short term priorities are discussed by the devs meeting and are for internal use, however you can find a list of features we would like to see added on the long term to the game here: http://planeshift.top-ix.it/pswiki/index.php?title=GSoC_2014.

5. Do those testing environments and nightly builds are public?

No, the testing environment is where we also test new content (quests, rules stuff, spells, etc.) and they're only accessible by who really need to work with them (this may include a few prospects if needed). The nightly builds are maintained by a dev at his place, content is mostly SVN based except a few "experiments".

[Serneum]

About Cal3D and CS - I meant it would be nice to have a forks of them, compatible with current PS version and supported by the PS team (but maybe a cost of maintaining them will be too high?)

Nope having forks of CS would not be good at all. We work along the CS team to make sure PS can always compile with latest CS revision. Sometimes it's not possible due to the fact that CS must continue its development process and it may take time to find out where the problems are. Forking CS will only lead to PS unable to use the latest CS features on the long run.

That's not entirely true. The way a lot of projects work nowadays is they fork a major project, add their own stuff, and then merge in changes from the main repo they forked. It you look at Libre Office, I believe they forked Open Office and merge in any changes Open Office makes. Other projects do the same thing. It would, however, be a lot more work because devs would have to track when CS has new releases and then merge changes in

[Eredin]

Three times I have started to post a reply to this describing our internal processes and movement toward anew agile-like methodology . The replies have been long and detailed and I have gotten pulled away and lost the post. I'll try to put my reply in here in smaller chunks in the next few days.

[redhound]

Thanks anyway, waiting for it

[Eonwind]

That's not entirely true. The way a lot of projects work nowadays is they fork a major project, add their own stuff, and then merge in changes from the main repo they forked. It you look at Libre Office, I believe they forked Open Office and merge in any changes Open Office makes. Other projects do the same thing. It would, however, be a lot more work because devs would have to track when CS has new releases and then merge changes in

May not be true for other projects but it's true for PS. Remember we're a little team and there's no way we can maintain forks of CS, we have PS devs with commit accesses in the CS repository and that's all we need right now.

[Eredin]

The first thing to keep in mind is, as eonwind says, we are a very small team.
I'm one of three active engine devs. Weltall is strictly envolved with builds and releases, and Jilare has very little free time these days. We have two active prospects : Natoka, who is working on a big project for us, but recently was overtaken by RL ( ) and Enio, who has little time for big projects but has done a number of very nice bug fixes for us. We also receive valuable code contributions from Shkirr and Neeno.


The second thing to keep in mind is that there is a long established history, as you say. Let me start with an overview of how the current process works and a little of why. Keep in mind that I have only been with the dev team for about 2 years, so lack most of the knowledge of why things are done the way they are.


• New feature requests come in from players via flyspray, from devs and gm's via flyspray or direct request, and from Talad's direct request in our developer team meetings.
• Requests are prioritized by potential impact to the community and developer preference. Critical fixes get immediate attention whereas feature requests that affect a very small number of players take lowest priority. Note the "developer preference" part, because it's important. It is often the case that a prospect will work for us as long as they like the project. Assign them something they don't like and they may leave. This is sometimes true of full developers as well.
• Features are worked on informal branches of the source code stored on the dev's machine. This works because we typically assign only one dev to a given project at a time.
• Code contributions are accepted from the community.
• All code has to be reviewed and tested by a full dev before it can be checked in. The reason behind this is one that none of us wants to think about, but the reality is that opening the code base would invite malicious code insertion.
• In the past we have collected newly developed features until an agreement is reached within the dev team that now would be a good time to release. Release candidate clients are built and distributed to the dev team who test against the release candidate server in the full test environment. If they seem ok, they are released.
• We build on top of other libraries but do not attempt to take our own forks of them because of manpower and expertise limitations. (ie, I'd rather work on PS than CS, and don't know enough about CS anyway)
  
  
• Jilare has SVN access to the CS project and has worked with them to implement fixes we need

Now a little about our current direction :


• feature requests and bug reports will still be managed as they are at present.
  
  
• A Rapid-development (not truly 'Agile' but borrowing some from it) environment has already been setup that serves both as a second-level dev sandbox and build environment combined:
  
  • provides daily client builds from the latest SVN, currently linux32 & 64 and windows 32. windows 64 and MacOS/X are in work
  • provides daily server and npcclient builds from the latest svn.
  • provides a safe sandbox for the development of scripts and other content (often descructive and involving lots of server restarts), as well as a place to debug the working npcclient and server.
  • tests new functionality with more load and persistence than individual dev-environments.
  [li]Once code, scripts and features are shown to be stable in the Rapid-development environment they will be promoted to the test server in incremental internal releases. There they will be tested against a copy of the prod database.
• When a release is deemed good enough, the latest clients from the Rapid-development server should be easily moved to the update server.
This approach has already proven itself in both development of scripts and quests, as well as detecting and correcting clent crashes due to new code.


Next time I'll address the items above specifically.

[Eredin]

1. Switch to SVN to git.

The biggest question is, given the size of our team, would we get enough benefit to make it worth the time and effort to convert ?

With our current approach each dev/prospect/contributor essentially takes an informal branch to build their local environment then the changes are merged back in manually by the reviewing dev. I'm not sure how formal branching would change things and my experiences with anything other than manual merges have been disastrous.

One final consideration, admittedly minor : we get a lot more project starts than completions. If we did a formal branch for each project we'd have a great many dead branches. I guess that's not really an issue for any source control system. It just feels untidy to me.

2. Separate repositories for client / server applications, libraries (like Cal3D), game content (restricted?), website, related projects (dev tools, default skins, etc.) - the smaller, the better.

Considering the high degree of sharing betweent the client, server and npcserver...how would we accomplish this without creating more work for ourselves?

Something I neglected to mention in my last post is that we do have seperate repositories for art, content, GM console, dev console, and other assets that are not open.

As for the libraries we depend on I think I addressed that in last post, but yes, what eonwind said:

Remember we're a little team and there's no way we can maintain forks of CS, we have PS devs with commit accesses in the CS repository and that's all we need right now.

3. Issue tracker, integrated with code repositories.

This would be very nice. I have begun referring to the flyspray issue number associated with the bug in commit notes. It's a poor substitute. Do you know of anything that integrates with SVN ? Better yet, would you be interested in investigating the possibility of tying our current bug track to our current sourc control system?

4. Unit tests, at least for some code parts.

This could be very helpful in detecting and preventing new bugs as well as driving stability into the code base. It is also an area in which I am very weak. If you would like to help us implement this, please, please, please apply as a prospect. I will be overjoyed to enable your work on it.

5. Automatic build system for main development platforms (simplifies testing).

(addressed in my last post)



So of the 5 issues: agree and already moving on 1, agree and open to help on 2 others, lack resources and recognition of benefits on the final 2. Hey, we agree on 3/5, that's a winning score!

It's not as good as the first writeup I did (and lost) but I think that's a pretty thorough basis for further conversation. Thoughts?

[Rigwyn]

Regarding unit testing, I've done some in java with junit and found that while very useful, you end up writing tests for each and every method/function and the tests are only as good as you make them. Ie. A test might test basic functionality (does it compute for one set of parameters) or the range and scope of the function (does it work for any combination of parameters including zeros nulls max and min values). I'm curious about whether or not there is a better way of doing this in c/c++ or if this is just the price to pay for added assurance.

[Eredin]

I do hope my long posts didn't kill this topic.