Uploaded image for project: 'Qt Quality Assurance Infrastructure'
  1. Qt Quality Assurance Infrastructure
  2. QTQAINFRA-933

need ChangeLog crowdsourcing platform

    XMLWordPrintable

Details

    • Task
    • Resolution: Won't Do
    • P3: Somewhat important
    • None
    • None
    • Packaging
    • None

    Description

      putting adequate changelogs into our releases proves unreliable over and over again. theoretically, the ultimate responsibility rests with each module maintainer, but that causes an unreasonable load and is thus often neglected. also, we don't even have maintainers for some modules.

      the "theoretical basis of (not) writing changelogs" is outlined in http://lists.qt-project.org/pipermail/development/2013-January/009545.html and the other messages in this thread.

      i agree with jason that the most realistic way to get back to good changelog coverage is making it the responsibility of release management. and missing high-quality logs must block the release.

      however, i think it would be unreasonable to put the entire load of writing the logs on RM. what we need is an online tool for crowdsourcing changelogs, one that does a bit more than the tool that existed in trolltech times:

      • the tool presents a list of commits:
        • only the commit summary is shown at first. the rest of the commit message can be unfolded. additionally, the summary is a hyperlink to the full commit on code.qt.io.
        • each commit has a checkbox to select whether it should be included in the changelog
        • each commit has a text field which contains the text for the changelog. this field would have the syntax of the ChangeLog entries encouraged in https://wiki.qt.io/Commit_Policy
          • it may be possible/advisable to make it more convenient by adding a separate field for labels, with auto-completion (pretty much like in jira). see also QTQAINFRA-1960.
        • obviously, if the commit actually contains a ChangeLog entry, the text field is pre-filled and the checkbox pre-checked
      • when the (non-)changes on a commit are saved, it is marked as handled and hidden from the default listing (next time the list is reloaded. until then, it would be greyed out or something)
      • the tool would automatically split responsibilities by showing each user only commits which touch paths for which they are the most relevant maintainer according to a mapping as described in QTQAINFRA-932.
      • higher-level maintainers (and release managers) could also switch to a view where they see unhandled commits of their "underlings", so they would know whom to nag, or fall back to writing the entries themselves.
      • when everything is done, a button would be pressed which makes the tool emit a proto-changelog, similarly to thiago's current changelog extractor tool
      • final editing and submission into gerrit would be still maintainer/RM responsibility, but at this point it seems like a quite manageable task.

      i googled around a bit, but didn't find an existing tool of that kind.
      the closest hit is kde's http://enzyme-project.org/ - it might be possible to add a different "mode" to it, or fork it.

      Attachments

        Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            People

              janihe Jani Heikkinen
              buddenha Oswald Buddenhagen
              Votes:
              1 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Gerrit Reviews

                  There are no open Gerrit changes