metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Allen <n...@nickallen.org>
Subject Re: [DISCUSS] Metron RPM spec changelog
Date Wed, 18 Apr 2018 17:21:32 GMT
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.miklavcic@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 <ottobackwards@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 (cestella@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.miklavcic@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.
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message