I suppose we can't overwrite what's there? 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 > >
