[llvm-dev] Bug-closing protocol
Reid Kleckner via llvm-dev
llvm-dev at lists.llvm.org
Thu Jun 21 08:18:49 PDT 2018
I'm just an armchair critic with a lot of opinions on what other people
should do, and not enough willpower to pick one project and make it happen.
:)
On Thu, Jun 21, 2018 at 5:57 AM <paul.robinson at sony.com> wrote:
> So Reid, you'll be running a BoF on this at the October dev meeting? J
>
> --paulr
>
>
>
> *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of *Reid
> Kleckner via llvm-dev
> *Sent:* Wednesday, June 20, 2018 6:12 PM
> *To:* JVApen at gmail.com
> *Cc:* llvm-dev
> *Subject:* Re: [llvm-dev] Bug-closing protocol
>
>
>
> Thanks for taking the time to report bugs! I think you are responsible for
> filing the most high-quality clang-cl bugs.
>
>
>
> I hope our bug responses continue to be helpful and informative, but
> things do often get lost in translation. =/
>
>
>
> I also think there's a lot we could do to improve our bug hygiene and
> processes as a community. The way our bugzilla is configured, pinging bugs
> does not sent email to llvm-bugs@, so if an issue is not immediately
> triaged within a week after filing it, it's very unlikely that anyone will
> ever find it. As a community, we could set up rotations to triage stale
> bugs, but this takes resources, commitments, and planning. It's eminently
> doable, but it's not something that any one person or team of contributors
> can do on their own, so people tend to shy away from disturbing established
> processes.
>
>
>
> On Mon, Jun 18, 2018 at 10:33 PM JVApen via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hi all,
>
>
>
> First of all, I'm sorry to create a separate thread on the mailing list, I
> have disabled all mails from it.
>
>
>
> I just read the thread about the bug closing protocol thanks to
> LLVMWeekly. (
> http://lists.llvm.org/pipermail/llvm-dev/2018-June/123955.html)
>
>
>
> I've noticed a lot of reactions from people involved with the solving part
> of the bugs. So I'm putting out the loggers point of view. (Or at least
> mine)
>
>
>
> I'm totally in favor of getting relevant information when a bug gets
> closed. Over the last couple of years, I've logged several bugs, of which a
> couple of clang-cl compatibility bugs where put to invalid.
>
> Having a good explanation on why this is closed helped me a lot in
> manually fixing several thousand of occurrences of that pattern. Both
> mentally to not give up, as by understanding the problem.
>
> Please keep doing so!
>
>
>
> However, from my point of view, this is the tip of an iceberg. Out of
> about 50 bugs I've logged on a variety of modules, only half reached an end
> state. (Either fixed or invalid/won't fix).
>
>
>
> My problem also lies in that other half, those bugs that have been open
> for more than 2 weeks (upto 5 years). Cause if you don't get a reaction
> within those 2 weeks, the chances of getting a reaction drop a lot. (Or if
> reactions suddenly stop)
>
>
>
> When a bug goes into such a state, you are lost as a bug logger. It took
> me a couple of years getting our companies code compiling with clang-cl
> (linking is far future), working around obscure bugs of which I still don't
> know if you (as community/maintainer) agree if it is a bug.
>
>
>
> To make matters worse, every time a component gets upgraded (internal
> library, extrernal library or even the tool-chain, including clang), there
> is a high probability of firefighting issues. Only when that fails, I spent
> time logging a bug (as creduce doesn't work on my system).
>
>
>
> In the best case scenario, I get an event like this weekend that states:
> merged.
>
> This means: I'm certain I'll have a fix in the future. Unfortunately, it
> is only available in the next official release, which will happen in
> September. And with a bit of luck, you can find back what the actual
> revision is, to see the diff. So for now, the code is ifdef-ed out for
> clang as it won't link anyhow.
>
>
>
> In conclusion: I really respect the work you do, this puts the standard on
> a high level. Taking the time to inform the bug logger is a must have.
> However, it is not the only place were we as bug loggers are lacking
> information.
>
>
>
> JVApen
>
> _______________________________________________
> 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/20180621/1b96bd56/attachment-0001.html>
More information about the llvm-dev
mailing list