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: [jsieve] Any more TODO before 0.2 release?
Date Fri, 20 Jun 2008 12:15:53 GMT
On 6/20/08, Stefano Bagnara <apache@bago.org> wrote:
> David Jencks ha scritto:
>> <total snip>
>>
>> So I seem to have provoked much more discussion than I intended here.
>
> David, don't take my words as too harsh: this is my way to understand
> things and communicate ;-)
>
> I really appreciate your help and I will try to summarize what we
> discussed and to push "Legal Affairs" so that they confirm this summary
> and put something in the website, so in future a similar thread will
> stop with "the policy is writte at this url, if you don't agree at this
> url you find an explanation of who and how the policy is defined".

The best way to approach this would be to create a patch and
contribute it through JIRA. Development and documentation of policy
works as any project. See links from http://www.apache.org for details
about changing content on www.apache.org.

-Robert

> Similar threads keeps repeating, if we end up with this stuff published
> then this thread has not been a waste of time. It is an issue that the
> whole thread from january didn't generate a clear result (at least to my
> understanding).
>
>  > I
>> don't know if its best practice, policy, or my misunderstanding but I
>> think the following are supposed to happen:
>
> ;-)
>
>> 1. expected svn checkout points are supposed to include LICENSE and
>> NOTICE files at their root covering everything in the checkout, and
>> nothing else.  These should be kept up to date via "best-effort" by the
>> pmc and committers, and should definitely be accurate for svn tags.
>
> I personally don't like to have to do that and I don't share the legal
> references made to justify the existence of this policy, but I agree
> that most people in the legal-discuss thread we referred previously
> agreed on this.
> I opened this issue: https://issues.apache.org/jira/browse/LEGAL-26
>
>> 2. released artifacts should include LICENSE and NOTICE files applying
>> exactly to their content.   If this goal is not achieved, its better to
>> have unnecessary stuff in the LICENSE/NOTICE files than missing stuff.
>
> https://issues.apache.org/jira/browse/LEGAL-27
>
>> For jsieve, I think these can be achieved simply by using the m-r-r-p
>> with no appended stuff for LICENSE and NOTICE for the java, source, and
>> javadoc jars, and using the svn LICENSE and NOTICE files for (1) in the
>> distro bundles.
>>
>> To me, this seems easy, as simple as possible, and correct.
>
> To not have the NOTICE/LICENSE in svn and have it automatically created
> by maven would be simpler, but if legal affair will agree on the policy
> above I'll agree that this is the best option now.
>
>> I've lost track of the ensuing discussion.  Points (1) and (2) are my
>> interpretation of what I thought was consensus reached on the
>> legal-discuss list around dec-2007-jan-2008 leading up to release of the
>> latest maven remote resource bundle for apache.  Getting it documented
>> clearly would have been a good idea at the time but I was tired.
>>
>> Discussions about whether (1) and (2) are accurate would probably be
>> best on legal-discuss.  I think Stefano wasn't sure if my proposed
>> strategy would work but I didn't understand why not.
>
> I submitted the 2 JIRAs above :-)
> Let's give a good ending to flames :-)
>
> My issue was not your strategy but the need to have LICENSE/NOTICE in
> svn and the need to manually mantain a different LICENSE/NOTICE file for
> each package released (expecially a different LICENSE/NOTICE file for
> src zip and bin zip because they ship different contents).
> Furthermore the strategy is not generally applicable because most m2
> projects do not have dependencies in svn so the LICENSE/NOTICE for the
> binary with runtime dependencies package will have to be created
> somewhere else or managed via a second m-r-r-p plugin in the build.
>
> *IF* the above JIRA will be approved and added to the policy it would be
> probably good if maven (or some of our maven guides for ASF, like the
> activemq, geronimo, openjpa guides I found really useful in past)
> document a good way to achieve the result (2 m-r-r-p seems the only
> alternative to manually create multiple copies, but maybe smarter people
> have smarter solutions)
>
>> I guess there might be some question about whether the java, source, and
>> javadoc jars are released independently, such as by deploying to the
>> maven central repo.  I hope you do release them in this way since not
>> doing so makes it really hard for other projects that use maven to use
>> interoperate with james.
>>
>> thanks
>> david jencks
>
> Yes, for our m2 based projects we use maven release plugin and we use
> the stage/deploy process described in the guides previously quoted. jars
> are automatically published to ASF m2 repository.
>
> To make sure we don't leave anything back I also opened this:
> https://issues.apache.org/jira/browse/LEGAL-28
>
> Thank you,
> hope you understand that beside my methods I was propositive :-)
> Stefano
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>

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