Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11

[Diego Elio Pettenò]

On 1 November 2014 00:18, Rich Freeman <rich0@g.o> wrote:
> So, if there is a better way, I'm all ears for constructive
> suggestions.  By constructive I mean that somebody who comes up with a
> script that automatically retrieves build logs and attaches them to
> bugs is being more helpful than somebody who says that somebody else
> should come up with such a script, and so on.  That doesn't mean that
> we can't talk about solutions before we build them - only that it
> isn't helpful when we basically demand that others build them for us.

Let me try to be clear (once again) of what the problem is. Even just
spending time rewriting this irks me because I have written, repeated,
re-explained, described the problem a number of times, between bugs,
this ML and my blog ( https://blog.flameeyes.eu/tag/tinderbox ).

The problem with "it's trivial to do that in python so just do it" is
that first of all Python is not my language of choice, so the whole
infrastructure is currently not written in Python at all. And all the
people, including Luca, who promised they can convert it to Python in
no time, never delivered. Beside the point that, if it's so trivial
for somebody, I would expect it'll take them less time to provide me
with the tool, rather than complain about it.

Another suggestion that happens fairly often is "oh just do it after
opening the bug with a script", and the answer is -> no way. Because
right now it's all self contained in a browser for good reasons: I
open these bugs when I'm at work waiting for a meeting, at home
waiting to sleep, or while watching TV. I do it from laptops and
tablets, and if I have to start copy-pasting things between browser
and console to run a script, I'd rather just leave things broken
because it *is* too much work by the amount of bugs I open. And it's
not something I can do on a tablet or at work. Which would mean that
not only it'll take me more time , and I would also have less time
available. Not a good deal.

Since the bugs are opened through a pre-filled form template, it's not
easy for anything else to know what the bug is to attach logs to. One
alternative would be to have the app that I use to show me the logs
file the bug entirely for me. Unfortunately that means I'll have to
figure out how to secure the app, as right now, being just a
display-only thing, it's completely open to the Internet. And I'm sure
Infra would rather not have a tool open to the internet that can open
bugs with logs of many MBs attached. It will also slightly lower the
quality of bugs because either it needs to build its own form to fill
in for summary and blocking bugs, or it'll just go with the two
summaries I know for sure how to get from the log ("fails to build",
"fails tests"), so no more "foo[doc] fails to build" or "foo fails to
build with ncurses[tinfo]".

But let's reason a moment on the no-linked-logs policy: as Rich
pointed out already, the policy is there for a reason and that reason
is that we don't want people to submit bugs with pastebins or home
server logs because they are bound to go away. I link logs to Amazon,
which I pay for. Mike says it's unreasonable to expect me to pay
Amazon for them forever... I pay $1/mo for storing viewing an adding
the logs. And even that turned out to be actually an excess as I was
paying between $.12 and $.20 for storing EBS snapshots from long ago
that I never ended up removing. It's not even a rounding error at this
point.


Diego Elio Pettenò — Flameeyes
flameeyes@×××××××××.eu — http://blog.flameeyes.eu/