+1 Yes for the past couple years we've been doing this, it seems like the testing and initiating of fixes has been completely the Release Managers job. I did delegate some client side testing for the various drivers we support and multi-node testing when I was in that role prior to sending out the vote. And it worked well. So I agree, delegating before the vote is even initiated is the way to go if the release manager does not have the bandwidth to do it all. Thanks Sandhya
-----Original Message----- From: Steve Varnau <[email protected]> Sent: Wednesday, September 5, 2018 9:41 AM To: [email protected] Subject: RE: Trafodion 2.3 check list Agree with Hans. When we create a release branch, then we should do a round of release testing. Many hands make light work. --Steve > -----Original Message----- > From: Hans Zeller <[email protected]> > Sent: Wednesday, September 5, 2018 8:13 AM > To: [email protected] > Subject: RE: Trafodion 2.3 check list > > +1 > > What we do right now is to run some critical tests for the first time > during the voting phase, which makes that process very inefficient. > > I wonder how we could make sure those tests are run before the vote starts. > Maybe we should find volunteers to run them before the release and > then just do a final check during the voting phase? > > Hans > > -----Original Message----- > From: Roberta Marton <[email protected]> > Sent: Tuesday, September 4, 2018 5:13 PM > To: [email protected] > Subject: Trafodion 2.3 check list > > I think we should document the list of tests we should run on > Trafodion before we officially release the product. > This will help the release manager and the voters to make better > decisions about the product. > When someone wants to validate the release, they can choose one or > more tests. > Here is a list that I have thought about, feel free to add your own comments: > > Identify the latest versions of Hortonworks, Cloudera, and Java we support. > Create a set of predefined tests to run for EsgynDB and native Hive objects. > Nothing too big just basic DML and DDL requests. > > > * Verify that the signatures on all deliverables are good > > * Perform the following tests on both Hortonworks and Cloudera > platforms using the identified versions: > > o Install the binaries using Python and Ambari installers and run set of > predefined tests > > o Build the source, build the binaries, install the binaries using Python > and > Ambari installers, and run some predefined tests > > * Rerun the previous bullet with security features enabled (Kerberos & > LDAP) > > * Make sure installations work on single node and multi-node clusters. > > * Build the clients and make sure they work on both Hortonworks and > Cloudera > > Roberta
