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 Thu, 10 Jun 2010 13:52:34 GMT
On 6/10/10 9:47, Guillaume Nodet wrote:
> I think we should keep the amount of legal files to the bare minimum, i.e.
> make sure the LICENSE and NOTICE files are correct wrt the ASF ways of doing
> things.  Anything else is not mandatory and imho, should be removed, unless
> generated, to avoid the extra work of maintaining those files for no real
> added value.
>    

Not sure to what you are referring, this is exactly what is being done 
now. The DEPENDENCIES file is not a legal file, so that is a non-issue. 
If you are saying you are against acknowledging the software we depend 
on, then we can have that discussion, but it has nothing to do with the 
legal files.

-> richard

> On Thu, Jun 10, 2010 at 15:41, Richard S. Hall<heavy@ungoverned.org>  wrote:
>
>    
>> On 6/10/10 9:03, Justin Edelson wrote:
>>
>>      
>>> On 6/10/10 8:54 AM, Richard S. Hall wrote:
>>>
>>>
>>>        
>>>> On 6/9/10 17:11, Justin Edelson wrote:
>>>>
>>>>
>>>>          
>>>>> Hmmm. When I looked at the framework DEPENDENCIES file, there was a
>>>>> reference to codehaus, but I didn't think the framework depends upon
>>>>> codehaus libraries, just some Maven plugin.
>>>>>
>>>>>
>>>>>            
>>>> I think it was the RAT plugin, but this has since moved to Apache, right?
>>>>
>>>>
>>>>          
>>> My (albeit very vague) understanding is that it is in the process of
>>> being moved. In any case, the framework pom still references the
>>> codehaus version.
>>>
>>>
>>>        
>> Yeah, that should probably be upgraded at some point.
>>
>>
>>   I think it very classy to acknowledge plugins like this. It just isn't
>>      
>>> clear to me that, based on your original email, that was your intent.
>>>
>>>
>>>        
>> As I said, we'll have to clear that up...when I find the time, I'll edit
>> the wiki page...
>>
>> ->  richard
>>
>>
>>   Justin
>>      
>>>
>>>
>>>        
>>>> ->   richard
>>>>
>>>>
>>>>
>>>>          
>>>>> Justin
>>>>>
>>>>> On Jun 9, 2010, at 4:49 PM, David Jencks<david_jencks@yahoo.com>
>>>>>   wrote:
>>>>>
>>>>>
>>>>>
>>>>>            
>>>>>> The DEPENDENCIES file is completely optional as far as apache policy
>>>>>> is concerned.  I wrote the maven code that generates these with the
>>>>>> intention of giving users hints about the other software that would
>>>>>> likely be needed to actually use the artifact containing the
>>>>>> DEPENDENCIES file.  As such, it only includes (appropriately scoped)
>>>>>> dependencies, not all the maven stuff that may have been used to
>>>>>> generate the artifact.
>>>>>>
>>>>>> Since felix is an osgi based project that uses osgi to hook up
>>>>>> bundles, and avoids require-bundle like the plague, and there's no
>>>>>> good reason to suppose that the maven dependencies will be the actual
>>>>>> providers of the required imports,  a strong case could be made that
>>>>>> felix should simply not include DEPENDENCIES files.
>>>>>>
>>>>>> thanks
>>>>>> david jencks
>>>>>>
>>>>>> On Jun 9, 2010, at 12:30 PM, Richard S. Hall wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>              
>>>>>>> On 6/9/10 14:52, Justin Edelson wrote:
>>>>>>>
>>>>>>>
>>>>>>>                
>>>>>>>> Richard-
>>>>>>>> Perhaps this is supposed to be obvious, but I think it would
be
>>>>>>>> helpful to
>>>>>>>> define the term "uses" with respect to the DEPENDENCIES file.
IIUC,
>>>>>>>> it
>>>>>>>> includes dependencies (in any scope) as well as software
executed
>>>>>>>> as part of
>>>>>>>> the build (i.e. Maven Plugins), but the inclusion of the
latter may
>>>>>>>> not be
>>>>>>>> intuitive.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                  
>>>>>>> True. We need to be clearer...
>>>>>>>
>>>>>>> ->   richard
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                
>>>>>>>> Justin
>>>>>>>>
>>>>>>>> On Wed, Jun 9, 2010 at 1:55 PM, Richard S.
>>>>>>>> Hall<heavy@ungoverned.org>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.
>>>>>>>>>
>>>>>>>>> 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).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                    
>>>>>>>>
>>>>>>>>                  
>>>>>>>                
>>>>>>              
>>>>>            
>>>        
>>      
>
>    

Mime
View raw message