On Thu, Jan 26, 2017 at 3:09 PM, sblackmon <sblack...@apache.org> wrote:
> > On December 18, 2016 at 9:08:21 PM, Suneel Marthi (smar...@apache.org > (mailto:smar...@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 > >
