We use it to maintain compatibility with rpm -q --changelog. It's duplicative, but somewhat useful if all you have are the binaries.
-D... On Wed, Apr 18, 2018 at 3:51 PM, Otto Fowler <ottobackwa...@gmail.com> wrote: > I could not find it. > > > On April 18, 2018 at 15:34:25, Justin Leet (justinjl...@gmail.com) wrote: > > Yeah, I tried digging the thread up and didn't find it; maybe you'll have > more luck than me. Iirc, it was more a "best practices" thing than an > actual hard rule. > > On Wed, Apr 18, 2018 at 3:17 PM, Otto Fowler <ottobackwa...@gmail.com> > wrote: > > > I’ll try to the list history, we had this conversation a while ago, I’m > not > > sure whom it was ( MattF or DLyle ). > > My recollection was that this was the ‘proper’ way to build RPMs and the > > concern was to do it correctly by > > book. > > > > > > On April 18, 2018 at 13:21:38, Nick Allen (n...@nickallen.org) wrote: > > > > Can someone clarify how the change log entries are useful? Who would use > > them and why? > > > > I assume there is some way to view them when the RPMs are installed on a > > host, but I've never found a need to do that. > > > > On Wed, Apr 18, 2018 at 1:18 PM, Michael Miklavcic < > > michael.miklav...@gmail.com> wrote: > > > > > I think I like Casey's recommendation here. Would you want to simply > say > > > that a release was cut, or actually list the changes under the release? > > We > > > could probably do a couple things to that end. > > > > > > 1. Per Otto's comment, get the existing changelog in order - I think we > > > should modify it to reflect a per-release formatting, which would mean > > > grabbing historical changes to that file and enumerating them per > release > > > (or just having a very simple single change note). > > > e.g., the 0.4.2 items get merged as follows (changing the date > > accordingly > > > to reflect the release date) > > > > > > * Tue Sep 25 2017 Apache Metron <dev@metron.apache.org> - 0.4.2 > > > - Add Alerts UI > > > - Updated and renamed metron-rest script > > > > > > 2. Depending on how you guys feel about granularity, we could make > > changes > > > in the current release added as a line-item under a CURRENT or > > > 0.4.3-SNAPSHOT version, e.g. > > > * RELEASE-DATE Apache Metron <dev@metron.apache.org> - CURRENT > > > - METRON-1499 Enable Configuration of Unified Enrichment Topology via A > > > - METRON-1483: Create a tool to monitor performance of the topologies c > > > - METRON-1397 Support for JSON Path and complex documents in JSONMapPar > > > - METRON-1460: Create a complementary non-split-join enrichment > topology > > > - METRON-1302: Split up Indexing Topology into batch and random access > > > - METRON-1378: Create a summarizer > > > > > > Or have the release manager do it. The first route would leave a dev on > > the > > > hook, but the release manager would then simply need to update the date > > and > > > version info rather than collect all the changes. I'm unsure off the > top > > of > > > my head if rpm will blow a gasket over the date and version formatting, > > but > > > we can find a way to make that work. The other approach would mean just > > > doing a git log on the spec file and grabbing the delta since last > > release. > > > Side note, I kind of like the idea of having the Jira ticket number in > > the > > > comment like that in the second example. What do you guys think? > > > > > > Mike > > > > > > > > > On Wed, Apr 18, 2018 at 9:23 AM, Otto Fowler <ottobackwa...@gmail.com> > > > wrote: > > > > > > > I think having the spec file updated with the changes per release is > > > fine, > > > > but is the release manager > > > > going to do that? > > > > > > > > If so then the docs need to be updated. Also, we *should* true up any > > > > missing entries from the file now. > > > > > > > > > > > > > > > > On April 18, 2018 at 11:02:35, Casey Stella (ceste...@gmail.com) > > wrote: > > > > > > > > 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. > > > > > > > > > > > > > > >
