shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <craig...@apache.org>
Subject Re: [VOTE] Release Shale version 1.0.4
Date Fri, 05 Jan 2007 07:32:44 GMT
On 1/4/07, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
>
> On 1/5/07, Craig McClanahan <craigmcc@apache.org> wrote:
> <snip/>
> >
> > What should also happen here is attribution in the NOTICE.txt file for
> > shale-tiger module too ... I'll look into the appropriate wording for
> that
> > and commit something soon.
> >
> <snap/>
>
> OK, I will be cutting the new artifacts in ~8 hours (I'll be away this
> weekend and would like to get the vote going before that).


Wow ... you get up early :-)

The mystery deepens a bit as I'm looking at the CVS logs for these files.  A
CDDL header was added (by a standard "add licenses before we open source"
sweep to both DTDs in August 2005, but was explicitly removed by a separate
commit in March 2006.  I'm not going to be able to resolve that before you
disappear for the weekend, but I know that these DTDs were *intended* to be
redistributable.  It's just that there is no way to know if a copyright
attribution is appropriate, since there is no copyright statement in the
files themselves.

What I'd suggest we do for 1.0.4 is go ahead and fix everything else, but do
nothing explicit about these two files.  There is ample precedent at Apache
for publishing them as part of a release, and if need be I can fall on my
sword within Sun if there are any issues -- but I'm sure there will not be
any ... the whole point of open sourcing the RIs (including the API stuff,
which includes the DTDs) was to eliminate barriers to *using* these kinds of
artifacts.

> Craig
> >
> > PS:  Rahul, don't forget to apply your cleanups based on Niall's
> comments to
> > the trunk too.  Otherwise, we'll need to go through this exercise again
> next
> > time :-).
> >
> <snip/>
>
> Yup, will do (I agree its best to do this immediately, for some reason
> I felt like porting the release related tweaks in one shot at the end
> ;-).


As long as they get included, I'm fine on the timing  :-)

> PPS:  I'm also +1 on removing the Cobertura reports from the release
> > version, although I do find the reports useful during development
> cycles.
> >
> >
>
> Tempted towards a "dev" profile for pushing out all reports
> (Cobertura, PMD, CPD, Checkstyle and what not) -- so (a) we don't get
> caught up in trying to sanitize all the bits these reports generate in
> the release distros and (b) its possible to generate a light version
> of the site for the documentation (but not reporting) bits.


I can see that POV ... and as long as we can convince Continuum to use the
"dev" profile on its continuous build runs, I'm fine.  The important thing
to me is that the coverage reports (in the case of this particular plugin)
are available to developers on a "continuous" basis.

Does publishing a GPL'd javascript file, on the Apache Shale website (but
not part of a downloadable artifact), cause a problem with the standard
"distribution" policy of what we can include in an artifact?  Nah ... it's
too late in the evening today for me to want to go there :-).

-Rahul
>


Craig

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