Thank you for the tips. I've filed a JIRA to get RAT working:
https://issues.cloudera.org/browse/IMPALA-4110 On Thu, Sep 8, 2016 at 2:02 AM, Tom White <t...@cloudera.com> wrote: > I would also add that each PMC member has their own way of checking > things. There may be some release checking scripts out there, but it's > actually OK to have different people go through the release process > checklist in their own way as it's more likely to catch problems. > Also, automated checking scripts can't catch everything - e.g. license > issues. > > +1 to adding RAT. > > Tom > > On Wed, Sep 7, 2016 at 10:13 PM, Todd Lipcon <t...@cloudera.com> wrote: >> On Wed, Sep 7, 2016 at 2:06 PM, Jim Apple <jbap...@cloudera.com> wrote: >>> >>> Dear mentors, >>> >>> The release policy says that PMC members, before +1ing a release >>> candidate, must "verify[ing] that the package meets the requirements >>> of the ASF policy on releases". >>> >>> Does that imply that PMC members need to be familiar with (and check >>> for) the rules on http://www.apache.org/dev/release.html in every RC >>> tarball? >> >> >> To a certain extent, yes -- the PMC's main duty is to ensure that the >> project releases are appropriately licensed (here's your weekly reminder >> that the ASF has no "quality bar" and doesnt care if your project is broken >> and crashes all the time, so long as it's IP-wise clear). Typically there is >> a smaller subset of PMC members who get very familiar with the licensing >> requirements, etc, and take it upon themselves to check it carefully on >> releases. >> >> I'd also recommend setting up something like Apache RAT which can >> automatically check for things like missing license headers, etc. eg we have >> our set up here: >> https://github.com/apache/kudu/tree/master/build-support/release >> and it's run automatically by our 'build_source_release.py' script: >> https://github.com/apache/kudu/blob/master/build-support/build_source_release.py >> >> Typically there's a lot of work in this area for your first couple releases, >> but then after that there's usually significantly less churn of >> dependencies, etc, and it's not too hard for someone to just spot check with >> a git diff between the prior release and this one to look at any changes to >> poms, thirdparty scripts, linkers, etc. >> >> -Todd >> -- >> Todd Lipcon >> Software Engineer, Cloudera
