Rich Hypermedia for NB Requirements and Release Process

Version 3.3

CSEM Consulting

ICS 225 – Spring 2002

Sun Microsystems

The Board Release Manager

Maintainer Developers/ Contributors

Website

Mailing Lists

Users

Contribute to community

, Meet time constraints for the release

Maintain a project/ module, manage a group of developers

ensure that the netbeans community is being run in a fair and open manner

Start new release phase, propose schedule/plan

Download and use free software

CVS

Funds, support, Promote Java/Open source

IssueZilla

QA team

Produce Q builds and ensure quality of the software

Release proposal, Release updates,

branch for current release, release post mortem,

review Release Candidates & decide final release

download development builds and test

, Release Q-builds

Download new release

report bugs

Select feature to develop

, bug to fix, download netbeans,

commit code

decide features for the project and merge patches/bug fixes

, create module web page

make decisions for the community, on high level

grant CVS commit privilege to developers

Link to all Use cases Links to all Agents

CVS Manager

Configure and Maintain CVS

Grant Access

Site Administrator

Manage website

Deploy Builds SourceCast

Tools

Link to Tools

Release candidate 2

Release candidate 1

Development build

Q build

Release Manager

source code

Module maintainer

QA Team

Test(Netbeans)

User

Use (Netbeans, Issuezilla)

List of bugs to

fix

Final release

Developer

Write bug fix

(Netbeans)

Check(Netbeans, Mailing list)

Module plan

Roadmap

Decide future release dates

Determine project features

(Mailing list)

Schedule Releaseproposal

Start a new release phase (Mailing list)

Determine main features

(Mailing list)

Build(CVS scripts)

Board member Release Manager

Netbeans Web Site

Create module web page(Web site)

List of bugs

Release information update

(SourceCast)

Check(Netbeans, Mailing list)

Check(Netbeans, Mailing list)

Decide which bugs to fix (Issuezilla)

Site administrator

Download links(SourceCast)

Module Web Page

Sponsors/Community

• Release Manager• Maintainer (Module Leader)• QA Team• Developers (Contributors and Developers)• Users• CVS Manager• Site Administrator• The Board• SUN

Relations (1/2)

• Propose module/feature• Create module web page• Send release proposal• Select feature to develop• Download NetBeans• Create branch for current release• Release RC1• Release RC2• Grant CVS access

Relations (2/2)

• Do Final Release• Release Post Mortem• Commit code in CVS• Release information updates• Report bugs• Select bugs to fix• Test Builds• Release Q Builds• Deploy Builds• Resolve Conflicts

Tools

• CVS Repository

• IssueZilla

• SourceCast

• Mailing Lists

• Website

Release Manager

• Start a new release phase, determine main features/bugs-to-fix

• Track the whole release process for one release, coordinate with project/module maintainers

• Keep all involved people informed about the state of the release

Module Maintainer

• Maintain the project, decide the features

• Manage a group of contributors

• Merge their patches, bug fixes (nightly build)

CVS Manager

• The CVS Manager is responsible for configuring and maintaining the CVS repository

• S/he is also responsible for granting access to developers of a project

• The module leaders request the CVS manager to create authorized accounts

QA Team

• Test development builds

• Produce Q builds

• This is part of SUN Microsystems

Site Administrator

• The webmaster is responsible for maintaining the website of NetBeans

• S/he is also responsible for granting web space for different projects

• S/he is also responsible for deploying the latest builds on the website

Developers

• Contribute patches/code (via email), once the contribution is used/integrated into the project, they become the contributor

• Contributors can directly make changes to the source base of the development branch, from which the nightly builds are made

Users

• Download and use Netbeans

• Report bugs/issues

• Request features/enhancements

The Board

• Has the high-level duty to ensure that the netbeans.org project is being run in a fair and open manner, the last resort

• Decides future release date

Sun Microsystems

• Funds, supports, and promotes Java/Open Source

Propose Module/Feature

• People from the community (module leaders eventually) can propose new ideas/features to be developed

• These ideas have to be implemented in part or can be just a proposal

• User Constraint: – Feature has to be first approved by the community by

sending it to the developer mailing list

• System Constraint:– Should comply with the NetBeans architecture

Create Module Web Page

• The module leader upon approval by the community creates the module web page

• User Constraint:– Content has to be managed by the module

owner

• System Constraint:– Web page allocated by the ?

Send Release Proposal

• The release manager based on the information from module leaders makes a proposal

• Proposal is prepared after consultation with all the module leaders (maintainers)

• The proposal is sent out to the developer mailing list for approval

• User Constraint:– Proposal in the first draft might not be accepted

Select feature to develop

• A developer may select any feature from the module web page to be developed

• The feature to be developed should be based on the constraint from the release proposal

• Feature should be completed before the feature freeze date

• User Constraint:– Features may take longer than estimated time to

develop

Download NetBeans

• The developers download NetBeans nightly builds for fixing bugs

• The user community also downloads the new releases

• User Constraint:– None

• System Constraint:– Nightly builds might not be available for all modules

Create Branch for Current Release

• The release manager is supposed to create a separate branch in the CVS repository for the current release after the feature freeze date

• User Constraint:– None

• System Constraint:– The new CVS branch should be named ReleaseXY

where X.Y is the release

Release RC1

• The Release Manager releases Release Candidate 1

• Release Candidate 1 is chosen after the stabilization phase where most of the known bugs are fixed

• RC1 is selected after the beta of the release has been tested and module leaders identify their module as stable

• System Constraint:– Not all bugs may be identified

Release RC2

• The Release Manager releases Release Candidate 2

• Release Candidate 2 is chosen after the release of RC1 after fixing the bugs identified in RC1

• System Constraint:– All major bugs that have been identified have

to be fixed

Grant CVS Access

• The CVS manager based on the request from the module maintainer grants commit access to CVS for developers

• By granting access it means creating user accounts for the particular users

• User Constraint:– None

• System Constraint:– Account activation might take a day

Do Final Release

• The Release Manager in collaboration with the module leaders decides on the final release

• If no serious issues are found the last release candidate becomes the final release

• System Constraint:– There must be at least a week between the last

release candidate and the final release

Commit Code in CVS

• The developers commit the code of their development into CVS during feature freeze

• The code is committed in the branch for the release

• User Constraint:– Complete the functionality before committing code

• System Constraint:– Branch has to be developed before feature freeze

Release Information Updates

• Release manager updates the mailing lists based on the dates of release

• Conflicts on these are resolved with the module leaders whose projects are part of the release

• User Constraint:– Dates might have to be readjusted for certain purposes

• System Constraint:– None

Release Post Mortem

• The release manager after a particular release is responsible for holding a discussion about the previous release

• Based on the discussion the release manager comes up with what was done well and what was done poorly

• The conclusions should reflect how things could be improved about the next release

• User Constraint:– Feedback from the discussion groups may be limited and

not so straight forward

Report Bugs

• Developers and Users report bugs to the system based on the released version of NetBeans

• Developers generally use the nightly builds• Users use alpha/beta builds and release candidates• User Constraint:

– Not all bugs can be found by the users/developers

• System Constraint:– Bug reporting tool used should be Issuezilla

Select Bugs to Fix

• Developers based on the feedback select the important bugs to be fixed

• The developer downloads the developer builds for this purpose (nightly builds)

• User Constraints:– Identify the important bugs based on priorities defined– Fix bugs depending on the schedule

• System Constraints:– Bug information based on the Issuezilla format

Test Builds• The QA team tests the latest nightly builds every Friday• QA team executes a set of manual tests on the builds as

well as some sanity checks• Test results are categorized as

– Critical bugs (p1)– Visible bugs (p2)– Minor issues (p3)

• User Constraint:– The tests depend on the manual tests specification

• System Constraint:– Not all bugs may be identified

Release Q Builds

• A Q build is a build that assures a certain level of quality

• It is tested by the QA team before release• The latest nightly build tested as of Friday• User Constraint:

– None

• System Constraint:– Q builds should comply to the assured quality level

Deploy Builds• The Site Administrator is responsible for deploying the

current builds on the website for download• The builds can be obtained from the CVS repository• The builds have to be properly classified into categories

like nightly builds, Q-builds, Release candidates and final releases

• User Constraint:– None

• System Constraint:– Builds will be available in the appropriate branch of CVS

repository

Resolve Conflicts

• The board resolves any conflicts that arise in the project

• This might involve issues ranging from release dates to features to be included in a release

• User Constraint:– None

• System Constraint:– None

Grant CVS Access

• The module maintainers are responsible for granting CVS commit access to the developers once they join the module

• The access may be controlled based on the involvement of the individual

• User Constraint:– Consider the important developers of the project from

the other contributors

• System Constraint:– Granting access might take a day for effect

Download and use Free Software

• The user community in general (people developing applications in Java) download the software that is free

• They might get interested in developing the IDE and be the future developers

Ensure Fairness

• The board is concerned with running the community in a fair manner

• This includes resolving any open issues or conflicts that might arise between people in the same sub-module or even different modules

Fund, Support and Promote

• Sun Microsystems is concerned with funding and promoting the project by supplying man power (most of the module leaders)

• It also supports the community by nominating a member to the board to ensure fairness in conflicts resolution

Contribute to Community

• The developer (Developers/Contributors) is concerned about contributing to the open source community

• This might be one of the major goals of the developer to get involved in the project

Maintain Website

• The Site Administrator is concerned with maintaining the website of NetBeans

• This includes tasks such as updating the various news items, links to web pages etc.

Configure and Maintain CVS

• The CVS manager is concerned with maintaining and configuring the CM system

• The CVS manager may be requested by the release manager to create the branch for a release or s/he may decide to do so on his own

Release Planning

• The release manager is concerned with the planning of the next release phase

• This involves getting consensus from various different members of the community

Ensure Quality

• The QA teams’ concerns include ensuring the quality of the software being produced

• This also involves conducting manual tests for releases every week

Manage Project

• The module maintainers are responsible for the timely delivery of the project

• They are also concerned with release issues in fixing bugs, delegating tasks if possible

Meet Time Constraints

• The developers are concerned with meeting the time constraints with respect to the issues they are handling

• The tasks have to be completed before the feature freeze date to be included in a particular release

CVS Repository

• This is the place where the source code is stored

• CVS helps in maintaining different branches for different releases

• It also helps with merging the code of different developers into a single branch

Mailing Lists

• The mailing lists are a medium of communication between the community

• The primary purpose of this is for announcements apart from regular communication

• Mail archive is maintained of all the mail sent to the lists and is indexed

Website

• The website serves as the primary medium of communication apart from email

• The website has several components for different types of users

• Website is indexed and searchable

• All module have their own web page with information on the projects

IssueZilla

• This is the primary means of communicating bugs in the community

• It is useful in keeping tracks of bugs encountered

• It assigns bugs to the appropriate developers and accordingly changes the status of the bug

• Also has a index for searching

SourceCast

• SourceCast is web space for the individual module pages

• It is a product of CollabNet

• It provides powerful tools for version control, issue tracking, discussions and decision making, automated builds, testing, module maintenance etc.