Skip to content
Snippets Groups Projects

Reconsider how we represent releases

    • Open Issue created by Wayne Beaton @wbeaton

    There was a time when the PMI (and the developer portal that proceeded it) were the only source of information about releases. That is no longer the case. In fact, the PMI has basically become a largely redundant source of information about releases that requires committers do extra work with what we might describe as having dubious value.

    Some background...

    In the past, the EDP was such that we needed to have a release review for every release. The PMI was designed with this in mind. It was also the case that releases really weren't generally capture anywhere (at least not in a consistent metadata), so this was the obvious place for them.

    The EDP evolved to a point where release reviews were only required once per year, but still tied to a release. In order to engage in a release, project teams were motivated to create a release record at least once every year. GitHub had a notion of releases, but many (perhaps most) of our projects were still using Gerrit at the time, so there was -- again -- really no consistent means of capturing releases in metadata, leaving the PMI as the obvious place.

    With the introduction of progress reviews, we evolved further. Projects could engage in a progress review (or the EMO could initiate them) and then make as many releases as they needed for a full year. Any "natural" motivation to create release records has disappeared for many of our projects. In the meantime, many projects moved to GitHub and GitLab which both support very natural notions of releases with solid support for metadata. As more projects move off of Gerrit, the value of release records in the PMI becomes more and more dubious.

    We're on the brink of retiring the notion of release reviews in favour of progress reviews. In practice, they're basically the same thing, with the exception that a release review is tightly coupled with a particular release. We do the same sorts of review activities with both a release and progress review and a project team can release as often as they want for a full year after success. The specific value of a release review is questionable.

    TL;DR: release records in the PMI used to provide value to projects, but more natural mechanisms for expressing releases exist today.

    Whether or not we want to show release information in PMI is an open question. If we remove the requirement for project teams to provide us with release information (and potentially retire the release content type), do we have to replace this with anything? Should we, for example, generate an equivalent of the "Latest Releases" section on the Overview page and the "Releases" section on the Governance page?

    There are other places where release information is used, including newsletters produced by the marketing team, the reporting that goes with the simultaneous release, and the generation of SECURITY files (the generator guesses at which releases are supported for vulnerability mitigation).

    There is too much historical information in the PMI to just remove the "Latest Releases" and "Releases" sections which are dependent on the release content type. But, as more and more projects stop using the releases mechanism, these sections will become more and more out-of-date and misleading.

    Perhaps we can supplement these sections with release data harvested from GitLab or GitHub using their respective APIs.

    Designs

      Child items ...

      2. Activity

      Please register or sign in to reply

      Copyright © Eclipse Foundation, Inc. All Rights Reserved.     Privacy Policy | Terms of Use | Copyright Agent