On Wed, 2008-09-24 at 14:32 +0200, Stefano Bagnara wrote: > Oleg Kalnichevski ha scritto: > > Folks, > > > > I'll be on vacation from Sept 27th (this Saturday) to Oct 6th. I would > > like to have mime4j 0.5 released before I leave. That means I'll have to > > build the packages and start the release vote tomorrow the latest > > (provided no release blockers are reported at the last moment), > > otherwise there will be no time. > > > > Cheers > > > > Oleg > > I applied MIME4J-79.
Great! I committed some very minor code tweaks as a followup. > If you want to prepare 0.5 and start a vote, you're welcome! At worst if > a bug is found in the 3 days vote we'll have another take when you come > back from your vacation. > If I cut the packages and start the vote now, the earliest chance for me to tally the votes and complete the release would be October 7th. This just does not seem to make a lot of sense. I am planning to start working on the release as soon as I am back (unless there is a kind soul who would be willing to act as a RM for 0.5 while I am away) Cheers Oleg > Stefano > > > On Mon, 2008-09-22 at 14:10 +0200, Stefano Bagnara wrote: > >> 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] > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
