incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: [VOTE] publish openjpa 0.9.6-incubating release
Date Sat, 18 Nov 2006 18:40:45 GMT
Hi Robert,

I just have to give you a very public THANK YOU for your assistance  
to projects in the incubator. I personally look forward to reading  
your posts because I learn so much from them. I think you are a model  
for how to give constructive feedback and nurture projects. Please  
keep up the terrific work.



On Nov 18, 2006, at 6:49 AM, robert burrell donkin wrote:

> On 11/17/06, Marc Prud'hommeaux <> wrote:
>> On Nov 16, 2006, at 12:57 PM, robert burrell donkin wrote:
>> > On 11/16/06, Marc Prud'hommeaux <> wrote:
> <snip>
>> > i have some issues i'd like to see fixed plus less important  
>> issues,
>> > some questions i'd like answered and some comments just FYI
>> >
>> > -- issues (i would like to see fixed) --
> <snip>
>> > openjpa distributes some jars in the binary. NOTICE.txt is ok (but
>> > note now asks that  
>> apache
>> > collective copyright is included) but their licenses are not  
>> included
>> > in LICENSE.txt. see
>> > for example.
>> The only two non-ASF jars in the distribution are serp-1.11.0.jar
>> (BSD license) and persistence-api-1.0.jar (Sun CDDL). I've added
>> their licenses into our LICENSE.txt. I'd appreciate if you could take
>> a glance at the text (at
>> openjpa/trunk/openjpa-project/LICENSE.txt ) and let me know if that
>> looks sufficient.
> looks good :-)
>> Also, I don't think I need to add the licenses for the ASF jars that
>> are included with the binaries. If I'm incorrect about that, please
>> let me know, and I'll paste in the text of their identical licenses
>> to our LICENSE.txt file.
> no need to add duplicate copies of each particular LICENSE
> the aim is to inform downstream users in particular packages about the
> LICENSE for each artifact distributed. this is good for both legal and
> social reasons. it's up to the project how they achieve this goal.
> there are other acceptable ways used but the example is a commonly
> used approach.
>> > source distribution is missing LICENSE, NOTICE and DISCLAIMER at  
>> the
>> > top level. (these probably need to be commit into svn.)
>> As an exact snapshot of the buildable sources, these files were
>> included in the "openjpa-project" sub-directory of the sources
>> package. Reviewing
>> headers.html#notice , I see that they need to be included in the top
>> directory of any artifact, so I've added a directive to the source
>> distribution build to add them there.
> (i personally distrust source distribution processing of any kind. i
> worry about reproducability. but this is a matter for the project so)
> that should be ok
>> > -- minor issues --
>> >
>> >
>> > incubating/src/site/apt/*.apt
>> > lack license headers. apt supports comments so these should  
>> probably
>> > have headers.
>> I've added license headers to these files. I hadn't realized that apt
>> supported comments.
> seems to be an under-advertised feature :-)
>> > -- questions --
>> >
>> > i can't find LICENSE, NOTICE or DISCLAIMER in
>> > openjpa-all-0.9.6-incubating.jar. did you intend to prevent  
>> official
>> > distribution through maven repositories?
>> Oops ... we missed putting these in. I've corrected this for the
>> LICENSE.txt and NOTICE.txt files. However, looking at http://
>> , I don't see any
>> mention of including the DISCLAIMER file ... is there somewhere else
>> that mentions that that file should be included in jars (or other
>> binary artifacts)?
> you won't find it since this is not a general requirement for apache
> releases :-)
> the IPMC requires a disclaimer text is distributed with each artifact.
> i guessed that since openjpa uses a DISCLAIMER.txt that it would make
> sense to include this. feel free to shoot me down if you already
> include the disclaimer in some other form.
>> > (RAT)
>> >
>> >
>> > incubating/openjpa-jdbc/src/main/resources/org/apache/openjpa/jdbc/
>> > schema/schemas-doctype.rsrc
>> > has no license header. is this a generated file?
>> No, but I don't think the format supports comments.
> i'm going to assume that it's a DTD
> AIUI it's possible to include xml style comments (<!-- -->) in all
> parsed entities (those that start with a prolog for example <?xml
> version='1.0'?>) but i'm willing to stand corrected...
> this isn't a release stopper for me
>> >
>> > incubating/openjpa-persistence/src/main/resources/org/apache/
>> > openjpa/persistence/orm-xsd.rsrc
>> > has no license header. is this a generated file?
>> I'm not sure what to do about that one ... it is a cached copy of
>> which we use for
>> XML schema validation without having to go to the web (which would be
>> prohibitive). The original schema doesn't specify any license, and
>> I'm not sure what the implicit license would be, but I also wouldn't
>> feel right about sticking in an Apache license header for a file that
>> we obviously didn't create.
> exactly right: never just stick headers in anything without clear  
> provinence
>> Any thoughts?
> in the absence of any clear license, there is a link at the bottom of
> which says
> arguable,
> though, it's part of the RI which is probably LGPL'd.
> but all this seems far too flimsy for comfort
> i recommend taking this up on legal-discuss and (if possible)
> contacting sun directly for clear guidance about their intended
> license. it would be cleaner and clearer if they embedded the license
> in the document or (at least) included the information in
> unfortunately, this sounds like it might take a while to sort out :-/
> might be quicker just to create a clean room implementation direct
> from the specification
>> > -- comments --
>> >
>> > --- notes and suggestions (for future reference) ---
>> >
>> > there is no need to create sums for detached signatures.
>> Maven seems to automatically attach .md5 and .sha1 checksums to all
>> uploaded artifacts. Since we are generating the .asc signatures in
>> the Maven process, it seems to include these in the list of artifacts
>> to sign. There doesn't seem to be any way to disable this, and the
>> convenience gained by having these files generated and uploaded as
>> part of the Maven build process outweighed the annoyance of having
>> these vestigial checksums lying around (IMO).
> fine
>> > some users (typically on *nix) prefer either bz2'd or tar.gz's
>> > distributions. creating additional artifacts is quick and easy  
>> so this
>> > is an easy way to make life just a little easier for some users.
>> We briefly discussed this on the open-jpa-list. While it is certainly
>> de-facto convention to release under both .zip and .tar.gz packaging
>> types, the only compelling reason to do so appears to be that UNIX
>> executable permissions are lost in the zip format. Since we don't
>> have any executables in the openjpa distribution, there doesn't seem
>> to be much reason to have additional packaging formats.
>> We'd be interested in knowing if there are other advantages to having
>> multiple packaging mechanisms, though.
> releases are important guerrilla advertising for a project :-)
> user expectation and convenience. users expect projects that produce
> just zip'd distributions to be windows centric. distributions with
> alternative compression are easy and quick to produce. so IMHO it
> makes sense to distribute .tar.gz'd as well as zip'd just to make
> *nix'ers feel at home. good for linux-centric grassroots news channels
> (such as freshmeat) as well.
> but it's for the community to decide so it's the debate that's  
> important
> <snip>
>> > there is no RELEASE_NOTES in the base directory. for open source
>> > projects, these serve as an important communication to users. the
>> > content will often serve for reuse in announcements and other
>> > grassroots publicity. consider creating them for the next release.
>> We don't have one since this is our initial release, so the whole
>> package is effectively one big release note :)
> RELEASE_NOTES are important guerrilla advertising for a project :-)
> the content is often reused for announcements and for grassroots news
> channels such as freshmeat. release notes should describe a project's
> purpose and aims, how people can get involved, list sources of
> information and give some general information about the project's
> plans.
> - robert
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Craig Russell

View raw message