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
