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 <ma...@apache.org> 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, "zeo...@gmail.com" <zeo...@gmail.com> 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 < > kylerichards...@gmail.com> > 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 <mfo...@hortonworks.com> > 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" <justinjl...@gmail.com> 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, zeo...@gmail.com < > zeo...@gmail.com> > > > 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
