Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #65444 > unrolled thread

Merge request friendly handling of debian/changelog

Back to article view | Back to linux.debian.kernel

Contents

  Merge request friendly handling of debian/changelog Bastian Blank <waldi@debian.org> - 2019-10-22 05:10 +0200
    Re: Merge request friendly handling of debian/changelog Joseph Herlant <aerostitch@debian.org> - 2019-10-22 06:10 +0200
    Re: Merge request friendly handling of debian/changelog Sam Hartman <hartmans@debian.org> - 2019-10-22 13:40 +0200
      Re: Merge request friendly handling of debian/changelog gregor herrmann <gregoa@debian.org> - 2019-10-22 14:00 +0200
      Re: Merge request friendly handling of debian/changelog Guido Günther <agx@sigxcpu.org> - 2019-10-25 21:00 +0200
    Re: Merge request friendly handling of debian/changelog Jeremy Bicha <jbicha@debian.org> - 2019-10-22 20:40 +0200
    Re: Merge request friendly handling of debian/changelog Simon Richter <sjr@debian.org> - 2019-10-23 14:40 +0200

#65444 — Merge request friendly handling of debian/changelog

Moin

In Debian most people prefer to have changelog entries with all changes,
so changes always contain a modification to debian/changelog.

If we also start to use merge requests on Salsa, all those changes will
contain modifications to debian/changelog, which will usualy conflict
with each other.  Or worse, are applied to an old changelog entry.  This
for example happens on the linux packaging project.

I don't think we already have a way to get around this?  Do we need
some?

There is "gbp dch", which ignores merge commits (so no really good for
merge requests), but I don't consider it to have enough control over the
content of the changelog.

The way that for example GitLab chooses in many locations is to create
split files and merge them together in the final release process.  They
now not only use that for the core software changelog[1], but also for
stuff like release posts.

So one rough idea could be:
- "dch $message" writes a dummy entry to debian/changelog if it does not
  exist and the entry to debian/changelog-unreleased/$hash.
- "dch --release" collects the snippets and creates one large entry.

Regards,
Bastian

[1]: https://docs.gitlab.com/ee/development/changelog.html
-- 
One does not thank logic.
		-- Sarek, "Journey to Babel", stardate 3842.4

[toc] | [next] | [standalone]

#65445

Hi Bastian,

Full disclaimer: I probably don't contribute often enough inside
Debian to be a reference on it but thinking about it I'm wondering if
it wouldn't be easier to do it another way.

On Mon, Oct 21, 2019 at 8:06 PM Bastian Blank <waldi@debian.org> wrote:
> There is "gbp dch", which ignores merge commits (so no really good for
> merge requests), but I don't consider it to have enough control over the
> content of the changelog.

I honestly generally only use gbp dch (and I reformat sometimes its
output to make it prettier).
2 reasons for that:
* it avoids conflicts when you have several MR
* it also forces me to have more relevant commit messages. Most of the
time the changelog entry I've seen in the MR is the same as the commit
message anyway so gbp dch would generate the same output, you're just
doing extra work which is already automated inside gbp dch

On another point, it would be really nice if we could have a way to
squash merge requests to avoid having the merge commit every time
cluttering the git history. I know that github has it, which lets you
rework the final commit message if you feel like it's necessary and
that allows you, as a contributor to not have to squash and force push
after each feedback for example (that also adds the MR number
automatically which is nice). I'm pretty sure there's a way to do it
in gitlab I just haven't seen it available yet in salsa.

> The way that for example GitLab chooses in many locations is to create
> split files and merge them together in the final release process.  They
> now not only use that for the core software changelog[1], but also for
> stuff like release posts.

It looks like the same idea as the reno software that openstack uses:
https://github.com/openstack/reno
But doesn't it clutter a bit your tree for things that you're going to
get in your changelog anyway in the end?

> So one rough idea could be:
> - "dch $message" writes a dummy entry to debian/changelog if it does not
>   exist and the entry to debian/changelog-unreleased/$hash.
> - "dch --release" collects the snippets and creates one large entry.

Other though, could we instead not populate the changelog inside the
MR but have a script that takes a MR as input and merges the MR using
the title of the MR as short description and description of the MR as
long description? (yes it is kind of what a merge squash does on
github)
And then use gbp dch to take care of actually updating the changelog
when the release is actually ready?

Thanks,
Joseph

[toc] | [prev] | [next] | [standalone]

#65447

I agree that better handling of things like debian/changelog is
something we should focus effort on.

I think we can either  do something gbp dch like, possibly allowing
commits to annotate whether and to what extent they should be included
in changelog.

Or  some code that knows how to merge changelogs

Or some file based approach like you discuss.

I think exploring options like these and getting experience would be
great for Debian.

[toc] | [prev] | [next] | [standalone]

#65448

[Multipart message — attachments visible in raw view] — view raw

On Tue, 22 Oct 2019 07:35:55 -0400, Sam Hartman wrote:

> Or  some code that knows how to merge changelogs

dpkg-mergechangelogs(1) is a nice helper for some of the merge
situations.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   

[toc] | [prev] | [next] | [standalone]

#65507

Hi,
On Tue, Oct 22, 2019 at 07:35:55AM -0400, Sam Hartman wrote:
> I agree that better handling of things like debian/changelog is
> something we should focus effort on.
> 
> I think we can either  do something gbp dch like, possibly allowing
> commits to annotate whether and to what extent they should be included
> in changelog.

gbp dch has flags for that can be part of the commit message:

  Gbp-Dch: Ignore

and

  Gbp-Dch: Short

Cheers,
 -- Guido

> 
> Or  some code that knows how to merge changelogs
> 
> Or some file based approach like you discuss.
> 
> I think exploring options like these and getting experience would be
> great for Debian.
> 

[toc] | [prev] | [next] | [standalone]

#65454

On Mon, Oct 21, 2019 at 11:06 PM Bastian Blank <waldi@debian.org> wrote:
> There is "gbp dch", which ignores merge commits (so no really good for
> merge requests), but I don't consider it to have enough control over the
> content of the changelog.

Just set your merge settings per project to fast-forward.

Thanks,
Jeremy

[toc] | [prev] | [next] | [standalone]

#65468

Hi,

On Tue, Oct 22, 2019 at 04:47:53AM +0200, Bastian Blank wrote:

> In Debian most people prefer to have changelog entries with all changes,
> so changes always contain a modification to debian/changelog.

It's worse than that: changelogs are supposed to contain the linear history
of the branch they are on, so the bug tracking system can determine fork
points and find out whether a particular bug is fixed in a particular
version.

> If we also start to use merge requests on Salsa, all those changes will
> contain modifications to debian/changelog, which will usualy conflict
> with each other.  Or worse, are applied to an old changelog entry.  This
> for example happens on the linux packaging project.

Yes, changelog merging needs to be special-cased with a tool that
understands the semantics, in the same way you are not presented with a
conflict resolution screen for the commit message when merging two branches
in a VCS.

Your proposal loses a bit of metadata in the VCS, because the changelog
entry is shown as having been created by the final release commit, and
backtracking through the VCS is made harder because of this. I'd consider
"git blame debian/changelog" to be a very useful tool.

   Simon

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web