commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <...@spaceroots.org>
Subject Re: [pool] apparently bad jar released ... ugh. help!
Date Thu, 28 May 2015 08:02:28 GMT
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 <james@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 <garydgregory@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.steitz@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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message