 |
MIFOS Project Home MIFOS Wiki Home
IMPORTANT: Mifos Wiki has moved as of 8/11/2007
The new website for the Mifos Initiative, mifos.org, has been launched.
All Java.net Wiki content has been migrated over to mifos.org
Adding and editing of information should now be done there.
Please create your user account and explore the new site and developer's wiki. Here are the current Developer FAQs
For more info, please see George Conard's recent post to the developer listserv, detailing the move.
Frequently Asked Questions
Getting a build
Contributing to the source code
Code Review
Issue/Bug tracker features
Deployment and configuration
Test environment
Q: How do I get the sourcecode?
A: See InstallMifos.
back
Q: How do I get a build working?
A: See InstallMifos.
back
Q: Who is managing the build process?
A: Cardinal rule is that no one should break the build ("break" means cause any failure in any of the junit tests). If you break the build, you must fix it or back out your changes. Most of what goes on in the build is controlled by build.xml and other checked in files - subject to the same CodeSubmissionProcess as everything else. GFUSA is implementing a build server and will be hosting this. See #CruiseControl.
back
Q: What are all of the various builds?
A: First the developer build (see build tab at http://mifos.sourceforge.net/ ). This is the developer build - pending : having that build post to a working container-mysql site.
The iteration build - or called the iteration release is at http://test.mifos.org:8080/mifos and is meant for testing purposes. Note that data is over-written every two weeks. See InstallMifos for details to access the iteration build.
Each iteration "release" is tagged in svn, and you can find a build of the tagged release in the snapshot folder. The official release build will be made available in the future. For more information, see MifosVersions
back
Q: How do I find out what areas need the most help?
A: Please review the Product RoadMap page, open issues TechnicalTodos and DesiredFeatures. Or, simply ask the listserv.
back
Q: How do I submit patches?
A: Send an email to the listserv prior to starting work, explaining your approach and asking for feedback, then provide the patch via the listserv including tests.
Generally speaking each patch should include jUnit tests for that functionality. Something like a 1:1 ratio is expected for lines of test: lines of code. Highly desireable to also include end-to-end integration test cases, so all exceptions should be discussed on the listserv. see also CodeSubmissionProcess
back
Q: What is the review process?
A: If you can, it can be useful to pair up with a coding buddy, while you write code or afterwards, to ensure that at least one other person has reviewed before submitting. But it is more important to frequently check in with the ListServ or IRC. One good way to do this is to send in small patches every day (or so). That way you get feedback which you can apply when you write the next bit of code.
It can also be good to ask about what you are thinking of doing to see whether people like the idea, what the impacts of a change will be, etc.
back
Q: What is the commit process?
A: Grameen Foundation's Tech Lead manages the commit process. The key thing to understand is what we expect from checkins (chiefly, don't break the build and follow the CodingStandards).
back
Q: How do I use the build server to verify that my code doesn't break the build?
A: Just run the tests on your own machine. The build server should produce the same results.
back
*Q. What role do I need on the java.net site?
Please see the roles and descriptions at http://wiki.java.net/bin/view/Javatools/ProjectRoles. Despite the name, Observer is what we ask that you as a developer request.
Q: What do I need to do code review?
A: Minimally, you only need the ability to access the code and read the code in an editor. Then send emails to the listserv. We use Eclipse IDE, and the settings are checked into the SVN.
back
Q: Do I need to do a build to do code review?
A: No, but most people like to see the runtime before they work on a set of code.
back
Q: How do I propose changes to the data model?
A: We have used DBDesigner4 for the data model. With this tool, we can create a mySQL database from the XML format and roundtrip back to DBDesigner from mySQL. Since there are multiple dependencies on the data model, if you are intending to modify the model to make a feature work better, the best way to make it happen is to also describe how data migration from the old model to the new model would work. See DatabaseStandards for more on database upgrades.
back
Q How do I report a bug?
A: See BugEntryInfo.
Once you are familiar with the process, you can enter a bug in the Issue Tracker. Bugs are automatically assigned based on sub-component so there's no need to assign your bug to a specific developer. If you want to receive email notifications when a bug is entered into the issue tracker, you can send an email to issues-subscribe@mifos.dev.java.net.
back
Q: I have an idea for a feature, should I enter that?
A:Please send an email first to the mifos-functional listserv and then propose the feature in the feature tracker. Emily Tucker will be coordinating these requests.
back
Q: Are there separate issue and bug tracking?
A: No, See Issue Tracker; this will contain bugs and issues.
back
Q: What are the requirements for a deployment server?
A: Our target is a platform neutral build and developers on the list are providing sample.properties files. If you get a build running, please think about providing your properties file used during build. We do not yet have an official set of requirements for a development or deployment platform, however here are some recommendations
- Minimal RAM is 1GB to support the current version of the code in SVN that includes BIRT integration.
- MySQL 4.1, JBOSS - all on one machine is possible. See build options in README.
- All configuration files are in the SVN configuration directories.
- Our target is eventually to run on an in-memory database (e.g. Mayfly) and in a light-weight container (jetty).
back
Q: What are the overall test plans? How are we doing integration testing and stress testing?
A: Please see TestPlan page.
back
Q: Is there an official build somewhere that people can hit so that they can determine if a bug reproduces in the main branch of the code (vs. their own private branch?)
A: Yes, see the question on different builds above.
back
Q: Build server - are the builds generated on the build server posting to a known system somewhere that people can hit?
A: The build results and build stats can be found from the build tab at http://mifos.sourceforge.net/ . The build itself is not being posted to an application/DB server automatically yet.
back
Q: Can we support mixed-mode environments; e.g., can someone working on the front end hit a shared back-end?
A: We don't have any plans for a shared back-end. MySQL 4.1 is fairly straightforward to setup, and a shared back end causes problems with speed, versioning control issues, and tracking down why failures are happening. See also RoadMap.
back
Q: How do you get the system into a known state for bug repros? E.g., if you create accounts and put money into them, how do you roll that back to reproduce things?
A: Developers should expect to be able to test on the interation build and the current developer build. If the error cannot be reproduced, the developer should update locally.
back
Q: What do you need to have installed in order to run test scripts (JUnit? Watir? Etc.)
A: Currently, the team is only using JUnit, so this is the only dependency to run test scripts. In the future, we would like to add Watir scripts back in or Selenium running under Ruby (and at this point, we will call out these new dependencies). This is a project for someone to volunteer for. The junit jar is in the lib/ directory.
back
|