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.

Thanks,

Craig

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

> On 11/17/06, Marc Prud'hommeaux <mprudhom@apache.org> wrote:
>> On Nov 16, 2006, at 12:57 PM, robert burrell donkin wrote:
>> > On 11/16/06, Marc Prud'hommeaux <mprudhom@apache.org> 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 http://www.apache.org/legal/src-headers.html now asks that  
>> apache
>> > collective copyright is included) but their licenses are not  
>> included
>> > in LICENSE.txt. see
>> > http://incubator.apache.org/guides/examples/LICENSE 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 https://svn.apache.org/repos/asf/incubator/
>> 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 http://www.apache.org/legal/src-
>> 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 --
>> >
>> > http://svn.apache.org/repos/asf/incubator/openjpa/tags/0.9.6-
>> > 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://
>> www.apache.org/legal/src-headers.html#faq-binaries , 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)
>> >
>> > http://svn.apache.org/repos/asf/incubator/openjpa/tags/0.9.6-
>> > 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
>
>> > http://svn.apache.org/repos/asf/incubator/openjpa/tags/0.9.6-
>> > 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
>> http://java.sun.com/xml/ns/persistence/orm_1_0.xsd 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
> http://java.sun.com/xml/ns/persistence/ which says
> http://developers.sun.com/license/berkeley_license.html. 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
> http://java.sun.com/xml/ns/persistence.
>
> 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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

Craig Russell
clr@apache.org http://db.apache.org/jdo



Mime
View raw message