You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@toree.apache.org by Gino Bustelo <gi...@bustelos.com> on 2016/04/05 16:23:52 UTC

Help from Mentors

We are getting close to completing work to our build scripts (PR #13
<https://github.com/apache/incubator-toree/pull/13>) to make the project
follow the Apache release criteria that we've been able to find through
search. Mainly auditing license headers, POM content, jar generation with
NOTICE/LICENSE files, etc.

At this point we need someone with experience that can verify all the steps
we've done. Also, it is not clear to me what the process is to getting all
the assets published for a release vote. Several question are:

1. Can publishing of assets be automated using Travis? Including maven
publish, and binary package distribution.
2. Where do we publish binary packages? Not talking about JARs, rather a
package with libraries and scripts to start/run Toree.

Any help is appreciated...

Thanks,
Gino

Re: Help from Mentors

Posted by Gino Bustelo <gi...@bustelos.com>.
We are correcting our LICENSE bundling to mirror what you've sent.

Now, on NOTICE file, we are going by the statement at
http://www.apache.org/dev/licensing-howto.html#mod-notice

>However, elements such as the copyright notifications embedded within BSD
and MIT licenses need not be duplicated in NOTICE

On Fri, Apr 8, 2016 at 12:51 PM, Hitesh Shah <hi...@apache.org> wrote:

> Another useful doc which was being worked on as part of Kudu going through
> the same pains of its first release:
>
> https://docs.google.com/document/d/1eftfjrWpOG-dRkw9dZWRfcj3p_qCeE5xC-G0Y5j29Ck/edit
>
> — Hitesh
>
> On Apr 8, 2016, at 9:03 AM, Gino Bustelo <gi...@bustelos.com> wrote:
>
> > I'm reading
> https://github.com/zeromq/jeromq/blob/master/COPYING.LESSER#L91 and
> > seems to me that we need to ship our bin distros with copies of the LGPL
> > license. What is you all read?
> >
> > On Thu, Apr 7, 2016 at 6:00 PM, Gino Bustelo <lb...@gmail.com> wrote:
> >
> >> @hitesh
> >>
> >> Awesome summary. This helps a ton. It confirms what we about to do with
> >> License/Notices files.
> >>
> >>
> >> Thanks
> >>
> >> Gino B.
> >>
> >>> On Apr 6, 2016, at 6:07 PM, Hitesh Shah <hi...@apache.org> wrote:
> >>>
> >>> Will take a look.
> >>>
> >>> Some general comments in the meantime:
> >>>  - version should have incubating. tar balls should be versioned and
> >> have incubating as part of their names ( this seems to be getting
> addressed
> >> in the pull request )
> >>>  - the main LICENSE and NOTICE are for a source release. This means if
> >> there are any files part of the source release ( javascript, fonts, etc
> )
> >> which are checked in as part of the codebase that have a different
> license
> >> should be checked to see if any updates are needed to the main LICENSE
> and
> >> NOTICE files.
> >>>  - Based on the thread (
> >>
> http://mail-archives.apache.org/mod_mbox/incubator-general/201602.mbox/%3C5F118AA0-4ADA-403B-A6EB-4A85F0B30651%40me.com%3E
> >> ), this will be the only one release allowed with the LGPL dependency.
> In
> >> addition, based on the thread, a sentence added to the DISCLAIMER that
> >> Toree depends on X which is licensed using Y and does not conform to
> Apache
> >> License v2 would be needed. See Bertrand’s reply to the thread.
> >>>  - jars should have a LICENSE and NOTICE ( seems like this is being
> >> addressed in the pull request too )
> >>>  - If there is a plan to publish binary-release.tar.gz and the other
> >> tarball as convenience artifacts as part of the release, they will need
> >> their own LICENSE and NOTICE files depending on what each of them are
> >> bundling. This is usually where most podlings trip up.
> >>>
> >>> thanks
> >>> — Hitesh
> >>>
> >>>> On Apr 5, 2016, at 3:10 PM, Gino Bustelo <gi...@bustelos.com> wrote:
> >>>>
> >>>> Thanks Hitesh... would you be available to take a look at all we are
> >>>> covering in the  PR #13 <
> >> https://github.com/apache/incubator-toree/pull/13>.
> >>>> Would be great to get an idea if we are going in the right direction
> >>>> regarding LICENSE/NOTICE files and what is needed extra due to LGPL
> >>>> dependency.
> >>>>
> >>>> I think once we got signing done... all the pieces are in place to
> >> create
> >>>> all the assets that will be released.
> >>>>
> >>>>> On Tue, Apr 5, 2016 at 3:43 PM, Hitesh Shah <hi...@apache.org>
> wrote:
> >>>>>
> >>>>> For snapshot versions, I believe build tools are allowed to publish
> to
> >> the
> >>>>> snapshot repo as needed. jenkins builds already support this and I am
> >>>>> guessing travis should have similar provisions.
> >>>>>
> >>>>> For releases ( with a disclaimer as binary artifacts are not
> considered
> >>>>> part of an official release), the binary convenience artifacts would
> be
> >>>>> publish via dist.apache.org. The general approach is to publish an
> RC
> >> to
> >>>>> dist.apache/dev , get it voted upon by the community/PPMC ( followed
> >> by an
> >>>>> IPMC vote on general@incubator ) and then move to /release after the
> >> vote
> >>>>> is successful. As part of the RC creation, the release manager would
> >> do an
> >>>>> appropriate mvn deploy ( this will go into a staging repo ) and also
> >> push
> >>>>> the bits to dist.apache.org - both of which need to be signed.
> >>>>>
> >>>>> Will need to check more on travis and whether a tool can publish bits
> >> as
> >>>>> all releases are meant to be signed by someone from the PPMC and
> using
> >> a
> >>>>> tool would imply providing your secret keys to the tool.
> >>>>>
> >>>>> — Hitesh
> >>>>>
> >>>>>> On Apr 5, 2016, at 7:23 AM, Gino Bustelo <gi...@bustelos.com> wrote:
> >>>>>>
> >>>>>> We are getting close to completing work to our build scripts (PR #13
> >>>>>> <https://github.com/apache/incubator-toree/pull/13>) to make the
> >> project
> >>>>>> follow the Apache release criteria that we've been able to find
> >> through
> >>>>>> search. Mainly auditing license headers, POM content, jar generation
> >> with
> >>>>>> NOTICE/LICENSE files, etc.
> >>>>>>
> >>>>>> At this point we need someone with experience that can verify all
> the
> >>>>> steps
> >>>>>> we've done. Also, it is not clear to me what the process is to
> getting
> >>>>> all
> >>>>>> the assets published for a release vote. Several question are:
> >>>>>>
> >>>>>> 1. Can publishing of assets be automated using Travis? Including
> maven
> >>>>>> publish, and binary package distribution.
> >>>>>> 2. Where do we publish binary packages? Not talking about JARs,
> >> rather a
> >>>>>> package with libraries and scripts to start/run Toree.
> >>>>>>
> >>>>>> Any help is appreciated...
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Gino
> >>>
> >>
>
>

Re: Help from Mentors

Posted by Hitesh Shah <hi...@apache.org>.
Another useful doc which was being worked on as part of Kudu going through the same pains of its first release:
https://docs.google.com/document/d/1eftfjrWpOG-dRkw9dZWRfcj3p_qCeE5xC-G0Y5j29Ck/edit

— Hitesh

On Apr 8, 2016, at 9:03 AM, Gino Bustelo <gi...@bustelos.com> wrote:

> I'm reading https://github.com/zeromq/jeromq/blob/master/COPYING.LESSER#L91 and
> seems to me that we need to ship our bin distros with copies of the LGPL
> license. What is you all read?
> 
> On Thu, Apr 7, 2016 at 6:00 PM, Gino Bustelo <lb...@gmail.com> wrote:
> 
>> @hitesh
>> 
>> Awesome summary. This helps a ton. It confirms what we about to do with
>> License/Notices files.
>> 
>> 
>> Thanks
>> 
>> Gino B.
>> 
>>> On Apr 6, 2016, at 6:07 PM, Hitesh Shah <hi...@apache.org> wrote:
>>> 
>>> Will take a look.
>>> 
>>> Some general comments in the meantime:
>>>  - version should have incubating. tar balls should be versioned and
>> have incubating as part of their names ( this seems to be getting addressed
>> in the pull request )
>>>  - the main LICENSE and NOTICE are for a source release. This means if
>> there are any files part of the source release ( javascript, fonts, etc )
>> which are checked in as part of the codebase that have a different license
>> should be checked to see if any updates are needed to the main LICENSE and
>> NOTICE files.
>>>  - Based on the thread (
>> http://mail-archives.apache.org/mod_mbox/incubator-general/201602.mbox/%3C5F118AA0-4ADA-403B-A6EB-4A85F0B30651%40me.com%3E
>> ), this will be the only one release allowed with the LGPL dependency. In
>> addition, based on the thread, a sentence added to the DISCLAIMER that
>> Toree depends on X which is licensed using Y and does not conform to Apache
>> License v2 would be needed. See Bertrand’s reply to the thread.
>>>  - jars should have a LICENSE and NOTICE ( seems like this is being
>> addressed in the pull request too )
>>>  - If there is a plan to publish binary-release.tar.gz and the other
>> tarball as convenience artifacts as part of the release, they will need
>> their own LICENSE and NOTICE files depending on what each of them are
>> bundling. This is usually where most podlings trip up.
>>> 
>>> thanks
>>> — Hitesh
>>> 
>>>> On Apr 5, 2016, at 3:10 PM, Gino Bustelo <gi...@bustelos.com> wrote:
>>>> 
>>>> Thanks Hitesh... would you be available to take a look at all we are
>>>> covering in the  PR #13 <
>> https://github.com/apache/incubator-toree/pull/13>.
>>>> Would be great to get an idea if we are going in the right direction
>>>> regarding LICENSE/NOTICE files and what is needed extra due to LGPL
>>>> dependency.
>>>> 
>>>> I think once we got signing done... all the pieces are in place to
>> create
>>>> all the assets that will be released.
>>>> 
>>>>> On Tue, Apr 5, 2016 at 3:43 PM, Hitesh Shah <hi...@apache.org> wrote:
>>>>> 
>>>>> For snapshot versions, I believe build tools are allowed to publish to
>> the
>>>>> snapshot repo as needed. jenkins builds already support this and I am
>>>>> guessing travis should have similar provisions.
>>>>> 
>>>>> For releases ( with a disclaimer as binary artifacts are not considered
>>>>> part of an official release), the binary convenience artifacts would be
>>>>> publish via dist.apache.org. The general approach is to publish an RC
>> to
>>>>> dist.apache/dev , get it voted upon by the community/PPMC ( followed
>> by an
>>>>> IPMC vote on general@incubator ) and then move to /release after the
>> vote
>>>>> is successful. As part of the RC creation, the release manager would
>> do an
>>>>> appropriate mvn deploy ( this will go into a staging repo ) and also
>> push
>>>>> the bits to dist.apache.org - both of which need to be signed.
>>>>> 
>>>>> Will need to check more on travis and whether a tool can publish bits
>> as
>>>>> all releases are meant to be signed by someone from the PPMC and using
>> a
>>>>> tool would imply providing your secret keys to the tool.
>>>>> 
>>>>> — Hitesh
>>>>> 
>>>>>> On Apr 5, 2016, at 7:23 AM, Gino Bustelo <gi...@bustelos.com> wrote:
>>>>>> 
>>>>>> We are getting close to completing work to our build scripts (PR #13
>>>>>> <https://github.com/apache/incubator-toree/pull/13>) to make the
>> project
>>>>>> follow the Apache release criteria that we've been able to find
>> through
>>>>>> search. Mainly auditing license headers, POM content, jar generation
>> with
>>>>>> NOTICE/LICENSE files, etc.
>>>>>> 
>>>>>> At this point we need someone with experience that can verify all the
>>>>> steps
>>>>>> we've done. Also, it is not clear to me what the process is to getting
>>>>> all
>>>>>> the assets published for a release vote. Several question are:
>>>>>> 
>>>>>> 1. Can publishing of assets be automated using Travis? Including maven
>>>>>> publish, and binary package distribution.
>>>>>> 2. Where do we publish binary packages? Not talking about JARs,
>> rather a
>>>>>> package with libraries and scripts to start/run Toree.
>>>>>> 
>>>>>> Any help is appreciated...
>>>>>> 
>>>>>> Thanks,
>>>>>> Gino
>>> 
>> 


Re: Help from Mentors

Posted by Hitesh Shah <hi...@apache.org>.
Thats actually required for any bundled dependency that has a non ALv2 license even the permissible ones such as BSD, MIT, etc ( not only LGPL ones ). The top-level license file is meant to call out the licenses for all the things that are being bundled. 

To summarize for the license files - depending on what is being bundled, the license file for the bundle should have either the full contents of the non-ALv2 licenses or pointers to the full text within the bundle itself ( cannot be a url). The Notice file is a trial-and-error at best to try and go through each dependency and figure out if the notice file needs updates. This is needed with the CDDL license for example ( based on looking at other projects ) as it requires a pointer to the actual source code for the CDDL jar that is being bundled ( https://tldrlegal.com/license/common-development-and-distribution-license-(cddl-1.0)-explained )

https://github.com/apache/spark seems to have a good handle on the license/notice files which could be used as helper guidelines. Although not really the best example to follow, you can take a look at https://github.com/apache/tez/tree/master/tez-dist/dist-files to see what we have done for the binary artifacts. We have the jars listed in the license file for now to aid a helper script to ensure that we are covering all the bundled artifacts. https://github.com/apache/lens/tree/master/bin-dist-files is another good example. 

thanks
— Hitesh

On Apr 8, 2016, at 9:03 AM, Gino Bustelo <gi...@bustelos.com> wrote:

> I'm reading https://github.com/zeromq/jeromq/blob/master/COPYING.LESSER#L91 and
> seems to me that we need to ship our bin distros with copies of the LGPL
> license. What is you all read?
> 
> On Thu, Apr 7, 2016 at 6:00 PM, Gino Bustelo <lb...@gmail.com> wrote:
> 
>> @hitesh
>> 
>> Awesome summary. This helps a ton. It confirms what we about to do with
>> License/Notices files.
>> 
>> 
>> Thanks
>> 
>> Gino B.
>> 
>>> On Apr 6, 2016, at 6:07 PM, Hitesh Shah <hi...@apache.org> wrote:
>>> 
>>> Will take a look.
>>> 
>>> Some general comments in the meantime:
>>>  - version should have incubating. tar balls should be versioned and
>> have incubating as part of their names ( this seems to be getting addressed
>> in the pull request )
>>>  - the main LICENSE and NOTICE are for a source release. This means if
>> there are any files part of the source release ( javascript, fonts, etc )
>> which are checked in as part of the codebase that have a different license
>> should be checked to see if any updates are needed to the main LICENSE and
>> NOTICE files.
>>>  - Based on the thread (
>> http://mail-archives.apache.org/mod_mbox/incubator-general/201602.mbox/%3C5F118AA0-4ADA-403B-A6EB-4A85F0B30651%40me.com%3E
>> ), this will be the only one release allowed with the LGPL dependency. In
>> addition, based on the thread, a sentence added to the DISCLAIMER that
>> Toree depends on X which is licensed using Y and does not conform to Apache
>> License v2 would be needed. See Bertrand’s reply to the thread.
>>>  - jars should have a LICENSE and NOTICE ( seems like this is being
>> addressed in the pull request too )
>>>  - If there is a plan to publish binary-release.tar.gz and the other
>> tarball as convenience artifacts as part of the release, they will need
>> their own LICENSE and NOTICE files depending on what each of them are
>> bundling. This is usually where most podlings trip up.
>>> 
>>> thanks
>>> — Hitesh
>>> 
>>>> On Apr 5, 2016, at 3:10 PM, Gino Bustelo <gi...@bustelos.com> wrote:
>>>> 
>>>> Thanks Hitesh... would you be available to take a look at all we are
>>>> covering in the  PR #13 <
>> https://github.com/apache/incubator-toree/pull/13>.
>>>> Would be great to get an idea if we are going in the right direction
>>>> regarding LICENSE/NOTICE files and what is needed extra due to LGPL
>>>> dependency.
>>>> 
>>>> I think once we got signing done... all the pieces are in place to
>> create
>>>> all the assets that will be released.
>>>> 
>>>>> On Tue, Apr 5, 2016 at 3:43 PM, Hitesh Shah <hi...@apache.org> wrote:
>>>>> 
>>>>> For snapshot versions, I believe build tools are allowed to publish to
>> the
>>>>> snapshot repo as needed. jenkins builds already support this and I am
>>>>> guessing travis should have similar provisions.
>>>>> 
>>>>> For releases ( with a disclaimer as binary artifacts are not considered
>>>>> part of an official release), the binary convenience artifacts would be
>>>>> publish via dist.apache.org. The general approach is to publish an RC
>> to
>>>>> dist.apache/dev , get it voted upon by the community/PPMC ( followed
>> by an
>>>>> IPMC vote on general@incubator ) and then move to /release after the
>> vote
>>>>> is successful. As part of the RC creation, the release manager would
>> do an
>>>>> appropriate mvn deploy ( this will go into a staging repo ) and also
>> push
>>>>> the bits to dist.apache.org - both of which need to be signed.
>>>>> 
>>>>> Will need to check more on travis and whether a tool can publish bits
>> as
>>>>> all releases are meant to be signed by someone from the PPMC and using
>> a
>>>>> tool would imply providing your secret keys to the tool.
>>>>> 
>>>>> — Hitesh
>>>>> 
>>>>>> On Apr 5, 2016, at 7:23 AM, Gino Bustelo <gi...@bustelos.com> wrote:
>>>>>> 
>>>>>> We are getting close to completing work to our build scripts (PR #13
>>>>>> <https://github.com/apache/incubator-toree/pull/13>) to make the
>> project
>>>>>> follow the Apache release criteria that we've been able to find
>> through
>>>>>> search. Mainly auditing license headers, POM content, jar generation
>> with
>>>>>> NOTICE/LICENSE files, etc.
>>>>>> 
>>>>>> At this point we need someone with experience that can verify all the
>>>>> steps
>>>>>> we've done. Also, it is not clear to me what the process is to getting
>>>>> all
>>>>>> the assets published for a release vote. Several question are:
>>>>>> 
>>>>>> 1. Can publishing of assets be automated using Travis? Including maven
>>>>>> publish, and binary package distribution.
>>>>>> 2. Where do we publish binary packages? Not talking about JARs,
>> rather a
>>>>>> package with libraries and scripts to start/run Toree.
>>>>>> 
>>>>>> Any help is appreciated...
>>>>>> 
>>>>>> Thanks,
>>>>>> Gino
>>> 
>> 


Re: Help from Mentors

Posted by Gino Bustelo <gi...@bustelos.com>.
I'm reading https://github.com/zeromq/jeromq/blob/master/COPYING.LESSER#L91 and
seems to me that we need to ship our bin distros with copies of the LGPL
license. What is you all read?

On Thu, Apr 7, 2016 at 6:00 PM, Gino Bustelo <lb...@gmail.com> wrote:

> @hitesh
>
> Awesome summary. This helps a ton. It confirms what we about to do with
> License/Notices files.
>
>
> Thanks
>
> Gino B.
>
> > On Apr 6, 2016, at 6:07 PM, Hitesh Shah <hi...@apache.org> wrote:
> >
> > Will take a look.
> >
> > Some general comments in the meantime:
> >   - version should have incubating. tar balls should be versioned and
> have incubating as part of their names ( this seems to be getting addressed
> in the pull request )
> >   - the main LICENSE and NOTICE are for a source release. This means if
> there are any files part of the source release ( javascript, fonts, etc )
> which are checked in as part of the codebase that have a different license
> should be checked to see if any updates are needed to the main LICENSE and
> NOTICE files.
> >   - Based on the thread (
> http://mail-archives.apache.org/mod_mbox/incubator-general/201602.mbox/%3C5F118AA0-4ADA-403B-A6EB-4A85F0B30651%40me.com%3E
> ), this will be the only one release allowed with the LGPL dependency. In
> addition, based on the thread, a sentence added to the DISCLAIMER that
> Toree depends on X which is licensed using Y and does not conform to Apache
> License v2 would be needed. See Bertrand’s reply to the thread.
> >   - jars should have a LICENSE and NOTICE ( seems like this is being
> addressed in the pull request too )
> >   - If there is a plan to publish binary-release.tar.gz and the other
> tarball as convenience artifacts as part of the release, they will need
> their own LICENSE and NOTICE files depending on what each of them are
> bundling. This is usually where most podlings trip up.
> >
> > thanks
> > — Hitesh
> >
> >> On Apr 5, 2016, at 3:10 PM, Gino Bustelo <gi...@bustelos.com> wrote:
> >>
> >> Thanks Hitesh... would you be available to take a look at all we are
> >> covering in the  PR #13 <
> https://github.com/apache/incubator-toree/pull/13>.
> >> Would be great to get an idea if we are going in the right direction
> >> regarding LICENSE/NOTICE files and what is needed extra due to LGPL
> >> dependency.
> >>
> >> I think once we got signing done... all the pieces are in place to
> create
> >> all the assets that will be released.
> >>
> >>> On Tue, Apr 5, 2016 at 3:43 PM, Hitesh Shah <hi...@apache.org> wrote:
> >>>
> >>> For snapshot versions, I believe build tools are allowed to publish to
> the
> >>> snapshot repo as needed. jenkins builds already support this and I am
> >>> guessing travis should have similar provisions.
> >>>
> >>> For releases ( with a disclaimer as binary artifacts are not considered
> >>> part of an official release), the binary convenience artifacts would be
> >>> publish via dist.apache.org. The general approach is to publish an RC
> to
> >>> dist.apache/dev , get it voted upon by the community/PPMC ( followed
> by an
> >>> IPMC vote on general@incubator ) and then move to /release after the
> vote
> >>> is successful. As part of the RC creation, the release manager would
> do an
> >>> appropriate mvn deploy ( this will go into a staging repo ) and also
> push
> >>> the bits to dist.apache.org - both of which need to be signed.
> >>>
> >>> Will need to check more on travis and whether a tool can publish bits
> as
> >>> all releases are meant to be signed by someone from the PPMC and using
> a
> >>> tool would imply providing your secret keys to the tool.
> >>>
> >>> — Hitesh
> >>>
> >>>> On Apr 5, 2016, at 7:23 AM, Gino Bustelo <gi...@bustelos.com> wrote:
> >>>>
> >>>> We are getting close to completing work to our build scripts (PR #13
> >>>> <https://github.com/apache/incubator-toree/pull/13>) to make the
> project
> >>>> follow the Apache release criteria that we've been able to find
> through
> >>>> search. Mainly auditing license headers, POM content, jar generation
> with
> >>>> NOTICE/LICENSE files, etc.
> >>>>
> >>>> At this point we need someone with experience that can verify all the
> >>> steps
> >>>> we've done. Also, it is not clear to me what the process is to getting
> >>> all
> >>>> the assets published for a release vote. Several question are:
> >>>>
> >>>> 1. Can publishing of assets be automated using Travis? Including maven
> >>>> publish, and binary package distribution.
> >>>> 2. Where do we publish binary packages? Not talking about JARs,
> rather a
> >>>> package with libraries and scripts to start/run Toree.
> >>>>
> >>>> Any help is appreciated...
> >>>>
> >>>> Thanks,
> >>>> Gino
> >
>

Re: Help from Mentors

Posted by Gino Bustelo <lb...@gmail.com>.
@hitesh

Awesome summary. This helps a ton. It confirms what we about to do with License/Notices files. 


Thanks

Gino B.

> On Apr 6, 2016, at 6:07 PM, Hitesh Shah <hi...@apache.org> wrote:
> 
> Will take a look. 
> 
> Some general comments in the meantime: 
>   - version should have incubating. tar balls should be versioned and have incubating as part of their names ( this seems to be getting addressed in the pull request )
>   - the main LICENSE and NOTICE are for a source release. This means if there are any files part of the source release ( javascript, fonts, etc ) which are checked in as part of the codebase that have a different license should be checked to see if any updates are needed to the main LICENSE and NOTICE files. 
>   - Based on the thread ( http://mail-archives.apache.org/mod_mbox/incubator-general/201602.mbox/%3C5F118AA0-4ADA-403B-A6EB-4A85F0B30651%40me.com%3E ), this will be the only one release allowed with the LGPL dependency. In addition, based on the thread, a sentence added to the DISCLAIMER that Toree depends on X which is licensed using Y and does not conform to Apache License v2 would be needed. See Bertrand’s reply to the thread. 
>   - jars should have a LICENSE and NOTICE ( seems like this is being addressed in the pull request too )
>   - If there is a plan to publish binary-release.tar.gz and the other tarball as convenience artifacts as part of the release, they will need their own LICENSE and NOTICE files depending on what each of them are bundling. This is usually where most podlings trip up.
> 
> thanks
> — Hitesh
> 
>> On Apr 5, 2016, at 3:10 PM, Gino Bustelo <gi...@bustelos.com> wrote:
>> 
>> Thanks Hitesh... would you be available to take a look at all we are
>> covering in the  PR #13 <https://github.com/apache/incubator-toree/pull/13>.
>> Would be great to get an idea if we are going in the right direction
>> regarding LICENSE/NOTICE files and what is needed extra due to LGPL
>> dependency.
>> 
>> I think once we got signing done... all the pieces are in place to create
>> all the assets that will be released.
>> 
>>> On Tue, Apr 5, 2016 at 3:43 PM, Hitesh Shah <hi...@apache.org> wrote:
>>> 
>>> For snapshot versions, I believe build tools are allowed to publish to the
>>> snapshot repo as needed. jenkins builds already support this and I am
>>> guessing travis should have similar provisions.
>>> 
>>> For releases ( with a disclaimer as binary artifacts are not considered
>>> part of an official release), the binary convenience artifacts would be
>>> publish via dist.apache.org. The general approach is to publish an RC to
>>> dist.apache/dev , get it voted upon by the community/PPMC ( followed by an
>>> IPMC vote on general@incubator ) and then move to /release after the vote
>>> is successful. As part of the RC creation, the release manager would do an
>>> appropriate mvn deploy ( this will go into a staging repo ) and also push
>>> the bits to dist.apache.org - both of which need to be signed.
>>> 
>>> Will need to check more on travis and whether a tool can publish bits as
>>> all releases are meant to be signed by someone from the PPMC and using a
>>> tool would imply providing your secret keys to the tool.
>>> 
>>> — Hitesh
>>> 
>>>> On Apr 5, 2016, at 7:23 AM, Gino Bustelo <gi...@bustelos.com> wrote:
>>>> 
>>>> We are getting close to completing work to our build scripts (PR #13
>>>> <https://github.com/apache/incubator-toree/pull/13>) to make the project
>>>> follow the Apache release criteria that we've been able to find through
>>>> search. Mainly auditing license headers, POM content, jar generation with
>>>> NOTICE/LICENSE files, etc.
>>>> 
>>>> At this point we need someone with experience that can verify all the
>>> steps
>>>> we've done. Also, it is not clear to me what the process is to getting
>>> all
>>>> the assets published for a release vote. Several question are:
>>>> 
>>>> 1. Can publishing of assets be automated using Travis? Including maven
>>>> publish, and binary package distribution.
>>>> 2. Where do we publish binary packages? Not talking about JARs, rather a
>>>> package with libraries and scripts to start/run Toree.
>>>> 
>>>> Any help is appreciated...
>>>> 
>>>> Thanks,
>>>> Gino
> 

Re: Help from Mentors

Posted by Hitesh Shah <hi...@apache.org>.
Will take a look. 

Some general comments in the meantime: 
   - version should have incubating. tar balls should be versioned and have incubating as part of their names ( this seems to be getting addressed in the pull request )
   - the main LICENSE and NOTICE are for a source release. This means if there are any files part of the source release ( javascript, fonts, etc ) which are checked in as part of the codebase that have a different license should be checked to see if any updates are needed to the main LICENSE and NOTICE files. 
   - Based on the thread ( http://mail-archives.apache.org/mod_mbox/incubator-general/201602.mbox/%3C5F118AA0-4ADA-403B-A6EB-4A85F0B30651%40me.com%3E ), this will be the only one release allowed with the LGPL dependency. In addition, based on the thread, a sentence added to the DISCLAIMER that Toree depends on X which is licensed using Y and does not conform to Apache License v2 would be needed. See Bertrand’s reply to the thread. 
   - jars should have a LICENSE and NOTICE ( seems like this is being addressed in the pull request too )
   - If there is a plan to publish binary-release.tar.gz and the other tarball as convenience artifacts as part of the release, they will need their own LICENSE and NOTICE files depending on what each of them are bundling. This is usually where most podlings trip up.

thanks
— Hitesh

On Apr 5, 2016, at 3:10 PM, Gino Bustelo <gi...@bustelos.com> wrote:

> Thanks Hitesh... would you be available to take a look at all we are
> covering in the  PR #13 <https://github.com/apache/incubator-toree/pull/13>.
> Would be great to get an idea if we are going in the right direction
> regarding LICENSE/NOTICE files and what is needed extra due to LGPL
> dependency.
> 
> I think once we got signing done... all the pieces are in place to create
> all the assets that will be released.
> 
> On Tue, Apr 5, 2016 at 3:43 PM, Hitesh Shah <hi...@apache.org> wrote:
> 
>> For snapshot versions, I believe build tools are allowed to publish to the
>> snapshot repo as needed. jenkins builds already support this and I am
>> guessing travis should have similar provisions.
>> 
>> For releases ( with a disclaimer as binary artifacts are not considered
>> part of an official release), the binary convenience artifacts would be
>> publish via dist.apache.org. The general approach is to publish an RC to
>> dist.apache/dev , get it voted upon by the community/PPMC ( followed by an
>> IPMC vote on general@incubator ) and then move to /release after the vote
>> is successful. As part of the RC creation, the release manager would do an
>> appropriate mvn deploy ( this will go into a staging repo ) and also push
>> the bits to dist.apache.org - both of which need to be signed.
>> 
>> Will need to check more on travis and whether a tool can publish bits as
>> all releases are meant to be signed by someone from the PPMC and using a
>> tool would imply providing your secret keys to the tool.
>> 
>> — Hitesh
>> 
>> On Apr 5, 2016, at 7:23 AM, Gino Bustelo <gi...@bustelos.com> wrote:
>> 
>>> We are getting close to completing work to our build scripts (PR #13
>>> <https://github.com/apache/incubator-toree/pull/13>) to make the project
>>> follow the Apache release criteria that we've been able to find through
>>> search. Mainly auditing license headers, POM content, jar generation with
>>> NOTICE/LICENSE files, etc.
>>> 
>>> At this point we need someone with experience that can verify all the
>> steps
>>> we've done. Also, it is not clear to me what the process is to getting
>> all
>>> the assets published for a release vote. Several question are:
>>> 
>>> 1. Can publishing of assets be automated using Travis? Including maven
>>> publish, and binary package distribution.
>>> 2. Where do we publish binary packages? Not talking about JARs, rather a
>>> package with libraries and scripts to start/run Toree.
>>> 
>>> Any help is appreciated...
>>> 
>>> Thanks,
>>> Gino
>> 
>> 


Re: Help from Mentors

Posted by Gino Bustelo <gi...@bustelos.com>.
Thanks Hitesh... would you be available to take a look at all we are
covering in the  PR #13 <https://github.com/apache/incubator-toree/pull/13>.
Would be great to get an idea if we are going in the right direction
regarding LICENSE/NOTICE files and what is needed extra due to LGPL
dependency.

I think once we got signing done... all the pieces are in place to create
all the assets that will be released.

On Tue, Apr 5, 2016 at 3:43 PM, Hitesh Shah <hi...@apache.org> wrote:

> For snapshot versions, I believe build tools are allowed to publish to the
> snapshot repo as needed. jenkins builds already support this and I am
> guessing travis should have similar provisions.
>
> For releases ( with a disclaimer as binary artifacts are not considered
> part of an official release), the binary convenience artifacts would be
> publish via dist.apache.org. The general approach is to publish an RC to
> dist.apache/dev , get it voted upon by the community/PPMC ( followed by an
> IPMC vote on general@incubator ) and then move to /release after the vote
> is successful. As part of the RC creation, the release manager would do an
> appropriate mvn deploy ( this will go into a staging repo ) and also push
> the bits to dist.apache.org - both of which need to be signed.
>
> Will need to check more on travis and whether a tool can publish bits as
> all releases are meant to be signed by someone from the PPMC and using a
> tool would imply providing your secret keys to the tool.
>
> — Hitesh
>
> On Apr 5, 2016, at 7:23 AM, Gino Bustelo <gi...@bustelos.com> wrote:
>
> > We are getting close to completing work to our build scripts (PR #13
> > <https://github.com/apache/incubator-toree/pull/13>) to make the project
> > follow the Apache release criteria that we've been able to find through
> > search. Mainly auditing license headers, POM content, jar generation with
> > NOTICE/LICENSE files, etc.
> >
> > At this point we need someone with experience that can verify all the
> steps
> > we've done. Also, it is not clear to me what the process is to getting
> all
> > the assets published for a release vote. Several question are:
> >
> > 1. Can publishing of assets be automated using Travis? Including maven
> > publish, and binary package distribution.
> > 2. Where do we publish binary packages? Not talking about JARs, rather a
> > package with libraries and scripts to start/run Toree.
> >
> > Any help is appreciated...
> >
> > Thanks,
> > Gino
>
>

Re: Help from Mentors

Posted by Hitesh Shah <hi...@apache.org>.
For snapshot versions, I believe build tools are allowed to publish to the snapshot repo as needed. jenkins builds already support this and I am guessing travis should have similar provisions.

For releases ( with a disclaimer as binary artifacts are not considered part of an official release), the binary convenience artifacts would be publish via dist.apache.org. The general approach is to publish an RC to dist.apache/dev , get it voted upon by the community/PPMC ( followed by an IPMC vote on general@incubator ) and then move to /release after the vote is successful. As part of the RC creation, the release manager would do an appropriate mvn deploy ( this will go into a staging repo ) and also push the bits to dist.apache.org - both of which need to be signed. 

Will need to check more on travis and whether a tool can publish bits as all releases are meant to be signed by someone from the PPMC and using a tool would imply providing your secret keys to the tool. 

— Hitesh

On Apr 5, 2016, at 7:23 AM, Gino Bustelo <gi...@bustelos.com> wrote:

> We are getting close to completing work to our build scripts (PR #13
> <https://github.com/apache/incubator-toree/pull/13>) to make the project
> follow the Apache release criteria that we've been able to find through
> search. Mainly auditing license headers, POM content, jar generation with
> NOTICE/LICENSE files, etc.
> 
> At this point we need someone with experience that can verify all the steps
> we've done. Also, it is not clear to me what the process is to getting all
> the assets published for a release vote. Several question are:
> 
> 1. Can publishing of assets be automated using Travis? Including maven
> publish, and binary package distribution.
> 2. Where do we publish binary packages? Not talking about JARs, rather a
> package with libraries and scripts to start/run Toree.
> 
> Any help is appreciated...
> 
> Thanks,
> Gino


Re: Help from Mentors

Posted by Gino Bustelo <gi...@bustelos.com>.
Thanks Corey!

On Tue, Apr 5, 2016 at 9:51 AM, Corey Stubbs <ca...@gmail.com> wrote:

> I found this article
> <http://incubator.apache.org/incubation/Incubation_Policy.html#Releases>
> explaining podling releases. It appears we should our own directory, under
> http://www.apache.org/dist/incubator/, to distribute our releases. This
> <http://www.apache.org/dev/release-publishing.html> seems to be the
> complete release process for binary package for apache projects. I found
> all of these links (and more) on the dev package under the releases section
> <http://www.apache.org/dev/#releases>.
>
>
>
> On Tue, Apr 5, 2016 at 9:24 AM Gino Bustelo <gi...@bustelos.com> wrote:
>
> > We are getting close to completing work to our build scripts (PR #13
> > <https://github.com/apache/incubator-toree/pull/13>) to make the project
> > follow the Apache release criteria that we've been able to find through
> > search. Mainly auditing license headers, POM content, jar generation with
> > NOTICE/LICENSE files, etc.
> >
> > At this point we need someone with experience that can verify all the
> steps
> > we've done. Also, it is not clear to me what the process is to getting
> all
> > the assets published for a release vote. Several question are:
> >
> > 1. Can publishing of assets be automated using Travis? Including maven
> > publish, and binary package distribution.
> > 2. Where do we publish binary packages? Not talking about JARs, rather a
> > package with libraries and scripts to start/run Toree.
> >
> > Any help is appreciated...
> >
> > Thanks,
> > Gino
> >
>

Re: Help from Mentors

Posted by Corey Stubbs <ca...@gmail.com>.
I found this article
<http://incubator.apache.org/incubation/Incubation_Policy.html#Releases>
explaining podling releases. It appears we should our own directory, under
http://www.apache.org/dist/incubator/, to distribute our releases. This
<http://www.apache.org/dev/release-publishing.html> seems to be the
complete release process for binary package for apache projects. I found
all of these links (and more) on the dev package under the releases section
<http://www.apache.org/dev/#releases>.



On Tue, Apr 5, 2016 at 9:24 AM Gino Bustelo <gi...@bustelos.com> wrote:

> We are getting close to completing work to our build scripts (PR #13
> <https://github.com/apache/incubator-toree/pull/13>) to make the project
> follow the Apache release criteria that we've been able to find through
> search. Mainly auditing license headers, POM content, jar generation with
> NOTICE/LICENSE files, etc.
>
> At this point we need someone with experience that can verify all the steps
> we've done. Also, it is not clear to me what the process is to getting all
> the assets published for a release vote. Several question are:
>
> 1. Can publishing of assets be automated using Travis? Including maven
> publish, and binary package distribution.
> 2. Where do we publish binary packages? Not talking about JARs, rather a
> package with libraries and scripts to start/run Toree.
>
> Any help is appreciated...
>
> Thanks,
> Gino
>