Re: [DISCUSS] Release Process Update

[Matt Foley]

Thanks, Jon.  I’ve committed the patch.
--Matt

On 10/25/17, 9:26 AM, "zeo...@gmail.com"  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  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"  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=34=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 
> 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"  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
> > > > , 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 

Re: [DISCUSS] Release Process Update

[zeo...@gmail.com]

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  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"  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=34=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 
> 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"  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
> > > > , 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

Re: [DISCUSS] Release Process Update

[Matt Foley]

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"  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


is the wiki diff, feel free to critique/alter.

Jon

On Tue, Oct 24, 2017 at 7:07 AM Kyle Richardson 
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  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"  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 
> > 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
> > > , 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

Re: [DISCUSS] Release Process Update

[zeo...@gmail.com]

Hmm, I kind of like it as a historical validation/confirmation of build
success, but I can see where you are coming from.  Here

is the wiki diff, feel free to critique/alter.

Jon

On Tue, Oct 24, 2017 at 7:07 AM Kyle Richardson 
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  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"  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 
> > 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
> > > , 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

Re: [DISCUSS] Release Process Update

[Kyle Richardson]

+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  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"  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 
> 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
> >
>
>
>

Re: [DISCUSS] Release Process Update

[Matt Foley]

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"  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  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
>

Re: [DISCUSS] Release Process Update

[Justin Leet]

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  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
>

[DISCUSS] Release Process Update

[zeo...@gmail.com]

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