Monday, June 12, 2017

Today is the first day of Vincent's baccalaureat. Spanish test.

Still answering discussions. This has been dragging on, painfully, since June 6. But now it's getting in a territory I don't like at all, that I find borderline unprofessional.

Valid opinion. Don’t like trace options, don’t have to use

them. But why prevent me from using them?

Cluttering the code because you can't use proper tools is not acceptable imho.

I saw that as an unwarranted ad-hominem attack. Responded, explictly asked the question that I am interested in:

1. What categories do we want?
2. How do spread the categorization work?
3. How much do today’s developers depend on existing output?
4. What categories do we request e.g. in bug reports (IOW, what should --spice-debug select)
5. What tracing options and tweaks are potentially dangerous for end-users (e.g. what could expose security information)
6. Consequently, what tracing options do hide in release builds, current POV ranging from “as many as possible" to “none of them”
7. What are the existing hard-coded parameters? Explicit (e.g. 400ms delay in the server) or implicit (e.g. unbounded memory usage)
8. Among these, which ones would we like to tweak?
9. Among those we want to tweak, which ones would deserve dedicated options or env variables, which ones would be perfectly OK with a more generic option like the -t I proposed.

But this is really annoying, and wasting a lot of my time (and probably other people too). And my proposal prompted a counter proposal from one of the maintainers. Great!

Or rather, that would be great if the counter-proposal addressed the problem I want and need to solve.