~svaksha/+junk/product-release-systers

***************************
 RELEASE MANAGEMENT NOTES
***************************

The contents of this page are available on the wiki at: 
http://systers.org/systers-dev/doku.php/svaksha:release_management_notes

Introduction
=============
Release Management of Systers-mailman project is a complex process which focuses
on the definition, support, and enforcement of processes covering activities in 
the areas of Mailman software development, maintenance and  transfer of software
into production environments with a set of required functionality. Systers-mailman
software is focused and aligned to promote the interests and communication 
(via mailing list discussions) needs of a large community of women in the 
computing and technology fields living in different parts of the world. 
(about_systers_-_gsoc_applicants_read_this_first: 
http://systers.org/systers-dev/doku.php/about_systers_-_gsoc_applicants_read_this_first ). 

Some of the good practices, existing and  essential for making the Software 
Release Management more effective are discussed here. This document reviews 
the existing practices and identifies areas (in the form of suggestions) where 
improvement process can help.  


Product structure:
================== 
Systers runs Mailman 2.1.10 (on Ubuntu 8.04) and has customized this FLOSS software
to include new features like: subscribe/unsubscribe to list threads, adding 
essays during list subscriptions, and the ability to self-add alternate email addresses.
 

Basic structure and Flow of Release Management activities:
==========================================================

The Systers-Dev project team had created the operating environments such as, 
- Development, 
- Version control, 
- QA (review, testing) and 
- Production, 
and had documented the process on the wiki.  



Release Management team: 
========================

Currently this activity is managed by the Systers-project drivers listed on 
Launchpad: 

Name  	          Member since  	       	            Status
Andy Grover 	  2008-10-29 17:49:09 UTC 2008-10-29  	Approved
Jennifer Redman   2008-10-29 17:28:23 UTC 2008-10-29 	Administrator
Kathy Gee 	      2008-10-29 17:52:30 UTC 2008-10-29 	Administrator
Kathy  	          2010-03-18 21:34:08 UTC 2010-03-18 	Approved
Robin J           2008-10-30 16:31:32 UTC 2008-10-30 	Administrator


Release Planning:
=================
The RM team defines the process and procedures for 'Change Management' concerned
with the reporting and resolution of project request, upgrades, bugs and 
wish-list recording for software enhancement and is made effective only with 
Change Control disciplines and registered as bugs only.
(how_to_submit_a_bug_to_the_mailman_project: 
http://systers.org/systers-dev/doku.php/how_to_submit_a_bug_to_the_mailman_project)  

This is triggered by Change incident leading to registering change, authorizing 
a Change, etc... 

The RM team identifies and assigns priority to registered bugs, identifies the 
tasks involved to meet the needs of project requirement, change management, 
testing, release, etc. The team is also responsible to deploy resources needed 
to support Production conditions. Due to the voluntary nature of development 
efforts there is a probability of mismatch between skill needed and what is 
actually available at any point of time, as well as time availability, hence no 
definite schedules with milestone are attempted.

As part of the orientation / training programme several wiki pages are made 
available describing the procedures in the form of what to do and how to do. 
The Systers WIKI-index page lists all available documents:
(http://systers.org/systers-dev/doku.php/soc010?do=index). 

Systers prepares and publishes annual development plans in the form of wish 
lists to infom volunteers about the requirements: 
2010_systers-mailman_development_projects, http://systers.org/systers-dev/doku.php/2010_systers-mailman_development_projects ;
2010_systers-mailman_gsoc_2010_students_projects, http://systers.org/systers-dev/doku.php/2010_systers-mailman_gsoc_2010_students_projects

Suggestions: 
------------
Tentative "suggestions" to facilitate the volunteer development are: creation 
of facility to register the names of volunteers available, their skill sets and 
their preferences for areas of work. This data could be used by the RM team for 
a realistic assessment of resources with skill set and the quantum of work in 
terms of what is to be done, how much manpower effort needed, what skill is 
needed to complete a work unit, and how the gap in resources can be bridged in 
case of mismatch, etc. This is to be done periodically covering  the entire 
scope of work, from development and bug fixing to regression testing and 
deployment. All these can be planned, scheduled and workflow tracked to release 
stage.  


Development: 
=============
Systers uses a distributed development model and uses Launchpad and Bazaar 
Distributed Version Control Systems (DVCS) to coordinate the project and 
documents guiding contributors and students on how to create a local development 
environnment is made available. 

Contributors have their local repositories tied to personal project branches on 
Launchpad that are tied to the Systers-mailman project 
http://systers.org/systers-dev/doku.php/before_you_sprint,
http://systers.org/systers-dev/doku.php/getting_started, 
http://systers.org/systers-dev/doku.php/designing_your_tests_during_development
http://systers.org/systers-dev/doku.php/how_to_merge_development_branch_to_production 

When new features and bugs are fixed, the modified codes (patches) become ready 
for server-side testing. The project branches are merged into the development 
branch for testing (on dev.systers) and can later follow the four pre-release 
stages, namely,: codefreeze, testing, migration, and production. Once tests are 
passed, it is moved into 'stable' for rollout to production. 

The development phase includes the preparation of documents, coding for new 
features, or making patches to fix bugs (http://systers.org/systers-dev/doku.php/bugs) 
in Systers-Mailman. 

System Crash Details from logs are analysed, bugs fixed and patches released to 
production on a priority basis. (about_the_logs, http://systers.org/systers-dev/doku.php/about_the_logs);  
http://systers.org/systers-dev/doku.php/how_stuff_works_both_default_mailman_and_our_changes
http://systers.org/systers-dev/doku.php/mailman_general_architecture
http://systers.org/systers-dev/doku.php/mailman_modified_files
http://systers.org/systers-dev/doku.php/development_server
http://systers.org/systers-dev/doku.php/general_how_stuff_works

All the documents created for and during the RM activities are required to use 
the systers-wiki (running on DokuWiki which is standard compliant 'Wiki') which 
is  mainly aimed at creating documentation of any kind on the web.


 
Software Configuration Management (SCM)
=======================================
At present the development work is focused on release of a single version of 
Systers mailman, hence there is only one  project team that is maintaining a 
single version of production series and another dev-image series in launchpad 
for development and the milestones/timeline details was last updated in Dec 2008.

Systers-mailman uses Bazaar for version/ revision control. Bazaar has a 
decentralized system that  keeps track of changes in software source code or 
similar information, and is linked to Launchpad. Their branches are public and 
are located on Launchpad, which uses bzr as the Distributed Version Control 
Systems (DVCS) and forms the back bone of Systers Release Management disciplines. 

Systers-mailman project is owned by Systers-Dev and maintained as a branch on 
launchpad as 'bzr branch lp:~systers-dev/systers/development' each revision is 
numbered and history is maintained   

Systers-mailman production series   lp:systers  bzr branch lp:systers 73 revisions  
   
Systers-mailman dev-image series


Change Management:
===================
It is the process and procedures for resolving issues, reporting bugs and 
wish-list recording for software enhancement and is made effective only with 
Change Control disciplines. This is triggered by Change incidence leading to 
Problem Management with procedures for registering change, authorizing a Change. 
Change management fixes priority for related activities like submitting bugs to 
a project (http://systers.org/systers-dev/doku.php/how_to_submit_a_bug_to_the_mailman_project). 

Each branch created undergoes the following stages of development before it is 
merged with production.

STATUS
-------
0.Experimental: Still under active development, and not suitable for merging into release branches.
1.Development: Shaping up nicely, but incomplete or untested, and not yet ready for merging or production use.
2.Mature: Completely addresses the issues it is supposed to, tested, and stable enough for merging into other branches.
3.Merged: Successfully merged into its target branch(es). No further development is anticipated.
4.Abandoned: Development activity for the branch has ceased.


Each BUG filed goes through various development stages on LP:
    * New
    * Incomplete
    * Opinion
    * Invalid
    * Won't Fix
    * Confirmed
    * Triaged
    * In Progress
    * Fix Committed
    * Fix Released
 

Quality Assurance (QA) /Testing
=================================
QA process maintains a physical development environment for application of 
patches and testing and covers a set of process for code review and testing. 
This also includes the application of risk assessment techniques  to assess 
pre-production resources and  vetting future technology.
This also involves testing software for functionality, performance, exception
and regression. 

Suggestions:
-------------
It is "suggested" that the review procedures be introduced after impact analysis
of changes due to bugs or new feature requests after completion of coding and testing.

Bugs fixed are tested by testing volunteers and the prepare test cases, test 
suites in the form of checklist as per the guidelines given in the 
master_checklist_template (http://systers.org/systers-dev/doku.php/master_checklist_template). 


Release Execution :
===================
Normally the RM team includes one or more personnel, preferably, with skills in 
Project Management, System analysis and architecture, Coding ,testing, product 
building and operation(s). This activity covers production change control and 
forward schedule of changes, configuration management and focuses on the creation
of dependencies and accountability in the operating environments. Additionally this 
involves the identification and definition of what causes a release, which part 
of the  system is affected and the target audience and expected results.  
Though the release is sourced and driven by the effort of different volunteers, 
it is coordinated and managed well by few dedicated people. 


Suggestions:
------------
It would be a good if Systers also have a back-up plan for production 
releases that are being deployed to manage live environments. This back-up-plan 
should be tested for removing the deployed release and roll back to the old one 
and should be invoked if and when the production system crashes or malfunctions. 

Numbering scheme Change significance  (refer to http://en.wikipedia.org/wiki/Software_versioning)
-------------------------------------
Software versioning is the scheme of assigning unique sequence-based identifiers
to convey the significance of changes between releases: -- changes are classified 
by significance level and the decision of which sequence to change between 
releases is based on the significance of the changes from the previous release, 
whereby the first sequence is changed for the most significant changes, and changes 
to sequences after the first represent changes of decreasing significance. 
(0.0.0 --> release.series.version)