1. Rich Hypermedia for NB Requirements and Release Process Version 3.3 CSEM Consulting ICS 225 – Spring 2002

2. Sun Microsystems The Board Release Manager MaintainerDevelopers/ 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 proposalRelease proposal, Release updates, branch for current release, release post mortem, review Release Candidates & decide final releaseRelease updatesbranch for current releaserelease post mortemreview Release Candidates decide final release download development builds and testdownload development builds and test, Release Q- builds Release Q- builds Download new release report bugs Select feature to developSelect feature to develop, bug to fix, download netbeans, commit codebug to fix download netbeans commit code decide features for the project and merge patches/bug fixesdecide features for the project and merge patches/bug fixes, create module web pagecreate module web page make decisions for the community, on high level grant CVS commit privilege to developers Link to all Use casesLinks to all Agents CVS Manager Configur e and Maintain CVS Grant Access Site Administrator Manage website Deploy Builds SourceCast Tools Link to Tools

3. 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 Release proposal Start a new release phase (Mailing list) Determine main features (Mailing list) Build (CVS scripts) Board memberRelease 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

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.