james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "robert burrell donkin" <robertburrelldon...@gmail.com>
Subject Re: NOTICE/LICENSE, apache- prefix and other ASF best practices (Re: [mime4j] release plan for 0.3) [LONG]
Date Wed, 16 May 2007 11:10:33 GMT
On 5/15/07, Stefano Bagnara <apache@bago.org> wrote:
> robert burrell donkin ha scritto:

<snip>

> >> If you add a dependency in maven MAYBE maven will automatically take
> >> care of the NOTICE changes, otherwise you can do it manually. If you
> >> don't use that generated license then you are SURE that you have to do
> >> it manually for sure.
> >
> > this algorithm is not sufficient to create a compliant NOTICE (it
> > would be possible to do it properly but it will take a while to write
> > the software and instrument the code bases with the required
> > meta-data)
>
> AFAIK the NOTICE we are generating in MIME4J is compliant, and it is
> generated. What's the problem, then?

there is no problem if they are compliant

i haven't checked the NOTICE and i know of weaknesses in the current
plugin. so it needs to be checked rather than just assumed to be
correct. in particular, check that there are no documents without ALv2
headers in the source.

> >> >> IMHO they are not compressed for delivery, but packaged in a
> >> >> redistributable artifact.
> >> >
> >> > just use a compression application
> >>
> >> <provoking>Why do you use ant? you could just execute a sequence of the
> >> command you need, instead..</provoking>
> >
> > creating and using any script is a trade-off
> >
> > creating source releases is quick and easy. few ever need to create
> > releases. i prefer to use the traditional way of creating releases. i
> > don't trust maven to accurately create source releases.
> >
> > - robert
>
> I don't share your missing trust for the maven-assembly-plugin: I don't
> see why I should trust svn/zip and not the maven-assembly-plugin.
> Either way, I checked the resulting package with a compare tool, and it
> worked fine.

good

> As you wrote "I prefer" I think you are only telling your own preference
> and you're perfectly fine with what differently I do.

yes

> Otherwise if
> you'll take the responsibility to release mime4j here is my +1 to use
> whatever build tool you like and whatever NOTICE generator and svn
> implementation ;-). "I don't trust maven to accurately create source
> releases" IMHO is not an acceptable justification to prevent us from
> working out a release.

i agree

> IMHO you should simply check the generated result independently on how
> we generated it: IMHO the tools should be a choice of the worker.

i agree

> That said I think I just completed my duties on mime4j. IMHO everything
> is ready for a release and our generated artifacts seems to be compliant
> with any policy I heard of. If anyone wants a release just ask Norman to
> take care of this (I don't have a signed gpg key so even if I wanted I
> could not do the last missing step).

a key with a strong web of trust is not required by policy: just a signature

it's best practice to use a key with a strong web of trust but it's
more important that the release is signed by the release manager who
cut the release. the signature is primarily to allow infrastructure
and the release manager to verify that an artifact was create by the
release manager. all that requires is that the private key is kept
safe and secure.

- robert

---------------------------------------------------------------------
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