-
Notifications
You must be signed in to change notification settings - Fork 0
Development Process
Information on the Fogcutter development process. Naming conventions, coding standards, source code management, etc.
At this early stage of development, a very lightweight process is in place. At a high level, it's basically this:
Somebody looks over the bug list, or the product backlog and picks a bug or feature they want to work on, or come up with an idea for a new feature or enhancement. At this point the developer in question should clone the Github repository for the project they wish to submit work to, and begin making fixes, committing code to their local repository as they see fit, and pushing to Github as necessary. When a discrete fix/enhancement is in place, a Github "pull request" should be issued against the main repository. If the fix is accepted, the code in question will be merged to the main repository on the relevant branches.
Note: substantial feature enhancements, or bug fixes which require API changes or architectural changes, should be discussed on the fogcutter-dev mailing list, before beginning work. The project developers should ideally reach a consensus on the issues under discussion, at which point it is totally safe to proceed with implementing the fix. If consensus cannot be reached, one or more groups may independently work on different versions of the issue, with a final decision on which (if any) will be merged to the main repository based on an evaluation of the resulting code (this might include performance testing, soliciting user feedback, etc.)
And, of course, in the worst case, a developer may simply choose to maintain a fork of the project as he/she sees fit.
At a more detailed level, we are employing an Agile approach to formalize things slightly. Since you can't really ask volunteers - who may have day jobs or other projects to work on, etc. - to commit to fixed deadlines, we'll do this: Each iteration will be planned, based on the available time of anybody who is willing to commit to specific task for an iteration (may be Fogbeam developers, and/or contributors from the community.) If other code is submitted during the iteration, it will simply be considered a bonus. We'll plan on (probably) 2-3 week long iterations, and we'll iterate as many times as it takes to declare a new release.
As always, the bug database and iteration planning tool will be available to everyone, and major decisions will be discussed in public on the mailing list.
In the leadup to a 1.0 release, we're using a scheme based on the idea of a "Technology Preview Release" or TPR. TPRs will be tagged/branched as necessary, and binary downloads may or may not be made available. A TPR is, in essence, a "pre alpha" release. TPRs may include code that has been lightly (if that) tested, that has major architectural flaws, and for which major API changes may occur from release to release. Once enough TPRs have been released, deployed, experimented with, and the code is deemed suitable, a more formalized system of release versioning will be implemented, follow the standard "Alpha," Beta," "Release Candidate," "GA" scheme.
So, for the near future, look for releases of Fogcutter projects with names like "tpr1," "tpr2," "tpr3" and so forth.