Re: 0.4.1-incubating Release and priorities for 0.5-incubating

[sblackmon <sb...@apache.org>]

 
On December 18, 2016 at 9:08:21 PM, Suneel Marthi (smarthi@apache.org(mailto:smarthi@apache.org)) wrote:

> While working on the 0.4.1-incubating release this weekend, we faced
> process challenges that need to be addressed before the next release and
> for Streams to be TLP graduation-worthy.
>  
Agreed.  Notes in-line below.

> 1. The release process was broken due to recent fix and had to manually
> fix the release versions across all the POMs across all the 3 projects.
> 
My experience with the maven release plugin has been that while you can attempt
to use properties to specify versions for dependencies outside the reactor, if 
they are snapshots the release plugin will ‘helpfully’ change them for you, discarding
the ${streams.version} in the process.  This happens a lot in streams-examples, which
has many dependencies to streams-project.

Best idea to avoid in future:
a) Let’s dependencyManage every org.apache.streams dependency in streams-examples in the
examples root pom to a property ${streams.version}
b) Let’s update that property from x.y-incubating-SNAPSHOT to x.y-incubating with a manual commit 
prior to running release-prepare.  If the release is cancelled, we’ll have to rollback past this
manual change to build from snapshot again.
c) There are some flags you can pass to release plugin to avoid the tedious snapshot resolution; 
let’s add those to the release instructions.

> 2. Facebook credentials timeout very quick and there's no easy fix for
> that, time to start conversation around how to address this in the long
> term.
> 
The Graph API Explorer is the easiest way I know of to get a working facebook token, but they 
do timeout quickly.  There are challenges creating and maintaining tokens for testing with 
Instagram with a sandbox account.

The only way we’ll get a set of testing credentials is to create official accounts and official apps
for the project.  Not a small undertaking, but essential.  I’ve added notes to that effect to:
https://cwiki.apache.org/confluence/display/STREAMS/Apache+Streams+Social+Accounts

Once we have a set of working credentials for all supported channels that reside securely in jenkins, we 
can skip integration testing as part of the release process and just link to the successful builds in the
rc notes.

In the interim, release managers (and anyone running integration tests) will need to create and supply 
their own account details and credentials by hand.  

> 3. Release script as it is now on the Release website is inadequate and
> doesn't accurately describe the release process.
> 
A lot of changes to project structure and poms have taken place recently.  Prior to and during the next release
let’s make an effort to cover every single step, placing details (such as how to create accounts and 
generate credentials for testing) to are relevant to users as well as release manager outside the body 
of the release process document.

> 4. Integration Testing of streaming plugins fails sporadically on some
> environments for no apparent reason, need to harden the Integration Tests
> for plugins.
> 
I believe the root cause of the plugin IT failures during 0.4.1 was addressed with STREAMS-472.

During all releases, any test failures encountered during the release process or during verification by
anyone, should result in a ticket created, whether or not the issue is intermittent or cancels the rc! 

> 5. The checkstyle link didn't work during the release process and had to be
> manually fixed.
> 
We chose to host the checkstyle definition on the website to make it easier to distribute among our 
multiple source repositories.  It was checked into streams-master initially and is now checked into streams-project.

As of https://github.com/apache/incubator-streams/commit/b3604a6ed808dc04490f098c6b69c31369a95ca3
the link is to /site/latest rather than to a specific version, removing the situation where the site would have to
be deployed before completing the release (which doesn’t make sense).

> 6. Merge streams-master and streams-project into one single project, this
> will save us some dependency issues while releasing streams-examples.
> 
As of https://github.com/apache/incubator-streams/commit/b3604a6ed808dc04490f098c6b69c31369a95ca3
neither streams-project nor streams-examples depend on streams-master.

This will materially affect the release instructions and other parts of the webpage.

Created STREAMS-484.

> I'll be creating High Priority jira issues for these and would emphasize
> that these need to be addressed prior to the next release.
>  
> Regarding the 0.4.1-incubating release, its likely that the build and tests
> may not pass on the first attempt and have to be repeated a few times, if u
> do encounter any such issues - please feel free to veto the 0.4.1 release
> and we could focus efforts on fixing all of the above issues and rolling
> out a 0.5 release early next year.
>  
> Regards,
> Suneel

Re: 0.4.1-incubating Release and priorities for 0.5-incubating

[sblackmon <sb...@apache.org>]

 
Opened STREAMS-485 and STREAMS-486 to wrap up this thread.

The set of issues planned for 0.5 can be seen here:  

https://issues.apache.org/jira/secure/RapidView.jspa?rapidView=147  

These are almost all documentation, project / release management improvements.  

Planned release timeframe: end of February. Please pitch in on something simple if you can.  

Thanks,

Steve


On January 28, 2017 at 10:55:18 AM, Suneel Marthi (smarthi@apache.org(mailto:smarthi@apache.org)) wrote:

> On Thu, Jan 26, 2017 at 3:09 PM, sblackmon wrote:
>  
> >
> > On December 18, 2016 at 9:08:21 PM, Suneel Marthi (smarthi@apache.org
> > (mailto:smarthi@apache.org)) wrote:
> >
> > > While working on the 0.4.1-incubating release this weekend, we faced
> > > process challenges that need to be addressed before the next release and
> > > for Streams to be TLP graduation-worthy.
> > >
> > Agreed. Notes in-line below.
> >
> > > 1. The release process was broken due to recent fix and had to manually
> > > fix the release versions across all the POMs across all the 3 projects.
> > >
> > My experience with the maven release plugin has been that while you can
> > attempt
> > to use properties to specify versions for dependencies outside the
> > reactor, if
> > they are snapshots the release plugin will ‘helpfully’ change them for
> > you, discarding
> > the ${streams.version} in the process. This happens a lot in
> > streams-examples, which
> > has many dependencies to streams-project.
> >
> > Best idea to avoid in future:
> > a) Let’s dependencyManage every org.apache.streams dependency in
> > streams-examples in the
> > examples root pom to a property ${streams.version}
> > b) Let’s update that property from x.y-incubating-SNAPSHOT
> > to x.y-incubating with a manual commit
> > prior to running release-prepare. If the release is cancelled, we’ll have
> > to rollback past this
> > manual change to build from snapshot again.
> > c) There are some flags you can pass to release plugin to avoid the
> > tedious snapshot resolution;
> > let’s add those to the release instructions.
> >
>  
> +1 to all of the above suggestions and it definitely makes the Release
> Manager's job less painful
>  
> >
> > > 2. Facebook credentials timeout very quick and there's no easy fix for
> > > that, time to start conversation around how to address this in the long
> > > term.
> > >
> > The Graph API Explorer is the easiest way I know of to get a working
> > facebook token, but they
> > do timeout quickly. There are challenges creating and maintaining tokens
> > for testing with
> > Instagram with a sandbox account.
> >
> > The only way we’ll get a set of testing credentials is to create official
> > accounts and official apps
> > for the project. Not a small undertaking, but essential. I’ve added
> > notes to that effect to:
> > https://cwiki.apache.org/confluence/display/STREAMS/
> > Apache+Streams+Social+Accounts
> >
> > Once we have a set of working credentials for all supported channels that
> > reside securely in jenkins, we
> > can skip integration testing as part of the release process and just link
> > to the successful builds in the
> > rc notes.
> >
> > In the interim, release managers (and anyone running integration tests)
> > will need to create and supply
> > their own account details and credentials by hand.
> >
>  
> Sounds like a good plan
>  
> >
> > > 3. Release script as it is now on the Release website is inadequate and
> > > doesn't accurately describe the release process.
> > >
> > A lot of changes to project structure and poms have taken place recently.
> > Prior to and during the next release
> > let’s make an effort to cover every single step, placing details (such as
> > how to create accounts and
> > generate credentials for testing) to are relevant to users as well as
> > release manager outside the body
> > of the release process document.
> >
>  
> Let's document this for 0.5-incubating release
>  
> >
> > > 4. Integration Testing of streaming plugins fails sporadically on some
> > > environments for no apparent reason, need to harden the Integration Tests
> > > for plugins.
> > >
> > I believe the root cause of the plugin IT failures during 0.4.1 was
> > addressed with STREAMS-472.
> >
> > During all releases, any test failures encountered during the release
> > process or during verification by
> > anyone, should result in a ticket created, whether or not the issue is
> > intermittent or cancels the rc!
> >
>  
> +1
>  
> >
> > > 5. The checkstyle link didn't work during the release process and had to
> > be
> > > manually fixed.
> > >
> > We chose to host the checkstyle definition on the website to make it
> > easier to distribute among our
> > multiple source repositories. It was checked into streams-master
> > initially and is now checked into streams-project.
> >
> > As of https://github.com/apache/incubator-streams/commit/
> > b3604a6ed808dc04490f098c6b69c31369a95ca3
> > the link is to /site/latest rather than to a specific version, removing
> > the situation where the site would have to
> > be deployed before completing the release (which doesn’t make sense).
> >
>  
> Thanks for taking care of this.
>  
> >
> > > 6. Merge streams-master and streams-project into one single project, this
> > > will save us some dependency issues while releasing streams-examples.
> > >
> > As of https://github.com/apache/incubator-streams/commit/
> > b3604a6ed808dc04490f098c6b69c31369a95ca3
> > neither streams-project nor streams-examples depend on streams-master.
> >
> > This will materially affect the release instructions and other parts of
> > the webpage.
> >
> > Created STREAMS-484.
> >
> > > I'll be creating High Priority jira issues for these and would emphasize
> > > that these need to be addressed prior to the next release.
> > >
> > > Regarding the 0.4.1-incubating release, its likely that the build and
> > tests
> > > may not pass on the first attempt and have to be repeated a few times,
> > if u
> > > do encounter any such issues - please feel free to veto the 0.4.1 release
> > > and we could focus efforts on fixing all of the above issues and rolling
> > > out a 0.5 release early next year.
> > >
> > > Regards,
> > > Suneel
> >
> >

Re: 0.4.1-incubating Release and priorities for 0.5-incubating

[Suneel Marthi <sm...@apache.org>]

On Thu, Jan 26, 2017 at 3:09 PM, sblackmon <sb...@apache.org> wrote:

>
> On December 18, 2016 at 9:08:21 PM, Suneel Marthi (smarthi@apache.org
> (mailto:smarthi@apache.org)) wrote:
>
> > While working on the 0.4.1-incubating release this weekend, we faced
> > process challenges that need to be addressed before the next release and
> > for Streams to be TLP graduation-worthy.
> >
> Agreed.  Notes in-line below.
>
> > 1. The release process was broken due to recent fix and had to manually
> > fix the release versions across all the POMs across all the 3 projects.
> >
> My experience with the maven release plugin has been that while you can
> attempt
> to use properties to specify versions for dependencies outside the
> reactor, if
> they are snapshots the release plugin will ‘helpfully’ change them for
> you, discarding
> the ${streams.version} in the process.  This happens a lot in
> streams-examples, which
> has many dependencies to streams-project.
>
> Best idea to avoid in future:
> a) Let’s dependencyManage every org.apache.streams dependency in
> streams-examples in the
> examples root pom to a property ${streams.version}
> b) Let’s update that property from x.y-incubating-SNAPSHOT
> to x.y-incubating with a manual commit
> prior to running release-prepare.  If the release is cancelled, we’ll have
> to rollback past this
> manual change to build from snapshot again.
> c) There are some flags you can pass to release plugin to avoid the
> tedious snapshot resolution;
> let’s add those to the release instructions.
>

+1 to all of the above suggestions and it definitely makes the Release
Manager's job less painful

>
> > 2. Facebook credentials timeout very quick and there's no easy fix for
> > that, time to start conversation around how to address this in the long
> > term.
> >
> The Graph API Explorer is the easiest way I know of to get a working
> facebook token, but they
> do timeout quickly.  There are challenges creating and maintaining tokens
> for testing with
> Instagram with a sandbox account.
>
> The only way we’ll get a set of testing credentials is to create official
> accounts and official apps
> for the project.  Not a small undertaking, but essential.  I’ve added
> notes to that effect to:
> https://cwiki.apache.org/confluence/display/STREAMS/
> Apache+Streams+Social+Accounts
>
> Once we have a set of working credentials for all supported channels that
> reside securely in jenkins, we
> can skip integration testing as part of the release process and just link
> to the successful builds in the
> rc notes.
>
> In the interim, release managers (and anyone running integration tests)
> will need to create and supply
> their own account details and credentials by hand.
>

Sounds like a good plan

>
> > 3. Release script as it is now on the Release website is inadequate and
> > doesn't accurately describe the release process.
> >
> A lot of changes to project structure and poms have taken place recently.
> Prior to and during the next release
> let’s make an effort to cover every single step, placing details (such as
> how to create accounts and
> generate credentials for testing) to are relevant to users as well as
> release manager outside the body
> of the release process document.
>

Let's document this for 0.5-incubating release

>
> > 4. Integration Testing of streaming plugins fails sporadically on some
> > environments for no apparent reason, need to harden the Integration Tests
> > for plugins.
> >
> I believe the root cause of the plugin IT failures during 0.4.1 was
> addressed with STREAMS-472.
>
> During all releases, any test failures encountered during the release
> process or during verification by
> anyone, should result in a ticket created, whether or not the issue is
> intermittent or cancels the rc!
>

+1

>
> > 5. The checkstyle link didn't work during the release process and had to
> be
> > manually fixed.
> >
> We chose to host the checkstyle definition on the website to make it
> easier to distribute among our
> multiple source repositories.  It was checked into streams-master
> initially and is now checked into streams-project.
>
> As of https://github.com/apache/incubator-streams/commit/
> b3604a6ed808dc04490f098c6b69c31369a95ca3
> the link is to /site/latest rather than to a specific version, removing
> the situation where the site would have to
> be deployed before completing the release (which doesn’t make sense).
>

Thanks for taking care of this.

>
> > 6. Merge streams-master and streams-project into one single project, this
> > will save us some dependency issues while releasing streams-examples.
> >
> As of https://github.com/apache/incubator-streams/commit/
> b3604a6ed808dc04490f098c6b69c31369a95ca3
> neither streams-project nor streams-examples depend on streams-master.
>
> This will materially affect the release instructions and other parts of
> the webpage.
>
> Created STREAMS-484.
>
> > I'll be creating High Priority jira issues for these and would emphasize
> > that these need to be addressed prior to the next release.
> >
> > Regarding the 0.4.1-incubating release, its likely that the build and
> tests
> > may not pass on the first attempt and have to be repeated a few times,
> if u
> > do encounter any such issues - please feel free to veto the 0.4.1 release
> > and we could focus efforts on fixing all of the above issues and rolling
> > out a 0.5 release early next year.
> >
> > Regards,
> > Suneel
>
>