Release Manager Responsibilities

WARNING: This content has been deprecated!

Please browse or search the main wiki for more up-to-date content.

Release Managers are Assigned on a rotating basis to the Hydra Framework components.

Component

Fall '12

Win '13

Spring '13

Hydra-Head

Jessie Keck

Jessie "Jeff" Keck

 

Hydra Tutorial

Chris Beer

Steven Anderson

 

OM

Mike Stroming

Justin Coyne

 

Active-Fedora

Adam Wead

Chris Beer

 

Solrizer / solrizer-fedora

Matt Zumwalt

Naomi Dushay

 

Rubydora

Jeremy Friesen

Jeremy Friesen

 

Jetty Wrapper

Chris Beer

Chris Colvard

 

Hydra-Jetty

Eddie Shin

Carolyn Cole

 

Hydra-LDAP

Mike "Still fine with that" Giarlo

Dan "of the Dans" Coughlin

 

Jenkins

Ben Armintor

Chris Beer

N/A

Web Site (content)

Richard "I don't add snark" Green

Richard Green

 

Web Site (technical support)

Mark Bussey

Mark Bussey

 
Wiki gardener   Richard Green  

Committers Call Housekeeper

Michael Klein

Adam Wead

 

Technical Documentation

Steven Anderson

 

 

Hydra project reporter

Jeremy Friesen

Jeremy Friesen

 

RightsMetadata-policyfinder

Eddie/Ben ?

 

 
CLA manager   Richard Green  

former quarters' release managers

Release Manager Process Notes

Component Release Manager Duties

Version Numbers

We use semantic versioning:

  • Major number bumps for incompatible changes (2.3.1 ==> 3.0.0)
  • Minor number bumps for new features (2.3.1 ==> 2.4.1)
  • Point number bumps for bugfixes (2.3.1 ==> 2.3.2)

NOTE: the version numbers of the different components in the Hydra stack (HydraHead, ActiveFedora, OM, Solrizer ...) are NOT synchronized.

Release Process

When to do a Release

  • to fix a bug
    otherwise, no more often than once a week
  • when a new feature is needed by a non-committer (someone who wouldn't want to pull from trunk)
    bigger releases (e.g. not backwards compatible) should not occur more often than once a quarter.

Responsibilities for Each Component's Release Manager

Barest minimum:

  • participate in Hydra Committers calls
  • ensure pull requests are dealt with in a timely fashion (a few days at most)
    • they must have tests
    • code authors MUST have an iCLA in place (or a cCLA from their institution) before any code is committed on their behalf.  See: CLA submission list.  If no CLA exists, liaise with CLA manager to get one.
  • do releases as indicated.
  • Continuous Integration builds
    • if they break, ensure that they are fixed in a timely fashion
    • get rid of warning messages if possible (e.g. invalid YARD tag)
  • Tests
    • must run cleanly for component
    • full Hydra stack tests must run cleanly.
    • make sure bugs aren't just fixed, they're tested

What we really want:

  • track dependencies and schedules of other components as needed for synchronization
    • This is especially crucial for the HydraHead component manager
  • Tests
    • must meet target percentage for test coverage
  • Responsible for Inclusion/Exclusion of Code Changes
  • Contributions from non-committers must be evaluated in a timely fashion
  • Ensure contributors have CLA on file (contributor license agreement)
  • Code Changes must
    • have test coverage
      • run cleanly for component, and change does not break full Hydra stack tests.
    • have documentation coverage (also yard/rdoc must cleanly compile - see above re API docs)
    • behave correctly
    • have readable code
  • Creating a Release
    • Release Notes
      • must indicate the full release number, the date, and what has changed since the last release.
        • Github tickets and possibly git history are best ways to find this information
      • put into HISTORY.textile which is symlinked to RELEASE_NOTES; both in root directory of component.
    • tag in git?
      • send email to hydra-tech indicating the new release, its number, and what has changed. Send an email once a week (if there is a release that week)
    • for MAJOR and MINOR releases, send an email to the hydra-releases@googlegroups.com list with the release notes.
    • for MAJOR RELEASES, provide details on release to Web Site Manager / Steering Group sufficient to generate a Press Release.
    • for MAJOR RELEASES, document upgrade path
  • Find and train your successor Component Lead
  • Support your successor component lead w/ tying up any loose ends

Web Site Manager Housekeeping Responsibilities

  • overall maintenance of website
    • ensure a steady stream of news
    • provide notification of major software releases
    • maintain up to date information about partners and projects
    • periodically review site for outdated and/or inaccurate content
  • regular patching of WordPress site to latest version (directly, or by liasing with Web site designated technical support)
  • News
    • keep an ear to the ground for information that should become news (steering and partner call, lists, etc)
    • write up and post news (chasing content from individuals where necessary)
    • follow up news if it should become or affect page content
    • try to ensure a steady flow (at least something new each month)
  • Software releases
    • Liaise with colleagues to provide web content around software releases (see above)
  • Partners and projects
    • In collaboration with partners, ensure that all partners and formally announced projects are properly represented on the site
    • Ensure that pages containing information about partners and projects are kept up to date
    • Create new pages for partners and projects as appropriate (chasing individuals for information where necessary)
  • Content
    • add new content when available (posts and pages), maintain menus as required
    • periodically review site for outdated or inaccurate content: liaise, as appropriate, to update, change or delete such
    • notify significant changes to the appropriate Hydra lists
    • regular full exports from WordPress as backup (after any significant change)

Committers Call Housekeeping Responsibilities

  • prepare weekly agenda
    • in wiki: https://wiki.duraspace.org/display/hydra/Notes+from+Meetings+and+Calls
    • send email prior to meeting (preferably on Friday, or at least before Monday morning Pacific time) with weekly agenda inline
    • topics culled from
      • hydra-tech email since last call
      • IRC
      • JIRA
      • any leftover agenda items from previous call
      • any relevant items from other related meetings (hydra partners, combined blacklight/hydra committers calls ...)
    • always included:
      • call for items
      • schedule next call
        • choose next moderator
        • choose next notetaker
        • choose next JIRA wrangler (optional)
      • JIRA roundup for sprint ending on day of call
  • JIRA
    • this is currently done by one Jira groomer for all components.
    • https://jira.duraspace.org/browse/HYDRA
    • BEFORE call:
      • create JIRA version in HYDRA project for next weekly sprint
        • try to maintain an appropriate order for the versions
      • look at previous un-released sprints (before the one ending on day of call)
        • ensure all tickets are resolved and/or closed (you may need to move some or ask people or what-have-you)
        • do a JIRA "release": from manage versions, when you hover over version, on far right is setup wheel - one of the menu items is "release".
    • note that there are JIRA versions for the components and their releases: these are used in addition to the versions for the weekly sprint, and are not part of the Committers Call Housekeeping Responsibilities

tech documentation

  • ensure the documentation for creating a hydra application from scratch is excellent
  • ensure it is easy for folks to find the documentation they seek
  • watch for questions on the hydra-tech list, and ensure the documentation reflects the information desired
  • organized for sane newbie access
  • invite newbies to smoke test installs, provide feedback to enhance docs and process
  • keep track of what upgrade problems people are having and update the upgrade notes with that information