streams-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sblackmon <sblack...@apache.org>
Subject Re: 0.4.1-incubating Release and priorities for 0.5-incubating
Date Thu, 26 Jan 2017 20:09:28 GMT
 
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


Mime
View raw message