incubator-etch-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From scott comer <wer...@mac.com>
Subject Re: etch 1.1.0 release candidate?
Date Tue, 26 May 2009 14:20:44 GMT
inline.

Niclas Hedhman wrote:
> On Tue, May 26, 2009 at 4:03 AM, scott comer <wert1y@mac.com> wrote:
>   
>> ok, the artifact name issue is resolved i think.
>>
>> i created a release tag:
>>
>> etch/releases/release-1.1.0-rc1
>>
>> artifacts posted here:
>>
>> http://people.apache.org/~sccomer/etch-1.1.0-rc1/
>>
>> what's left?
>>
>> run rat.
>> check out the notices and readme and release notes and stuff.
>> download and test the artifacts.
>>     
>
> 1. People in the Incubator will complain if the tag is not containing
> the 'incubating' word, so copy the one you have into a new name, and
> kill the old tag.
>   
nod.
> 2. Rat reports a lot of "????", which shows at the top as "unapproved
> licenses". For all files that supports comments, the Apache standard
> header should be used. Need to fix this.
>   
yes. i don't see any way to customize (despite words that say you can, 
must be in the source code
that i can do that) rat's list of file types that matter. *.vcproj and 
readme style text files would seem
to fall into the category of files that don't matter. i'm working on the 
complaints today to resolve the
legitimate issues.
> Since you don't distribute any of the "Dependencies", I would
> recommend that you rename it to "System Requirements". Apache allows
> system requirements of stuff with just about any license, whereas
> redistributed dependencies must be of certain kinds. My guess is that
> you codebase may actually "dependOn" velocity, so perhaps a bit
> surprise to see it not included in the distro. JavaCC is another one
> that should perhaps be redistributed (no problem, since it is BSD
> license) to simplify for users and hence stay as a "Dependency".
>   
not sure what you're saying here. we do distribute velocity in our 
binary image. because it is
needed at runtime by the compiler. we have no other runtime 
dependencies. the rest (javacc,
junit, apr, ant, etc.) are build dependencies. are you suggesting we 
should put those into our
source tree as well? (personally, i'd like that, as the current scheme 
has a pretty high barrier
to getting started and lots of twitchy settings to keep it working).

scott out


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message