llvm dev - Mar 2016 - Need help with code generation

> That's because we seem to be debating whether we'd actively reject
a patch to fix such issues, not how important they are to us to fix.
I would not work on it. Including not review it while there are actual
missing features to be implemented.

If you want to call that a low priority bug, go for it. I don't find
it honest to do that myself.

Cheers,
Rafael

----- Original Message -----
> From: "Rafael Espíndola" <rafael.espindola at gmail.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Bruce
Hoult" <bruce at hoult.org>, "Mehdi Amini" <mehdi.amini
at apple.com>
> Sent: Tuesday, March 22, 2016 2:09:21 PM
> Subject: Re: [llvm-dev] Need help with code generation
> 
> > That's because we seem to be debating whether we'd actively
reject
> > a patch to fix such issues, not how important they are to us to
> > fix.
> 
> I would not work on it. Including not review it while there are
> actual
> missing features to be implemented.
I disagree with your characterization. "Actual missing features" are
anything for which there is community support and there are contributors.
> 
> If you want to call that a low priority bug, go for it. I don't find
> it honest to do that myself.
That's fine. No one can force you to review anything. Generically, Rui, as
the code owner, is responsible for serving as reviewer of last resort. However,
lld is an LLVM project, and any contributor familiar with our general
conventions and the current design of the code in question is qualified to
approve a patch to remove undefined behavior from our code.

Rafael, please don't misunderstand me. I think you (and Rui and George and
several others) have done an excellent job moving lld forward. I'm very
excited about it. I'm concerned, however, that you would effectively turn
away potential contributors (especially contributors interested in overall code
quality, not just some particular bell or whistle) by implying that reviews of
their patches would be indefinitely delayed. I don't think that's
healthy, either for lld in particular, or for the LLVM community more generally.

Thanks again,
Hal
> 
> Cheers,
> Rafael
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

On Tue, Mar 22, 2016 at 12:09 PM, Rafael Espíndola <llvm-dev at
lists.llvm.org>
wrote:
> > That's because we seem to be debating whether we'd actively
reject a
> patch to fix such issues, not how important they are to us to fix.
>
> I would not work on it. Including not review it while there are actual
> missing features to be implemented.
> If you want to call that a low priority bug, go for it. I don't find
> it honest to do that myself.
>
I wouldn't call this a "low priority bug". If you would not review
patches
to fix it (effectively blocking patches, I assume - I take it you would ask
for such patches to be reverted if you hadn't reviewed/approved them?) that
seems different to how the rest of the LLVM community treats these sort of
issues.

- David

>
> Cheers,
> Rafael
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://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/20160322/c78d2c06/attachment.html>

On 03/22/2016 01:02 PM, David Blaikie via llvm-dev
wrote:
>
>
> On Tue, Mar 22, 2016 at 12:09 PM, Rafael Espíndola 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>
>     > That's because we seem to be debating whether we'd
actively reject a patch to fix such issues, not how
>     important they are to us to fix.
>
>     I would not work on it. Including not review it while there are actual
>     missing features to be implemented. 
>
>
>     If you want to call that a low priority bug, go for it. I don't
find
>     it honest to do that myself.
>
>
> I wouldn't call this a "low priority bug". If you would not
review
> patches to fix it (effectively blocking patches, I assume - I take it 
> you would ask for such patches to be reverted if you hadn't 
> reviewed/approved them?) that seems different to how the rest of the 
> LLVM community treats these sort of issues.
I haven't seen Rafael state that he would either a) block others from 
reviewing this patches or b) revert patches reviewed by someone else.  
Merely not reviewing is different from either of those.

(Just being pedantic for clarity.)
>
> - David
>
>
>     Cheers,
>     Rafael
>     _______________________________________________
>     LLVM Developers mailing list
>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://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/20160322/c259d372/attachment.html>

On 22 March 2016 at 16:02, David Blaikie <dblaikie at gmail.com>
wrote:
>
>
> On Tue, Mar 22, 2016 at 12:09 PM, Rafael Espíndola <llvm-dev at
lists.llvm.org>
> wrote:
>>
>> > That's because we seem to be debating whether we'd
actively reject a
>> > patch to fix such issues, not how important they are to us to fix.
>>
>> I would not work on it. Including not review it while there are actual
>> missing features to be implemented.
>>
>>
>> If you want to call that a low priority bug, go for it. I don't
find
>> it honest to do that myself.
>
>
> I wouldn't call this a "low priority bug". If you would not
review patches
> to fix it (effectively blocking patches, I assume - I take it you would ask
> for such patches to be reverted if you hadn't reviewed/approved them?)
that
> seems different to how the rest of the LLVM community treats these sort of
> issues.
I agree. which is why I don't want to call it a bug.

But since having a bug open for years causes far less discussion than
otherwise I am fine with it as long people know I will retire long
before I get to it.

Cheers,
Rafael