[llvm-dev] [Release-testers] 12.0.1-rc1 release has been tagged

Andrew Kelley via llvm-dev llvm-dev at lists.llvm.org
Fri Jun 4 19:23:42 PDT 2021


On 6/4/21 5:36 PM, Tom Stellard wrote:
> On 6/3/21 12:23 PM, Andrew Kelley via llvm-dev wrote:
>> On 6/2/21 2:40 AM, Michał Górny via llvm-dev wrote:
>>> On Tue, 2021-06-01 at 10:03 -0700, Tom Stellard wrote:
>>>> On 5/28/21 1:45 PM, Michał Górny wrote:
>>>>> On Wed, 2021-05-26 at 00:15 -0700, Tom Stellard via Release-testers
>>>>> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I've tagged the 12.0.1-rc1 release.  Testers may upload binaries 
>>>>>> and report results.
>>>>>>
>>>>>
>>>>> I've started testing, hit two bugs I've already reported for 12.0.0 
>>>>> RCs
>>>>> and figured out I'm wasting my time.  It seems that LLVM reached
>>>>> the point where releases are pushed through just for the sake of
>>>>> releases and QA doesn't exist.
>>>>>
>>>>
>>>> Which bugs are these?
>>
>> https://bugs.llvm.org/show_bug.cgi?id=49821
>>
>> The fix for this has been in main branch since May 4, with a request 
>> to merge into release/12.x, and yet the release candidate does not 
>> include this, despite the bug open as a 12.0.1 release blocker.
>>
>> Downstream we have our MIPS test suite disabled because of this bug. 
>> It was passing with LLVM 11.
>>
> 
> Sorry, I missed this one.  The committer asked for us to wait until
> the fix had been upstream for a while before backporting it, which
> is why it was not backported right away.
> 
> In the future, if there is a bug you care about, I would recommend pinging
> it once week if you aren't seeing movement on it.
> 
>>>
>>> Just to be clear, I'm not blaming you.  But the whole release testing
>>> process is just getting more and more frustrating.
>>>
>>
>> I'm pretty frustrated over here too. What's the hurry on tagging 
>> releases? Can't we wait to tag releases until all the release blockers 
>> are fixed?
>>
> 
> We usually don't have release blocking bugs.  I know it's a little 
> confusing,
> because we use the 'blocks' field in bugzilla, but this is really used 
> to mark
> bugs that we want to fix, not bugs that must be fixed.
> 
>> This is a compiler backend. Priority number one should be not 
>> introducing regressions. The timing of releases is not important at 
>> all in comparison.
>>
> 
> I understand this position, but some people value a predictable release 
> schedule
> over more bug fixes from upstream and that's why we do time-based releases.
> 
> As I mentioned in the other mail, I think that moving to GitHub issues is
> going to enable a lot of improvements in our release process.  I think
> with better automation and more process transparency we'll be able to
> get more bugs fixed and provide a better experience for bug reporters,
> developers, and release managers.
> 

Thanks for the reply, Tom. I'm looking forward to this.

Andrew

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210604/33e90260/attachment.sig>


More information about the llvm-dev mailing list