Subsections
The ESMF Release Schedule is generated by the Change Review Board (CRB) (see section 2.3)
as the main outcome of its quarterly meetings. The release schedule is posted on the ESMF website home page
under Quick Links.
The Task List
is used
to archive past, current, and future development tasks. It's updated by the Core Team
Manager during and after quarterly CRB meetings. The CRB bases the Release Schedule
on the Task List. The Task List is browsable by anyone and is located at
http://www.sourceforge.net/projects/esmf (click on Tasks).
8.3 Trackers
SourceForge provides the development team with a set of trackers. Current trackers are
Support Requests, Bugs, Feature Requests, Application Issues, and Operations. These are
described in more detail in section ![[*]](crossref.png)
.
An item entered into a tracker is called a ticket. Tickets are assigned a unique
number and can move from tracker to tracker. Tickets may be opened in response to a customer
request or as a result of some finding or need of the development team.
The process for handling customer requests is located in Section .
All trackers categorize requests similarly. Pull down menus can assign various criteria
including Assignee, Status (Open, Closed, etc.), Category (Array, Regrid, etc.), and Group
(Bug, Feature Request, etc.) Tickets can be sorted and viewed based on these criteria and
can be moved from one tracker to another. For example a ticket may start out as a support
request and be moved to the bug tracker for resolution. To move a ticket, simply change
the type using the type pull down menu.
The SourceForge trackers allow the user to set the priority of a ticket. Priority nine is used
to label tickets that are associated with a task scheduled for release on the Task List.
These are the only tickets that should be labeled at this level. Priority levels one through
five can be used by individual developers to prioritize tickets that are not associated with
any upcoming release.
8.3.2 Labeling Tickets Longer than 2 Weeks
The CRB only manages tickets that will take longer than two calendar weeks.
All tickets that are estimated to be two calendar weeks or longer should
be labeled with LONG: prepended to the title of the ticket.
Examples:
- LONG: wants one-sided communications options (2)
- LONG: typekind vs type and kind (4)
The following guidelines should be used when determining ticket completion times:
- Estimates are in calendar weeks.
- Estimates do not include the 25% time spent on support. Thus
time for ticket items is allocated at 3 weeks per month.
- Estimates do not include integration and release preparation.
- Estimates do include any research time that's part of the developer's position. Calendar weeks are not corrected for this.
- Estimates include design time.
- Design estimates do include looking at other packages, design, design documentation, time for iterating on telecoms, design reviews, feedback, and prototyping.
- Implementation estimates do include implementation, code reviews, testing, and documentation. As a rule of thumb, documentation time and testing time are at least equal to coding time. Also include any peripheral capabilities that will be needed to support the main item.
- Use the past as a guide and estimate long.
An estimated time to completion should be placed at the end of any ticket title labeled with
the LONG: key. If the time includes a design phase, this should be included in the
total estimate e.g. (7) equals 3 weeks design plus 4 additional weeks for completion.
The tasks in the Task List are usually associated with
one or more items in the Feature Request, Bug, and Support Request
trackers. In order to cross-reference items, developers should label
both the item on the Task List and tracker tickets with a
unique key. The key should describe the task, be unique, and be followed by a
colon. Careful placement of keys will allow the CRB to quickly visualize
through the search mechanism all tasks necessary for a new release. The key
is highlighted in the example below:
There are multiple steps to properly identifying tickets. The preceding sections
cover these steps, which are summarized here:
- Use key words to link tracker tickets with items in the Task List
- Label all tickets with LONG: that will take longer than two calendar weeks
- Put the completion time estimate after the title (DESIGN + COMPLETION)
- Label tickets scheduled for release on the Task List with a priority nine.
- Prioritize other tickets using levels one through five.
In Task List: STDIZE_INIT: Standardize Initialization Behavior
In Bug Tracker:
- LONG:STDIZE_INIT:Std hand. of Verify rc for declared obj (4)
- LONG:STDIZE_INIT:Field count from uninitialized FieldBundle(4)
- STDIZE_INIT:Fld ct on uninit Bndle is not 0 on nag (4)
- LONG:STDIZE_INIT:BndleGetFildNmes crashes if Bndle uninit(4)
8.3.7 Types of Trackers
- Support Requests: Support requests are monitored on the Support Request tracker on SourceForge.
(See Support Requests Tracker).
- Bugs: Bugs are tracked using the Bug Tracker. Bugs are issues with capabilities that already exist e.g. optimization, documentation, and tests. Bugs can be of short or long duration.
Bugs may be identified independently, or they may originate as a support request. If the bug originated independently, the Integrator will create the initial entry. If it originated as a support request, then the Handler or Advocate (see section 2.1.1 for definitions) will transfer the support request to the bug tracker. When a bug is opened, provide as much detail as possible to help the Handler reproduce the problem. Indicate where the bug was found e.g. trunk, branch, or both. A bug that exists on both the trunk and a branch will generally be fixed only on the trunk. If the bug is fixed on both the trunk and branch, the ticket must state this explicitly. When the bug is fixed, the Handler adds a note to the ticket and changes the status to Pending. Once the customer who originated the bug or initial support request has confirmed the fix, the ticket can be closed.
- Feature Requests: Features are various requests that involve creating new functionality. Features are tracked using the
Feature Requests Tracker
- Applications Issues: The Applications Issues tracker exists to segregate tickets that
involve ESMF code that is embedded in third-party applications and which it is believed the problem
lies with the application and not ESMF. This category includes issues with ESMF code that
has been modified by a third party, code that has ESMF interface names but was not developed by
the Core Team, and and implementation issues with the Application itself. This segregation is
necessary because such tickets can remain open for extended periods of time, which would have
a negative impact on our support metrics. This tracker is located at
Applications Issues Tracker
- Operations: Current infrastructure related items are recorded using the
Operations Tracker
The Integrator is responsible for tracking various aspects of the
ESMF project to measure the implementation and testing progress.
Throughout the ESMF software development process, the software is constantly
being unit and system tested. It is essential to know the percentage of the
code that has been fully or partially tested. A script has been written that
lists all the public interface subprograms (functions and subroutines) and
determines which of these have been unit and/or system tested. From this script
output, the tested percentage can be calculated.
An Excel spreadsheet is maintained listing the requirements as described in the
ESMF Requirements Document. A hard copy of the spreadsheet has been posted in a
convenient place for the core team. Using color coding the core team indicates
which requirements have been implemented and of these which have been tested.
The ESMF SLOC information is provided in an internal ESMF web page. The
SLOC data is presented in graph form with the following columns:
- Fortran
-
- C++
-
- c
-
- Makefiles
-
- SLOC Total
-
- Lines of text
-
The graphs are a monthly breakdown from January 1, 2002 to the present.
esmf_support@ucar.edu
