|
4.0 Project Software Development Process (Updated 26-AUG-05)
- Code Development Process
- Builds and Releases
- Sourceforge Repository
- Sourceforge CVS Directories
- Why is there a BSD and a GPL version
- Project Feature Requests
4.1 Code Development Process
At this time, the CMMI level for this project is SW-CMMI Level 1. A
near-term goal at the moment is to reach SW-CMMI level 2. To this goal,
we have begun documenting the development process here which we will be
following (in order to assure repeatability in the process.) Of course,
as an open-source project, we cannot afford a third-party appraisal for
our CMMI level, but at this point we are only providing a self-appraisal
of our progress, which is likely to be more conservative than that of a
third party.
The process for development is currently as follows:
The project will use the release model as a model of operation. Goals,
objectives, and major milestones will be based on this release model. A
release will be defined as code packaged for use at a conference or
event where the code will be used (this will occur roughly twice a year.)
Each cycle of development will occur one-after-another, in order based on
time leading up to a release. The cycle of development will start with
"Lessons Learned", then "Project Features Outline", then "Implementation
and Bugfixes", then "Code Lock/Testing", and then "Release". Once
"Release" phase is reached, then the "Lessons Learned" phase will begin
again.
- Lessons Learned Phase - Developers and implementers will provide
reports about new features needed, changes required to existing software,
and bugfixes. Reports will be submitted to the openinfreno-developers @
lists .dot. sf .dot. net mailing list (and should be cross-posted to the
openinfreno-team @ lists .dot. sf .dot. net mailing list.) The lead
developer will consolidate these reports and write a general lessons
learned white-paper, to be posted to the website, including all inputs
from the developers and implementers. This report should also include
comments and suggestions made by contestants, other users, or the
public in general.
- Project Features Outline Phase - Once the white-paper has been
written and posted to the website, the lead developer will take the
new features, changes, and bugfixes and consolidate them into a single
"todo" list, which will be submitted to the group of developers via the
mailing list. All developers will provide an ordered list by priority
for those "todos", using the categories "Will add/fix in this cycle,"
"May add/fix in this cycle," or "Won't add/fix in this cycle." In
addition, developers should request which additions/fixes they wish to
work on at this time, so that they can be tasked. The lead developer
will take these lists and consolidate them, assigning tasks for each
developer based on their requests or assigning a task to each developer
if no requests have been made for a task which a majority have marked
"Will add/fix in this cycle."
- Implementation and Bugfixes Phase - During this time developers
will tackle, or collaborate to tackle all items on the todo list which
they have been assigned to work on. No new features will be implemented
that have not been listed as part of the "todo" list (they should be
saved for implementation at a later time.) The only exception to that
rule is if all items on the todo list marked "Will add/fix in this cycle"
and "May add/fix in this cycle" have been implemented and all bugfixes
accomplished, and there is significant time between the point and the
code lock to accomplish the new feature coding and the group of
developers agree to the add.
- Code Lock/Testing Phase - At the beginning of this phase, the
code is moved from the /devel/ directory to the /unstable/ directory
(this is the only time such a move is made.) The code is then locked,
and no further features can be added or changes to existing features
made. The only exception is for security bugfixes or code which doesn't
work correctly. All code in the tree is tested, and any major flaws
will be fixed (in the /unstable/ tree, backporting fixes to the /devel/
tree.) Once the code is locked and tested, and all major bugfixes
accomplished, the code will be ready for release.
- Release - The /unstable/ code will be used to implement a public
game. Any flaws related to the game itself which affects the outcome of
the game should be fixed during the game (hopefully this will not occur
as bugs will be worked out in the previous test.) Changes should be
documented thoroughly and immediately for inclusion in the "Lessons
Learned" phase following the game. Immediately after the game, these
changes will be implemented into the /unstable/ branch, with backporting
to the /devel/ branch. Once this is accomplished, the /unstable/ branch
will be copied into the /stable/ branch, and a release tarball created
for the website.
4.2 Builds and Releases
As stated above, the release of release tarballs will only occur during
the end of the "Release" phase. Release numbering will be as follows:
- Major number incrementations (i.e.: 1.0.0, 2.0.0) will only occur when
there is a significant rewrite of all code associated with the game
engine (including agent, agent-server, and scorebot code.) More than
50% of the code will need to change before the major number is
incremented. An example was the move from 1.0.0, which used modified
OpenSSH servers and a server-centric method of obtaining status to 2.0.0,
which went with agent based code.
- Minor number incrementations (i.e.: 2.1.0, 2.2.0) will occur after each
release of the code. Toorcon 2004 was version 2.0, BetaRun 2005 was
version 2.1, and Toorcon 2005 will be version 2.2.
- Series number incrementations (i.e.: 2.1.14, 2.1.15) will occur during
the "Code Lock/Testing" phase, for each code flaw discovered and fixed.
Thus, if there are 6 documented changes to the code during this time,
the version released will be version x.x.7 (the code automatically goes
to version x.x.1 when the code lock occurs, to differentiate it with
in development code.)
- Code in the /devel/ tree in between the previous "Code Lock/Testing"
phase and the current "Code Lock/Testing" phase will be incremented to
the next minor number with a zero serial (i.e.: version 2.1.6 will
become version 2.2.0.) The version does not change during this time
until it is moved to /unstable/ during the "Code Lock/Testing" phase.
4.3 Sourceforge Repository
All development for this project is done using the tools available from
SourceForge. This means that the latest code committed by the developers
is public and available to users. The only exception is code developed
solely for the purposes of implementing the game (code developed as
features for targets, etc.) While this code may be available in the
future, to prevent cheating, target code (except the agent software,) is
not available at this time. This includes special programs developed for
interacting with power systems, simulators, etc.
4.4 Sourceforge CVS Directories
The following directories are used for development of the code.
- devel - Bleeding-Edge Code Directory. This is code that we are
working on at the moment. While the code in this directory will compile,
it may not work in conjunction with the other tools or systems. You'd
be best to stay away from this directory unless you are a developer.
- unstable - Latest release of the code. Everything in this
tree should work together...it is the release candidate for a new
release. We operate our games using this code. If you don't mind using
untested code (it is tested, just not in an operational environment yet,
which is why we use it, the moment it is tested in an operational
environment, it gets moved to stable,) then this is the code to use.
However, most people elect to use stable.
- stable - Mature release of the code. Everything is tested
operationally. It may be older code without the new frills, but it
has been shown to work properly. Most people elect to use this code.
4.5 Why is there a BSD and a GPL Version?
As stated before (in section 2,) this project is DUAL-LICENSED. The code
may be distributed via the GPL license, or the BSD license. This means
that folks can distribute the binaries only, using the BSD license to do
so. However, since the GPL forbids the use of GPL code in a binary only
distribution (without providing the source code when asked,) the code in
the agent-server is split into GPL and BSD versions. If you plan on
distributing the source with binaries, then it doesn't matter what
version of the binaries you distribute (as both versions comply with the
BSD License and GPL.) It is only when you distribute binaries alone
that you could possibly get into serious trouble.
If you are going to distribute the source of derivitives using one of the
licenses listed on the
FLOSS License Exemption page on the mysql website, then you can use
the GPL sections of the code without issue (just as we have here,) so
long as you follow the rules of the exemption.
For the most part, when using the code (and not distributing it outside
of your organization in binary form,) we suggest you use the GPL version,
as the BSD version really doesn't work yet anyway.
4.6 Project Feature Requests
All of the code we have for the toolkit is available for free online.
You can download a .tar.gz file or download directly from CVS (which
is discussed in detail below.)
Occasionally people ask if we can add functionality to the code which
doesn't currently exist. Often, these requests are honored, but
sometimes, the request is too difficult to implement or is not in line
with the wants/wishes of the team. We will take every opertunity to
add functionality that others want, but there are a few things we will
not do, so please don't even ask.
Specifically...
- We will not make the game work like GHI's game. Sorry, they are friends,
we aren't about to compete with them. (See FAQ Section 2).
- We will not implement code that makes it easier for teams to cheat.
|
|