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

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.
> 
> 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?

This is a compiler backend. Priority number one should be not 
introducing regressions. The timing of releases is not important at all 
in comparison.

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/20210603/7d5c7152/attachment.sig>

Hi,

For ARM, we still have the known cfi failures and one unexpected pass on
(CodeGen/sanitize-coverage.c) seen on 12.0.0
and mentionned in https://bugs.llvm.org/show_bug.cgi?id=46117

There is also https://bugs.llvm.org/show_bug.cgi?id=50481 which was
introduced into 12.0.0 and has a proposed fix
(https://reviews.llvm.org/D103167) which I think would be nice to have
included in this release.

AArch64 are good, binaries uploaded:
> sha256sum clang+llvm-12.0.1-rc1-a*
330b9ad17ad4538a8660e3cf115c449a8bb9acc42a86ec30c5927fabec7f2a4c
 clang+llvm-12.0.1-rc1-aarch64-linux-gnu.tar.xz
758190a1705281f97e5aa9c5e24d1fff8e1dace6377e8a2bdd21c8cbf36c4353
 clang+llvm-12.0.1-rc1-armv7a-linux-gnueabihf.tar.xz

Cheers,
Yvan



On Thu, 3 Jun 2021 at 21:23, Andrew Kelley via llvm-dev <
llvm-dev at lists.llvm.org> 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.
>
> >
> > 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?
>
> This is a compiler backend. Priority number one should be not
> introducing regressions. The timing of releases is not important at all
> in comparison.
>
> Andrew
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210604/bf792db9/attachment.html>

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.

-Tom
> Andrew
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>