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. > > > > > > > > > >
