streams-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suneel Marthi <smar...@apache.org>
Subject Re: 0.4.1-incubating Release and priorities for 0.5-incubating
Date Sat, 28 Jan 2017 16:55:12 GMT
On Thu, Jan 26, 2017 at 3:09 PM, sblackmon <sblackmon@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message