You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pirk.apache.org by Suneel Marthi <su...@gmail.com> on 2016/08/20 19:17:30 UTC

Fwd: Apache PIO v0.10.0 release

FYI..

---------- Forwarded message ----------
From: Andrew Purtell <an...@gmail.com>
Date: Sat, Aug 20, 2016 at 3:14 PM
Subject: Re: Apache PIO v0.10.0 release
To: dev@predictionio.incubator.apache.org


It took Gearpump six release candidates before their first release from
incubation passed the IPMC's checks on correct LICENSE and NOTICE files
(note: different requirements for source and binary artifacts) and that all
the licenses of all transitive dependencies were accounted for and did not
require anything in Category X. This cannot be fully automated even with
maven projects where license data is part of the POM model, because the
metadata is sometimes wrong. I don't know how it works for SBT but suspect
at best it's the same situation.

The process is basically:

- Study and understand fully the foundation and Incubator release policies
with respect to licensing requirements.

- Dump the transitive dependencies of your source build and ensure there
are only Category A dependencies, or you have a plan to replace something
in B with A. X is not allowed except in limited circumstances as part of
the build only.
- Ensure the LICENSE and NOTICE files in the source root directory contain
everything required by policy.

- Dump the transitive dependencies of your binary builds and make sure
everything is licensed under licenses in Categories A or B.
- Ensure the LICENSE and NOTICE files included in **every PIO jar** contain
everything required by policy. If you aren't including such files in every
jar fix the build so it happens as required.

You can avoid dealing with binary artifact requirements by producing only
source artifacts for releases.

> On Aug 20, 2016, at 11:24 AM, Suneel Marthi <su...@gmail.com>
wrote:
>
> This is a laborious manual thing. Most incubator projects get dinged on
> those very issues.
>
> We have been trying to get a first Pirk release for a week now, but
holding
> off to fix the license and notices.
>
> Maybe in PIO, its already been taken care of. Donald?
>
> Regardless it would be good if someone reviewed the release artifacts now
> and validates the License and Notices as opposed to pushing a release and
> getting -1 vote from IPMC.
>
>
>
>> On Sat, Aug 20, 2016 at 2:21 PM, Pat Ferrel <pa...@occamsmachete.com>
wrote:
>>
>> Sound good. Is this a hand thing or can we automate it like PIO-26 RAT.
>> Could you add a Jira with comments?
>>
>> On Aug 20, 2016, at 11:16 AM, Suneel Marthi <sm...@apache.org> wrote:
>>
>> While waiting on #1 below, I would ask that you do the due diligence on
the
>> License and Notice files and ensure that all third party jars have been
>> accounted for and the License and Notice files are included in the
>> appropriate project release artifacts.
>>
>>> On Sat, Aug 20, 2016 at 2:00 PM, Pat Ferrel <pa...@occamsmachete.com>
wrote:
>>>
>>> What do people think remains for release?
>>>
>>> 1) template donation and mods. Chan Lee has done work on this but we
>> can’t
>>> review until the donation and repos are set up.
>>> 2) install.sh. There are some suggestions on how to deal with the
>> one-line
>>> install here: https://issues.apache.org/jira/browse/PIO-22 and a bug
>> here
>>> https://issues.apache.org/jira/browse/PIO-25 PIO-22 suggests we have an
>>> install based on source pull and build so it will work even on snapshots
>> in
>>> the “develop” branch but we could also have an install from binary that
>>> works after the release. Comments welcome.
>>> 3) https://issues.apache.org/jira/browse/PIO-26 has a PR but I don’t fee
>>> qualified to merge it, can someone pick this up?
>>>
>>> Anything else? I took the liberty of marking anything I thought was a
>>> non-blocker but unresolved as minor. Feel free to disagree.
>>>
>>> Hopefully when #1 comes through we will have everything else cleared up.
>>> Let’s ship-it.
>>
>>