How PMC members are supposed to enforce release policy?

[Jim Apple <jb...@cloudera.com>]

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?

Re: How PMC members are supposed to enforce release policy?

[Jim Apple <jb...@cloudera.com>]

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 <to...@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 <to...@cloudera.com> wrote:
>> On Wed, Sep 7, 2016 at 2:06 PM, Jim Apple <jb...@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

Re: How PMC members are supposed to enforce release policy?

[Tom White <to...@cloudera.com>]

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 <to...@cloudera.com> wrote:
> On Wed, Sep 7, 2016 at 2:06 PM, Jim Apple <jb...@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

Re: How PMC members are supposed to enforce release policy?

[Todd Lipcon <to...@cloudera.com>]

On Wed, Sep 7, 2016 at 2:06 PM, Jim Apple <jb...@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