metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Foley <>
Subject Re: [DISCUSS] Release Process Update
Date Mon, 23 Oct 2017 19:12:53 GMT
I agree with Justin.  This micro-feature is intended as a github widget, which causes the top-level
README to give all viewers an immediate flag whether the build is healthy or not.  It does
not belong in a rendered site-book.

Removing the widget during site-book build, can be done with a one-line addition to HREF_REWRITE_LIST

Recommend not worrying about historical site-books (they naturally obsolesce out of the “dist/release”


On 10/23/17, 6:38 AM, "Justin Leet" <> wrote:

    I'd argue it shouldn't be in the site-book at all. Presumably we aren't
    releasing while Travis is broken, so it's not useful information for anyone
    looking at docs. It just carries over from the main README.  Seems like we
    should just scrub it when we do the other fixes to the READMEs to make them
    suitable for site-book.  At that point it's just gone entirely. from the
    next release.
    Doesn't solve the problem of prior releases (assuming we care enough to do
    On Mon, Oct 23, 2017 at 9:32 AM, <> wrote:
    > Today I was poking around the Metron site and documentation, and I noticed
    > that the site-book's travis build status image is pointing to master for
    > all of our releases.  We should probably update the release process
    > <> to
    > pin
    > this to the specific release.
    > I will happily handle the documentation update but I wanted to ask, what
    > should it be pointing to?  Repointing is incredibly straightforward
    > <>, but I'm not sure would be
    > more appropriate to use - the release branches (e.g. Metron_0.4.1), or
    > the release tags (e.g. apache-metron-0.4.1-release)?  I'm not clear on
    > their specific uses in our environment.  In reviewing our current process,
    > it appears that we _could_ use either.
    > I also wanted to ask, does anybody think that this should get fixed
    > historically?  I think that this might be an excessive amount of hassle,
    > but I wanted to put it out there since I'm not intimately familiar with
    > what we'd need to do in order to clean this up.
    > Jon
    > --
    > Jon

View raw message