General_Development_Process

---

title: General_Development_Process
updated_on: Fri May 11 14:08:59 ~~0400 2012\

\
}
\
h1. General Development Process
\
h2. Sprint
\
h3. Goal
\
The ultimate goal of each sprint is to deliver a batch of **complete**
features.
\
h3. Normal Sprint routine
\
\# Team member claims a feature in redmine. This means they are the
‘lead’ for this feature. Others may claim tasks that are part of this
feature, but should always coordinate with the person who initially
claimed the feature to avoid confusion or overlap.\
\# Team member fleshes out any missing tasks for that feature that must
be completed prior to that feature being acceptable and sets the task to
‘in progress’. Example tasks that are often omitted during planning:\
\#\# cuke/rspec tests\
\#\# documentation\
\#\# preparation of dependent rpms\
\#\# additions to puppet configuration\
\#\# patch review\
\# Team member can work on something on a public branch until complete.
It is the feature lead’s responsibility to ensure that the branch is
fast-forward apply-able to master.\
\# When the code work is complete do any git fetch/rebasing required to
ensure that your patch will apply cleanly to the HEAD of next, then
format-patch & send to the group for review. Set Redmine task to
‘feedback’. In the comment, put the last commit hash before the
patchset, so if the reviewer has trouble applying it, they know where to
fall back to. Patch writer will still need to rebase, but this should
speed up the process a bit, so there is less time wasted resending to
list.\
\# Reviewer ensures\
\#\# Code quality\
\#\# dependencies exist in yum repos on fedora|fedorapeople\
\#\# acceptable test coverage\
\# Upon ACK, the patch should be merged onto the master branch , unless
it is being developed on a public topic branch . Set Redmine task & the
patch review to ‘closed’, add commit hash as a comment. If this is the
last task to complete a feature, the feature should be marked ‘closed’
as well.\
\# The last week of each sprint will be devoted to fixing bugs that have
come up during the sprint and/or outstanding bugs from previous
releases, packaging preparations, and demo preparation.
\
h3. What is ‘done’?
\
A feature is considered done when:\
\* All described aspects of the feature work as expected\
\* The app continues to work from end to end with patchset applied. This
is especially important for any model changes, as they may have
unanticipated side effects on a component that was not intentionally
affected.\
\* It is the responsibility of the feature lead to facilitate the
following, even if they are not the one doing all steps:\
**\* All new dependencies must be packaged as RPMs somewhere, ideally
fedora, our yum repo is a good temporary fallback.\
**\* RPM spec for conductor must be updated to reflect new
dependencies.\
**\* Any changes to puppet or initscripts must be accounted for.

\
h3. Wrap Up
\
Each sprint is a time-boxed release 3 weeks in duration. The following
points apply to what happens at the end of the sprint.
\
** Wednesday:\
**\* Last day of the sprint. Any tasks in progress should be sent to the
list by end of day. If something is not ready by this time, the task or
feature will not make it into the just-ending sprint.\
** Thursday:\
**\* Sprint Review/demo. This is the time to show off what has been
added and bring up any issues with current sprint features that the team
may not be aware of. The goal is to demo an rpm-based installation of
all new features delivered in this sprint. This allows the project
stakeholders to see the progress that has been made and comment on new
features .\
**\* Before and after the call, the entire team should be reviewing
patches on the list and testing the app end to end. Barring major
problems, all patches should be pushed by end of day.\
**\* Project backlog maintenance . They are slightly more flexible than
a typical in-person scrum due to the distributed nature of the team, but
follow the same basic format:\
** What did I do yesterday \
\* What am I doing next?\
\* ]
\
Please include ticket numbers you are working on and set their status
before giving your update in the scrum.
\
h3. Daily Scrum times
\
We currently have 2 time slots. All developers should give a daily
update in the time window for their team. You can get your local time
with `date -d '15:00 UTC'` .
\
\* Conductor : 16:00-16:30 UTC~~ [TZ
Converter](http://timeanddate.com/worldclock/meetingtime.html?month=1&day=5&year=2012&p1=179&p2=43&p3=204&p4=47&p5=152&iv=0)\
\* Infrastructure: 16:30-17:00 UTC - [TZ
Converter](http://timeanddate.com/worldclock/meetingtime.html?month=1&day=5&year=2012&p1=179&p2=43&p3=204&p4=47&p5=152&iv=0)

### Bugzilla States

We tried to simplify the states and were reject by the bugzilla admin

-   NEW (bug opened)
-   ASSIGNED ( the bug has been assigned to a dev)
-   ON\_DEV (optional, bug has been picked up by assigned dev)
-   POST ( dev has submitted fix to
    [[email protected]](mailto:[email protected])
    and is awaiting ACK)
-   MODIFIED ( dev has committed code)
-   ON\_QA ( bug fix is consumable by QE, in a yum repo )

### Bugzilla info

When reporting new bugs, please try to include as much relevant
information pertaining to the bug as you can in the initial report. Logs
and output should be included as attachments to keep the actual comments
as concise and scrollable as possible. The following information is
useful to include (either partially or in their entirety) in a bug
report (if they contain errors and such):

-   aeolus-configure output
-   conductor logs: /var/log/aeolus-conductor/rails.log and
    /var/log/aeolus-conductor/thin.log
-   deltacloud logs: /var/log/deltacloud\*
-   imagefactory logs
-   aeolus-cli output
-   web form parameters
-   aeolus-configure node parameters (if they are able to be shared
    publically)
-   any additional data relevant to replicating the issue