Oleg Kalnichevski ha scritto:
On Sun, 2008-09-21 at 19:24 +0200, Stefano Bagnara wrote:
Oleg Kalnichevski ha scritto:
Folks,
The 0.5 release is pretty much ready. Please do try to find a moment to
review the release notes, packages and the web site:
release notes:
http://people.apache.org/~olegk/mime4j-preview/RELEASE_NOTES.txt
Great! :-)
packages:
http://people.apache.org/~olegk/mime4j-preview/packages/
The src package contains a lib folder that should not be there.
Fixed. I also fixed a whole bunch of javadoc warnings. New packages
uploaded.
Great! You're fast and effective as always!
Everything looks good now.
Stefano
DISCLAIMER: under this line you'll find a pedantic answer about binary
packages and vote.
site (status page):
http://people.apache.org/~olegk/mime4j-preview/site/status.html
If anything is wrong, just go ahead and fix it in the source
I've no time now.. I'll check the above issue tomorrow.
=====================
My interpretation of the feedback given the release policies by the
legal folks is that we no longer need to vote on binary artifacts as
long as they are generated from the official source distribution
https://issues.apache.org/jira/browse/LEGAL-34
My interpretation is that no one from the legal team answered, yet ;-)
And they probably won't given there is a reasonably satisfactory answer
to the question.
Lately they didn't close any legal issue.. maybe sooner or later they
will start again trying to close some of them. We don't need a
satisfactory answer, but an answer. If no answer is possible to that
question then it means that every PMC have the power to decide its own
rules and there is no policy.
If anyone would still like to vote on the Maven artifacts, please let me
know.
If it comes for free I'd like to also review them while reviewing other
packages. What if I find that a generated maven artifact has a wrong
NOTICE?
I always thought one is meant to test that the release src package
builds and generates correct binary artifacts ;-)
That's what I do, but I would bet all of my money that MOST +1 given to
[VOTE] release (both in JAMES and other ASF projects) are given without
doing this.
Sometimes, like this one, as I found an issue in the src package I
didn't even tried to build it. But I only spent a few more minutes
checking the content of binaries you uploaded, so publishing them can
save you some iteration ;-)
Should I vote down the source release? In this case I think that
is a facility from the release manager to the reviewers to publish them
too otherwise each voter should build and check the generated binary
artifacts locally.
See above.
If publishing that stuff comes for free then I think it worth it. At
least people casting +1 without compiling would have a chance to check
some more stuff or they could test the binary result in their
environment. (better some check than a blind +1..)
Let's say a binary generation script works differently in my machine and
in the release manager machine and in my machine it produces correct
binaries while in your machine it produces bad binaries (a pratical
example could be a java version issue: let's say we have sources with no
-target specified, and I use java 1.5 while the release manager uses
java 1.5... if we don't review binaries generated by the release manager
we'll end up with java 5 only binaries...). I don't know what is the
procedure in this cases.. maybe the binary artifacts can be fixed and
replaced without requiring a new vote?
My understanding is that only the source package is what a release vote
is all about. Binary artifacts are merely byproducts. They MUST be built
from the source package, though, but can be (re)published without a
vote.
I'm fine with this interpretation, even if I'm not sure how to deal with
defining what binaries generated by that source content should be
published in the ASF repository and what should not.
E.g: in our server products we use "ant" as our build tool, but the
source tree and the src package include also a pom.xml because we use m2
for the website generation. The binaries generated by the m2 build are
not good wrt to licensing (or at least no one ever cared about this). If
I call a vote only for the src package people will not know if in the
end I'll upload binaries generated with the good tool (ant) or with the
bad tool (m2). We can ignore all of this issues (and probably many more
I could architect ;-) ) if we include everything in the VOTE/review process.
Anyways, I'll post maven artifacts when the official vote is held to
make everyone happy.
Thank you! If publishing them does not add too much work I'd be happy,
so I can check if packages generated by my "mvn package" equal packages
generated in your environment
Of course this is not a blocker for me, just a convenience. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
