On 28 May 2015 at 11:46, James Carman <ja...@carmanconsulting.com> wrote: > I suppose we can't overwrite what's there?
AFAIK, one can just re-release 2.4. Still needs a vote IMO. > On Thu, May 28, 2015 at 3:14 AM Mark Thomas <ma...@apache.org> wrote: > >> Technically we do need a new release vote since: >> >> a) The released source will not be exactly the same (due to the version >> bump). >> >> b) The convenience binaries will be different (due to fixing the >> corruption). >> >> We need the vote to make the release an act of the foundation. >> >> We can make the vote as short as we like. That there must be a vote is a >> hard rule. Running the vote for at least 72 hours is strongly encouraged >> but PMCs are allowed to make exceptions if a shorter vote is in the best >> interests of the community e.g. security releases or - as in this case - >> fixing a broken binary. I've seen votes last less than an hour for some >> security fixes. >> >> Mark >> >> >> >> >> On 28/05/2015 05:13, Phil Steitz wrote: >> > >> > >> > >> > >> >> On May 27, 2015, at 10:03 PM, James Carman <ja...@carmanconsulting.com> >> wrote: >> >> >> >> Are the files that we voted on originally actually corrupt? >> > >> > The binary jar is corrupt. I don't think there is anything wrong with >> the source distribution. Independent confirmation that jars built from the >> 2.4 release sources are consistently clean would be appreciated. >> > >> > In any case, I am fine running another vote once I have 2.4.1 artifacts. >> > >> > Phil >> > >> > >> >>> On Wed, May 27, 2015 at 9:48 PM Gary Gregory <garydgreg...@gmail.com> >> wrote: >> >>> >> >>> I think we need a vote no matter what for a new release. What we can >> do is >> >>> make the vote 24 hours instead of 72. >> >>> Gary >> >>> >> >>> -------- Original message -------- >> >>> From: Phil Steitz <phil.ste...@gmail.com> >> >>> Date: 05/27/2015 17:54 (GMT-08:00) >> >>> To: Commons Developers List <dev@commons.apache.org> >> >>> Subject: Re: [pool] apparently bad jar released ... ugh. help! >> >>> >> >>> OK, having calmed down a bit, I have a plan. Feedback, objections, >> >>> general grumpiness welcome. >> >>> >> >>> 0. Open JIRA against 2.4 >> >>> 1. Revert web site update >> >>> 2. Drop 2.4 artifacts from release area >> >>> 3. Copy 2.4 release tag to make 2.4.1 release tag >> >>> 4. Roll good artifacts from 2.4.1 tag. If these do not test out, >> >>> drop the tag; else >> >>> 5. Push out 2.4. >> >>> >> >>> I don't think we need a new vote for 2.4.1 because (unless there >> >>> actually is a problem with it) the source should be the same as 2.4. >> >>> >> >>> I am about to get on a plane, so I won't get to 5 for at least 10 >> >>> hours. Please speak up if you have objections. >> >>> >> >>> Phil >> >>> >> >>> >> >>>> On 5/27/15 2:57 PM, Phil Steitz wrote: >> >>>> Somehow the 2.4 binary release jar that I just pushed to the mirrors >> >>>> and maven central appears to be corrupted. I don't know why / how >> >>>> this happened but I get the following error when I build dbcp with >> >>>> the new jar: >> >>>> >> >>>> net/sourceforge/cobertura/coveragedata/TouchCollector >> >>>> java.lang.NoClassDefFoundError: >> >>>> net/sourceforge/cobertura/coveragedata/TouchCollector >> >>>> at >> >>> >> org.apache.commons.pool2.impl.AbandonedConfig.__cobertura_init(AbandonedConfig.java) >> >>>> >> >>>> There is also a coberta.properties file in the manifest. I have no >> >>>> idea how it happened, but somehow maven seems to have created the >> >>>> release jar from the coberta-instrumented classes or something. >> >>>> >> >>>> The hashes and sigs on the jar are all good. >> >>>> >> >>>> I would appreciate some help figuring out what is going on here and >> >>>> also pushing out a quick fix release, as I suspect there is no way >> >>>> we can pull back what I pushed out about 10 hours ago. >> >>>> >> >>>> Sorry to have not caught this prior to pushing the binaries out and >> >>>> thanks in advance for any help anyone can provide. >> >>>> >> >>>> Phil >> >>> >> >>> >> >>> >> >>> --------------------------------------------------------------------- >> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >>> For additional commands, e-mail: dev-h...@commons.apache.org >> >>> >> >>> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
