On 28/05/2015 09:02, Luc Maisonobe wrote: > 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?
In the general case I agree with you completely. In the less than an hour case I was referring to, folks had actually had a lot longer to review and test the patch but on the private security@ list. The public vote was simply an exercise in getting the necessary votes into the public record. As always these things are a balance and the board generally leaves it up to the PMC to decide what is best. If a PMC was regularly having votes of only a few hours I'm sure the board would have concerns. I don't think the board would have concerns about a short vote in the Pool 2.4.1 case. In the Pool 2.4.1 case we need to balance giving time for folks to find issues with 2.4.1 against reducing the time the known faulty 2.4.0 binary is out there. My own view is that the greater risk / harm / inconvenience to the community is to leave 2.4.0 out for longer than we absolutely have to. Given that: - the only source change since 2.4.0 will be to the version number - the known issue in 2.4.0 that we are trying to fix is easy to test for I think the chances of the same issue happening again and not being detected or a new issue being introduced are slim enough that a short vote is OK. Ultimately it is the RM that decides how long the vote is (which should be declared when the vote is called). If the the consensus view is that the vote period called for is too short the RM can always extend it. Mark > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
