Thanks, Jon. I’ve committed the patch.
--Matt
On 10/25/17, 9:26 AM, "[email protected]" <[email protected]> wrote:
I still kind of like the build image historically, since not everybody who
interfaces with our project will _know_ that the build must always succeed
for a release, but I agree that this is a clean approach so I rolled back
the wiki changes. Thanks,
Jon
On Tue, Oct 24, 2017 at 2:34 PM Matt Foley <[email protected]> wrote:
> The release wouldn’t have been made if the build didn’t succeed.
> And the Release Manager doesn’t need one more fiddly manual edit to do.
> I recommend the Release Process instructions be put back, and instead we
> incorporate
> https://github.com/apache/metron/pull/815
> Rational in
> https://issues.apache.org/jira/browse/METRON-1278
>
> Thanks,
> --Matt
>
> On 10/24/17, 5:37 AM, "[email protected]" <[email protected]> wrote:
>
> Hmm, I kind of like it as a historical validation/confirmation of
build
> success, but I can see where you are coming from. Here
> <
>
https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=66854770&selectedPageVersions=34&selectedPageVersions=33
> >
> is the wiki diff, feel free to critique/alter.
>
> Jon
>
> On Tue, Oct 24, 2017 at 7:07 AM Kyle Richardson <
> [email protected]>
> wrote:
>
> > +1 I agree with Matt and Justin. The Travis build widget doesn't
> make sense
> > in the published release documentation. No sense in fixing
> retrospectively.
> >
> > -Kyle
> >
> > On Mon, Oct 23, 2017 at 3:13 PM Matt Foley <[email protected]>
> wrote:
> >
> > > 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 in:
> > >
> > >
> >
>
https://github.com/apache/metron/blob/master/site-book/bin/generate-md.sh#L75
> > >
> > > Recommend not worrying about historical site-books (they naturally
> > > obsolesce out of the “dist/release” area).
> > >
> > > Cheers,
> > > --Matt
> > >
> > > On 10/23/17, 6:38 AM, "Justin Leet" <[email protected]> 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
> > > anything).
> > >
> > > On Mon, Oct 23, 2017 at 9:32 AM, [email protected] <
> [email protected]>
> > > 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
> > > > <
> > https://cwiki.apache.org/confluence/display/METRON/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
> > > > <https://travis-ci.org/apache/metron/branches>, 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
> > > >
> > >
> > >
> > >
> >
> --
>
> Jon
>
>
>
>
> --
Jon
