felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: NOTICE/DEPENDENCIES files for Felix subproject releases
Date Wed, 09 Jun 2010 17:58:25 GMT
On 6/9/10 13:55, Richard S. Hall wrote:
> With the latest release of the framework and Gogo modules, we've tried 
> to update the release process for how we handle the NOTICE file. Our 
> past usage is apparently not aligned with the intended usage, where 
> the NOTICE file should only contained notices for included third-party 
> software whose license requires notice. Our new approach (for now) is 
> this:
>   1. Include a NOTICE file which contains only required notices.
>   2. Include a DEPENDENCIES file which contains our acknowledgments
>      about the software the subproject uses.
> For the most part, this isn't a major hassle and largely boils down to 
> this:
>   1. Rename the current NOTICE file to DEPENDENCIES.
>   2. Create a new NOTICE file that contains notices only for the "used"
>      software requiring notices in the DEPENDENCIES file.

Sorry, that should say: "included" software, not "used" software...
> Although the new DEPENDENCIES file is very similar to the old NOTICE 
> file, the template is slightly different as indicated here:
> https://cwiki.apache.org/confluence/display/FELIX/DEPENDENCIES+file+template+%28PROPOSED%29

> Of course, in the long term we can try to move to automating the 
> generation of the NOTICE and/or DEPENDENCIES files, which would make 
> our lives simpler. If any subprojects currently are able to automate 
> this information, as long as the generated files contain information 
> consistent with what is proposed here, then the exact formatting is 
> not that important. But for hand generated files, follow this template.
> If you want to see examples, look in the framework or gogo subprojects.
> -> richard
> p.s. This is obviously all open for discussion to the specifics, but 
> until then we should use this approach for releases in an effort to 
> better align with Apache process (with perhaps the exception of Karaf 
> since if/when it goes TLP then its PMC will decide how to do releases).

View raw message