Role 1: Update packaging progress tracker page

  1. Edit version in software.yml at https://gitlab.com/debian-ruby/gemdeps-generator. After committing the change, wait for the pipeline to finish (See https://gitlab.com/debian-ruby/gemdeps-generator/pipelines). The CI pipeline will generate a tracker page at http://debian.fosscommunity.in/.

  2. Use Get ToDO list button of tracker to generate markdown formatted tracker, for example http://debian.fosscommunity.in/status/gitlab-v11.5.0/?type=todo will give a markdown version of gitlab 11.5.0

  3. Create a new issue like https://git.fosscommunity.in/debian-ruby/TaskTracker/issues/100 using the output from from previous step. Mention all members of debian-ruby team (@all), so everyone gets notified. Copy notes from previous version's tracker, if any. Note: For gitlab, we will also need to check these files GITALY_SERVER_VERSION, GITLAB_SHELL_VERSION, GITLAB_PAGES_VERSION, GITLAB_WORKHORSE_VERSION in the source tree and update packages.

Role 2: Update rubygem dependencies

  1. Find if unpackaged dependencies are added in the new version (compare Gemfile of both versions) or use tracker at http://debian.fosscommunity.in/ For example, https://gitlab.com/gitlab-org/gitlab-ce/compare/v11.4.9...v11.5.3 has all the changes between gitlab 11.4.9 and 11.5.3 versions, search Gemfile to see the changes in Gemfile.

  2. Optional: Package any new gems and add them to a staging repo until they clear NEW queue. Use reprepro package to create the repo. Use people.debian.org, or any personal site to host the repo.
  3. For stable libraries (?SemVer defines stable libraries as version >= 1.0), upload minor and patch updates to unstable directly (skip experimental) as previous version's Gemfile is already relaxed to allow newer minor versions. Check reverse dependencies are not broken when updating. Check the gemspec files of reverse dependencies for their exact requirement. Use build-and-upload script from https://salsa.debian.org/ruby-team/meta repo to automate this.

  4. For major updates of stable libraries and minor update of development libraries (?SemVer defines version << 1 as development), use experimental as staging repo and upload all reverse dependencies to unstable together in a transition.

Role 3: Update the rails app

  1. Optional: Import the new upstream to a new branch (if the current version is still in experimental or if you think the update can take a long time to complete and you want to keep the previous version updated for bug fixes) and add package to staging repo. Note: Check debian/gbp.conf for any components listed, you will need devscripts >= 2.19.7~ for components support and some component tarballs may need to be manually created if uscan cannot download them automatically.

  2. Refresh patches to match versions in the archive. Relax stable libraries (>= 1.x) and be careful with development libraries (0.x). Update debian/control with stricter dependency for dependency update (it will help in backporting).

    1. Refresh patches that is needed for build (Gemfile changes/quilt push fails)
    2. Refresh patches for bundle install --local (install the newly built package to find out)
  3. Once new dependencies clear NEW queue, upload new package with dependencies to experimental. If the new version is a security release, embed the new dependencies to avoid waiting for clearing NEW queue. Remove the embedded copies when they clear NEW. You may also embed in case of transitions (for example rails).
  4. Move to unstable with dependencies only in experimental (always use experimental, never directly upload to unstable) after testing the new version in experimental.

Role 4: Keep dependencies in sync

If we have to update any dependency in debian first, go through the below steps to get it updated upstream as well.

  1. Fork the upstream.
  2. Clone your fork.
  3. Checkout another branch from master (make sure you pull the changes to master (if and when required) before).
  4. Before doing the changes, compare the changes in new upstream gem (that is, their g/h or g/l repo). And see if there's anything major or not.
  5. If not, simply bump the version in GitLab's Gemfile and run bundle update <gem_name>. Then do the same for qa/Gemfile and run bundle update <gem_name> inside the qa directory (note: it is not necessary to always find the gem in qa/Gemfile; also you'll need to check and make changes manually in qa/Gemfile.lock when you cannot find the gem to be bumped in qa/Gemfile but is present in qa/Gemfile.lock).

  6. If there's a major change and you can find the code to change, do that. Else leave that and raise a MR. But do give a link of the diff (gem's upstream) in the MR description.
  7. When the MR is created, it usually takes 40 minutes to complete the CI (if all goes well), if it doesn't, you can check the CI logs and try fixing (if you can). Otherwise, someone will tell you to do that anyway.