metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Lyle <dlyle65...@gmail.com>
Subject Re: [DISCUSS] Metron RPM spec changelog
Date Wed, 18 Apr 2018 20:32:56 GMT
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 <ottobackwards@gmail.com>
wrote:

> I could not find it.
>
>
> On April 18, 2018 at 15:34:25, Justin Leet (justinjleet@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 <ottobackwards@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 (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