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