Rich Hypermedia for NB Requirements and Release Process

1
Rich Hypermedia for NB Requirements and Release
Process

• Version 3.3
• Chris Jensen, Susan Hu, Eugene Nistor, Maulik Oza
• UCI Institute for Software Research

2
Funds, support, Promote Java/Open source
Sun Microsystems
Download and use free software
ensure that the netbeans community is being run
in a fair and open manner
Configure and Maintain CVS
Download new release
Start new release phase, propose schedule/plan
make decisions for the community, on high level
Release Manager
The Board
report bugs
Users
Release proposal, Release updates, branch for
current release, release post mortem, review
Release Candidates decide final release
Grant Access
CVS Manager
Mailing Lists
Manage website
Website
Tools
Deploy Builds
download development builds and test, Release
Q-builds
SourceCast
decide features for the project and merge
patches/bug fixes, create module web page
CVS
IssueZilla
Site Administrator
Select feature to develop, bug to fix, download
netbeans, commit code
QA team
Produce Q builds and ensure quality of the
software
Maintain a project/ module, manage a group of
developers
Contribute to community, Meet time constraints
for the release
grant CVS commit privilege to developers
Maintainer
Developers/ Contributors
Link to all Use cases
Links to all Agents
Link to Tools
3
Board member
Release Manager
Module maintainer
Decide future release dates
Start a new release phase (Mailing list)
Determine project features (Mailing list)
Determine main features (Mailing list)
Create module web page (Web site)
Module Web Page
Release proposal
Module plan
Build (CVS scripts)
Roadmap
Schedule
Site administrator
source code
QA Team
Developer
Development build
Final release
Check (Netbeans, Mailing list)
Download links (SourceCast)
Write bug fix (Netbeans)
Test (Netbeans)
Netbeans Web Site
List of bugs to fix
Release candidate 2
Check (Netbeans, Mailing list)
Q build
Use (Netbeans, Issuezilla)
Release information update (SourceCast)
Release candidate 1
Decide which bugs to fix (Issuezilla)
Check (Netbeans, Mailing list)
List of bugs
User
Release Manager
4
Sponsors/Community

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

5
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

6
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

7
Tools

• CVS Repository
• IssueZilla
• SourceCast
• Mailing Lists
• Website

8
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

9
Module Maintainer

• Maintain the project, decide the features
• Manage a group of contributors
• Merge their patches, bug fixes (nightly build)

10
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

11
QA Team

• Test development builds
• Produce Q builds
• This is part of SUN Microsystems

12
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

13
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

14
Users

• Download and use Netbeans
• Report bugs/issues
• Request features/enhancements

15
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

16
Sun Microsystems

• Funds, supports, and promotes Java/Open Source

17
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

18
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 ?

19
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

20
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

21
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

22
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

23
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

24
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

25
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

26
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

27
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

28
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

29
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

30
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

31
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

32
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

33
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

34
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

35
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

36
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

37
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

38
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

39
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

40
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

41
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.

42
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

43
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

44
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

45
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

46
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

47
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

48
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

49
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

50
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

51
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.