html5-img
1 / 51

Rich Hypermedia for NB Requirements and Release Process

Rich Hypermedia for NB Requirements and Release Process. Version 3.3 Chris Jensen, Susan Hu, Eugene Nistor, Maulik Oza UCI Institute for Software Research. Funds, support, Promote Java/Open source. Sun Microsystems. Download and use free software.

kelvin
Download Presentation

Rich Hypermedia for NB Requirements and Release Process

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 make decisions for the community, on high level Start new release phase, propose schedule/plan 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 Link to Tools Links to all Agents

  3. Board member Release Manager Module maintainer Decide future release dates Start a new release phase (Mailing list) Determine main features (Mailing list) Determine project 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 Final release Development build Download links (SourceCast) Check (Netbeans, Mailing list) 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

More Related