On 8/21/12 5:10 PM, Marvin Humphrey wrote:
> On Tue, Aug 21, 2012 at 1:11 AM, Jürgen Schmidt <jogischmidt@gmail.com> wrote:
>> On 8/21/12 8:14 AM, Marvin Humphrey wrote:
>>> * I could not find a version control tag for 3.4.1-rc2, but I was
>>> able to obtain the AOO34 branch at the specified revision 1372282; it was
>>> close, though seemingly not exact. The discrepancies are shown below.
>>> I don't believe this should block, but it would be nice to know why the
>>
>> I can explain this because I prepared the source release. The binaries
>> (MacOS) and the first build of the src release were made on clean source
>> tree based on revision r1372282.
>>
>> After this I analyzed a potential further bugfix on the same tree. I
>> made some debug output in 3 cxx files. But after deeper analysis we
>> decided that we don't want include this fix in 3.4.1. The risk to break
>> something else was to high and we postponed the fix to the next release.
>>
>> After this we recognize some problems with the RAT output. I deleted
>> some svn generated *.rej files and built the src package again to clean
>> up the RAT output. It seems that I have overseen the debug messages in
>> the changed cxx files.
>>
>> I can easy repackage the src release on the same tree where I revert the
>> local changes to revision 1372282.
>>
>> If we all agree I can easy exchange the src release packages with the
>> new ones.
>
> Thank you for the thorough explanation. If I have understood you correctly,
> all files flagged by either RAT or by the check against the svn export of
> revision 1372282 have been accounted for and we have sufficient rights to
> distribute them. That being the case, in my view it is not necessary to roll
> a new RC.
exactly that is my understanding when I checked the sources. We always
try to address concerns immediately. But we are also humans and no
machines and can make errors or can oversee things. But as mentioned
before we are happy to incorporate any kind of valuable feedback.
The more detaield the feedback is and potential concerns are the better
it is. And of course it is much easier to change things accordingly. We
are still learning.
>
> +1 to release.
Thanks
Juergen
>
> Marvin Humphrey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org