Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-13312

confusing xtradb related items in the 10.2 changelog

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 10.2(EOL)
    • 10.2.8
    • Documentation
    • None

    Description

      The way git works and our changelog are generated, xtradb related commits from 10.1 end up in the 10.2 changelog. It's confusing.

      It'd be good not to have xtradb related items in the 10.2 changelog.

      Attachments

        Activity

          What if I filter out the latest MariaDB 10.1 release tag when I generate the changelog (e.g. with ^mariadb-10.1.25)? It will filter out more than just xtradb-related commits, but everything it filters out is already available in the 10.1 changelog.

          dbart Daniel Bartholomew added a comment - What if I filter out the latest MariaDB 10.1 release tag when I generate the changelog (e.g. with ^mariadb-10.1.25)? It will filter out more than just xtradb-related commits, but everything it filters out is already available in the 10.1 changelog.

          I think you used to collapse merge commits into one "merge from ..." without listing every merged commit individually. Am I wrong? Or did you do that and then stopped for some reason?

          serg Sergei Golubchik added a comment - I think you used to collapse merge commits into one "merge from ..." without listing every merged commit individually. Am I wrong? Or did you do that and then stopped for some reason?

          I think I experimented a while back with collapsing merges like you say, but IIRC the changelog was then missing important commits that were made in, e.g. feature and bug-fix branches.

          My current practice is to style the actual merge commit differently, but I do include the commits that come along with the merge because the merge commits usually only say unhelpful things like "Merge 10.1 into 10.2" which doesn't particularly describe what is included in the merge. If a merge commit summary is especially helpful it will say something like "Merge pull request #397 from MariaDB/bb-10.2-MDEV-12067", but even then you can't tell at a glance what the merge was about.

          That said, if I exclude the latest MariaDB 10.1 release from 10.2 release changelogs then 10.2 changelogs have a bunch of "Merge 10.1 into 10.2" commits with no indication of what was included, but at least in this case we do have the 10.1 changelogs that people can refer to if they're interested, and I could make it standard practice to always add a link to the latest MariaDB 10.1 changelog somewhere on a given 10.2 changelog page (maybe wherever there is a "Merge 10.1 into 10.2" commit).

          dbart Daniel Bartholomew added a comment - I think I experimented a while back with collapsing merges like you say, but IIRC the changelog was then missing important commits that were made in, e.g. feature and bug-fix branches. My current practice is to style the actual merge commit differently, but I do include the commits that come along with the merge because the merge commits usually only say unhelpful things like "Merge 10.1 into 10.2" which doesn't particularly describe what is included in the merge. If a merge commit summary is especially helpful it will say something like "Merge pull request #397 from MariaDB/bb-10.2- MDEV-12067 ", but even then you can't tell at a glance what the merge was about. That said, if I exclude the latest MariaDB 10.1 release from 10.2 release changelogs then 10.2 changelogs have a bunch of "Merge 10.1 into 10.2" commits with no indication of what was included, but at least in this case we do have the 10.1 changelogs that people can refer to if they're interested, and I could make it standard practice to always add a link to the latest MariaDB 10.1 changelog somewhere on a given 10.2 changelog page (maybe wherever there is a "Merge 10.1 into 10.2" commit).

          I see, feature and bug-fix branches, indeed.

          Agree, then, excluding the latest 10.1 release tag should mostly do it.

          Perhaps it should be done consistently for all versions? exclude 10.0 for 10.1, 5.5 for 10.0, etc?

          serg Sergei Golubchik added a comment - I see, feature and bug-fix branches, indeed. Agree, then, excluding the latest 10.1 release tag should mostly do it. Perhaps it should be done consistently for all versions? exclude 10.0 for 10.1, 5.5 for 10.0, etc?

          Yes, doing it consistently makes the most sense. I'll do that going forward.

          dbart Daniel Bartholomew added a comment - Yes, doing it consistently makes the most sense. I'll do that going forward.

          my changelog creation process has been updated, so closing

          dbart Daniel Bartholomew added a comment - my changelog creation process has been updated, so closing

          People

            dbart Daniel Bartholomew
            serg Sergei Golubchik
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.