Release Coordinating

The Release Coordinator

The release coordinator is elected from any volunteers for the position. Usually there is only one volunteer! Each Release Coordnator will have their own 'style', so it is likely that each release will be coordinated in a slightly different way. Use your own preferred style, following the outline below:

DSpace development

DSpace is a community driven open source project. This means that the requirements for new features are driven by the community, and the actual code developments are contributed by the community. Therefore much of the role of the release coordinator is based around working closely with the community to ensure that requirements are documented, and code is contributed.

What is a Release Coordinator expected to do or not do?

Generally speaking, a Release Coordinator does the following:

• Helps keep code development around a release organized (DSpace JIRA is a great resource for keeping organized)
  • e.g. Ensures each new feature or bug fix has a developer assigned to it
  • e.g. If a developer needs help/feedback, helps locate that help/feedback from the Committers or the Community
• Helps communicate information about the Release to DSpace Community
• Reports on release status updates during DSpace Developer Meetings
• Asks for additional help/support when a release requires it

A Release Coordinator is NOT expected to:

• Make all decisions him/herself (FALSE: The Release Coordinator should use the Committers Group to help make all decisions. But, the Release Coordinator can veto an idea, or ask for a re-vote, if it doesn't seem plausible for the release.)
• Be an expert on every feature in the release (FALSE: The Release Coordinator should just be aware of who the feature experts are, and be able to delegate questions to them as necessary)
• Do everything himself or herself (FALSE: The Release Coordinator should delegate tasks to the Committer's Group or others as necessary. In addition, DuraSpace provides additional support when a Release Coordinator has other work or personal priorities that come up)

Example Tasks

Listed below are example tasks that a Release Coordinator may need to undertake (or delegate to someone else to handle). Some of the tasks the release coordinator may have to undertake are:

• Determine, along with the development community, whether a major or minor release is required. Minor releases include bug fixes and minor, non-db-schema-altering changes; mostly minor releases can be installed by replacing the DSpace code. Major releases include major functional enhancements, configuration changes and db schema alterations.

• Determine, along with the committer group, the requirements for the next release. If it is a minor release, this may be as simple as fixing any bugs that have been reported in JIRA. For a major release, you will likely want to consult the community via surveys, emails, or JIRA voting to determine what features should be included. Final determination is often done in conjunction with the rest of the committers.

• Work with the development community and committer group to find volunteers to develop new features.

• Work with the committer group to find volunteers to take patches, test them, and commit them to SVN.

• Determine a feature freeze date. In a normal release cycle, there will hopefully be a constant influx of patches waiting to be rolled into the relevant release. The feature freeze date, therefore, need not be a long way in advance. It's useful if the date is a Friday, as this allows trailing time-zones to catch up before work in earnest can start on code integration on the Monday.

• Announce to dspace-devel, dspace-tech and dspace-general lists the date of the feature freeze for the coming release, requesting patches and bug fixes

• The job of the release coordinator is not to test all the patches and fix all the bugs, but to help others in doing so. Advise the list of any important events in development and liaise with patch authors to ensure smooth development.

• Once the free date has occurred, hold a Testathon. Encourage the community to take part in the testathon to make the release less buggy. Ask for volunteers to run test instances of the new version to allow people who do not have access to a server to be able to test it.

• Following the testathon, the release may be ready, or it may have significant bugs, in which case bug fixing is required, and another release candidate. Work with the community to find volunteers to fix bugs.

• The release coordinator is responsible for building the release package and uploading it to SourceForge. See Release Procedure for information on how to do this. At the same time as releasing a file the coordinator should also email dspace-devel, dspace-tech and dspace-general to announce the release and add a news item to the SF project page. See other news items for examples of the format of such announcements.

Things to Do at the Start of a Release Cycle

• Review prerequisite software (DBMS, Java, etc.) version requirements with the developer community, and adjust them as required.  Keep the documentation of this up-to-date.
• Review dependency (e.g. log4j) version requirements and adjust as required.  Tools such as mvn dependency:analyze can help.  Also remember non-Java things such as Javascript libraries.  This could be a big job, so ask for volunteers to help.

In general, try to establish a stable up-to-date foundation for development and integration early on.

Tips

• It is never too early to start thinking about the release.
• It is never too early to start talking about the release. People are busy and need reminding.
• Try and create a provisional list of major features as soon as possible, even though it will undoubtedly change throughout the year.
• Engage with the developers and gently push for development and commit timescales. Just talking may help speed the process.
• A commit date for a major feature of one week before the feature freeze is too late, it will inevitably result in a postponement of the feature freeze date. All code needs review and probably rework, developers need to recognise that and plan accordingly.
• Don't be afraid to badger people. It goes with the role and people expect it.
• Don't be afraid to ask for help.