impala-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom White <...@cloudera.com>
Subject Re: How PMC members are supposed to enforce release policy?
Date Thu, 08 Sep 2016 09:02:39 GMT
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 <todd@cloudera.com> wrote:
> On Wed, Sep 7, 2016 at 2:06 PM, Jim Apple <jbapple@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

Mime
View raw message