james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: [mime4j] release plan for 0.3
Date Sun, 13 May 2007 22:50:09 GMT
robert burrell donkin ha scritto:
> not sure how critical it really is. apache tends to be loathed to take
> legal action. IIRC this arose around 5 years ago but i can't remember
> why. it can't have been that important or it would have been more
> widely known.
> 
> but it is good practice and worth adopting

Maven is all about spreading good practice and sharing a standard way to
do releases. So such a policy should be transmitted to the maven guys
first of all. If ASF committers could read somewhere "it is suggested by
ASF policies to include "apache-" as a prefix of every artifactId I
guess we would have much more "policy compliant" packages.

>> Please note that this is not to mean that I don't believe you, but
>> simply to tell to someone that I think this thing is important and this
>> should be documented and more widely communicated to newcomers.
> 
> not sure apache has a solution for this. i find that writing
> documentation is tough and takes a lot of time. there are only a
> limited number of other people who find any time for documentation.
> 
> it's easier (and usually quicker) to create technical solutions. when
> infra moves to using a proper release upload mechanism, the releases
> can be verified and any which don't meet policy can be rejected.

This would be cool, but this would increase the requirement of a policy
to be written :-)
E.g: maybe that if the maven2 guys was aware of this "prefix"/"trademark
" issue they could have decided to include the groupId in the name of
the resulting artifacts in the m2 repository.

I will try to do my homework and to post a message about this issue to
repository@apache list so to ping them about the issue and spread the word!

>> >> I believe the
>> >> source package containes the NOTICE/LICENSE.
>> >> About the svn source tree I posted a question on legal-discuss but I
>> >> received no answer about this:
>> >>
>> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200705.mbox/<463EFEEF.4080201@apache.org>
>>
>> >
>> > it's not a legal question but an infra question
>> >
>> > all apache releases require LICENSE and NOTICE. source releases should
>> > be the primary form of release for apache projects. source releases
>> > are formed by svn export. if the source lacks top level LICENSE and
>> > NOTICE files then it's hard to create compliant releases.
>>
>> the source package is generated via an mvn assembly (package) command
>> and it make sure to include an up-to-date NOTICE/LICENSE.
> 
> in that case, policy will be satisfied
> 
> IMHO it's not a real source release though, since it does not actually
> corresponding to anything that i can check out of svn. i sometimes
> worry about the reconstructability of maven source releases...

It is exactly the svn export with the only addition of NOTICE and
LICENSE that I think are required (by policies) to redistribute a
package. Also the "package concept" is not part of svn ;-)

>> Imho it is important to understand if the svn root tree is a requisite
>> or not because currently our NOTICE and LICENSE is generated by metadata
>> included in the POM and having also a non-automatically generated
>> artifact in the source tree will lead to duplication and much more easy
>> desynchronization.
> 
> the maven NOTICE generation stuff seems to be working much better now

In the same message I posted to legal-discuss I also asked other
questions about the content of NOTICE and LICENSE as my knowledge about
what to put in NOTICE and LICENSE was different by the knowledge of the
m2 committer that created the remote resources plugin (that generates
the NOTICE and LICENSE). The weird thing is that our knowledge has been
generated by discussions with Cliff, for both of us..

>> So I'd like to know what is the legal requirement and then to be able to
>> decide how to better accomplish it technically ;-)
> 
> it's a consequence of a policy requirement (not a legal one)

Thank you for explaining: I often merge the issues, because I classify
anything not technical as "legal". ASF policies are my "laws" as a
committer at the same level as "real" legal issues.

>> I don't understand why this should be asked to INFRA and not LEGAL,
> 
> legal discuss is about points of law and not about points of policy.
> yes, policy is informed by law but release policy is set by the
> infrastructure team. the policy is that every artifact released must
> have LICENSE and NOTICE documents. (the convention for source
> distributions is to have them at top level.)

I exactly followed that policy. The only "detail" is that in zips I
always included a folder with the same name of the artifact and the
LICENSE/NOTICE are placed inside this folder with everything else.
Is this OK?

> therefore to produce a proper source release through a svn export,
> LICENSE and NOTICE files need to be at top level. however, if you
> aren't going to be shipping a proper source release then they aren't
> necessary.

Can I guess that "proper" is your own opinion and not an ASF policy? ;-)

>> but I will do this too.
> 
> not sure that there's much point asking on infra: you'll probably get
> a quicker answer by asking infrastructure questions on this list.
> hopefully, i've been reasonably comprehensive. please ask more
> questions if i haven't been clear on any points.

Can you check the thread I linked before? In that message I was asking
few things about LICENSE/NOTICE and related stuff. It would be cool to
have a reply.

>> >> If they will reply that NOTICE and LICENSE are needed also in the svn
>> >> source tree then we should coordinate the Maven2 guys to avoid pushing
>> >> the use of the
>> >> "apache-jar-resource-bundler"+"maven-remote-resources-plugin"
>> >> combination because this leads to no LICENSE/NOTICE in the source
>> tree.
>> >
>> > seems wrong to me that maven actively conflicts with the use of an svn
>> > export to create a proper source release
>> >
>> > - robert
>>
>> I don't agree on the fact that svn export should be used to create
>> source releases. svn export does not create a package, does not sign it,
>> does not ensure any rule.
> 
> maven doesn't really enforce rules yet (but it is coming)

Not maven alone, but a properly configured pom.xml results in maven
creating the LICENSE/NOTICE. (you just need to declare the parent apache
pom, even if we don't use this solution for JAMES products).
The parent apache pom include this LICENSE/NOTICE "rule".

>> Every other package we release is created by a build script: why should
>> we use svn export for the source release?
> 
> because it's the source and are an open source project :-)

My understanding was that LICENSE and NOTICE are required for
redistribution. You can do everything else with the svn export ;-)

> a source release should consist of the source exported directly from
> the repository and compressed for delivery. everything else is just
> window dressing.
> 
> - robert

Add also that you can add LICENSE/NOTICE for redistribution policies and
maybe you name the package apache-something and I agree with you.

IMHO LICENSE and NOTICE are not part of the sources: in fact they are
not involved in the build process ;-) . LICENSE and NOTICE are
policy/legal disclaimers needed to protect the ASF and to enforce the
licensing.

IMHO "svn export" is not intended to create redistributables (does this
word exists?).

IMHO they are not compressed for delivery, but packaged in a
redistributable artifact.

Stefano

PS: I don't want to convince you of anything but I ask you a personal
favor: I found it difficult to understand what of your sentences are
personal ideas and what are ASF policies. As described here:
http://www.apache.org/foundation/how-it-works.html#management (hats)
I always consider your sentences as personal ideas if not otherwise
specified, but if you have knowledge of ASF policies that already
defined what we have to do then it does not worth discussing our
personal ideas.


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message