I think I'd prefer to see the changelog only include the release entries,
rather than individual entries per dev.  We keep the spec file in source
control to determine the individual changes between releases.  I'm happy to
have my mind changed, though.

On Wed, Apr 18, 2018 at 9:47 AM Michael Miklavcic <
michael.miklav...@gmail.com> wrote:

> We discovered yesterday while reviewing a PR that the RPM changelog hasn't
> been maintained since 9/25/17. There are 7 changes to that file that have
> not been logged in the changelog itself. The question is if we want to keep
> maintaining the changelog and, if so, should we patch the existing log with
> the missing commits. Any opinions on this? I myself don't have a strong
> opinion either way, but we shouldn't leave it in its current state.
>
> Mike
>
>
> Quoting the conversation between myself and Justin Leet:
>
> https://github.com/apache/metron/pull/996#issuecomment-382194736
> @justinleet Do we still want/need to do this? The last log change was Tue
> Sep 25 2017 by @merrimanr in METRON-1207. However, there have been 6
> changes to the spec since then that have not made it to the change log. I
> believe there was a reason we started doing this (in duplication of source
> control), but I don't recall specifically. Do remember why that was?
>
> https://github.com/apache/metron/pull/996#issuecomment-382199021
> I believe, and my memory is pretty fuzzy, is that it's best practice to
> maintain that changelog because it's useful for auditing and tracking
> purposes given that it's available on the rpm itself.
>
> There's probably a couple questions here
>
>
>    1. Are we going to maintain it going forward? If not, we should just
>    dump it entirely.
>    2. If we choose to do so, do we want/need to update the changelog for
>    the missing commits (and probably to use the dev list as authors, rather
>    than individuals)?
>
>
> Might be worth opening a discuss on it. I could be persuaded either way in
> terms of whether we update it for this PR or not, but I have a slight
> preference on adding it until there's agreement we aren't doing it.
>

Reply via email to