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 <g...@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 <hit...@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 <g...@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 >> >>
