Le 28/05/2015 09:14, Mark Thomas a écrit : > 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.
I understand this, but feel slightly uncomfortable with it. The 72 hours delay also implied people can have time to raise objections. If 3 votes are gathered in less than an hour but a fourth reviewer identifies a critical problem 12 hours later (just because of time zone for example), then it would be too late. I know enough +1 are enough to get a release out even if some -1 are also cast, but in a general case we often try to fix them. Of course, another urgent fix could be made once again, though. So to be clear, I though 72 hours were required for both gathering enough +1 but also to see if some -1 are raised, what do other people think about it? best regards, Luc > > 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
