On 1 November 2014 00:18, Rich Freeman <ri...@gentoo.org> 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 flamee...@flameeyes.eu — http://blog.flameeyes.eu/
