metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otto Fowler <ottobackwa...@gmail.com>
Subject Re: [DISCUSS] Metron RPM spec changelog
Date Wed, 18 Apr 2018 19:17:08 GMT
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 (nick@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.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