On Fri, Jan 18, 2013 at 1:32 AM, Duncan <1i5t5.dun...@cox.net> wrote: > To be clear I'm not in a position to offer, and I definitely respect and > value your volunteer work, but suppose someone /was/ sufficiently > interested in something like ffmpeg to be willing to pay for a tinderbox > run on it. What sort of "pay for" are we talking?
It's tricky to quantify honestly. I've been seriously thinking about it (as those who have been reading my G+ feed today noticed), and the question of how to quantify it is the one that I have no real answer for. I can give you an idea of what's involved, so that it gives an idea of why I tend to be touchy when people complain about the way I report bugs, or the choices of packages I make. For those who follow my blog, part of this has been covered already, so sorry if it feels like a re-heated soup. First of all, there's the time involved in setting up the tinderbox itself. Given that I can easily start from a known configuration, it usually does not take that much of mytime to configure it — but since keeping seeds around is pointless (they go bad too quickly), and since changing package choices often requires cleaning up everything that used the previously-chosen package, even if I wanted to set up a parallel tinderbox for ffmpeg, it'd take me one or two days just of _unmerging_ the currently-installed packages. It's not an exaggeration, last time it took 34hr to complete a --depclean on tbamd64. As of me writing this, tbhs64 (the stable-targeted tinderbox) is performing a depclean, started early this morning. It's machine time, but it needs to be monitored, so let's say that a 5% of the time is my time, and the rest is purely the machine's. Then there is the time to build all the packages, or at least the involved subset — I honestly forgot how many reverse dependencies were involved in the libav testing, but I remember that the time it took was around five days to go through all packages (and their dependencies). Again this is mostly machine time, but as those following my Twitter feed know, it's not so uncommon to have a package hogging down the queue for over 24hr if not monitored, because a test stuck, or (in the case of mldonkey) because a prompt is requested on the tty. If somebody has a good idea how to stop interactive prompts without having to detach or redirect stdout to file, it'd be nice. 7.5-12.5% of the time mine, the rest the machine? Likely. Then comes the actual timedrain: sifting through the logs, and track down the bugs — this generally has to be done while the tinderbox run, because otherwise you can easily get obsolete bugs. While I have written a tool that helps me with the analysis, it only does so in the sense of finding me which logs report failures, and pre-fills the template for reporting a bug related to said log — it does not help me with actually finding what's going on. And sometimes a build log shows a failure due to another package's build mistake. Only about half the logs that my analysis script report end up in a bug at all; for the tinderboxes as they are, I counted in the past few months an average of an hour a day spent on "detective work" on said logs, to get to the bugs. Now with a bit of luck, the amount of logs to sift through for an ffmpeg-targeted tinderbox would be much less than those generated by tbamd64 (which uses glibc-2.17 and gcc-4.7), so let's say we end up with a total of 10/12 hr of work all in all? I wouldn't go as far as ask for my going hourly rate, but especially for ffmpeg, it would come for something a bit higher than a dinner at the next conference — more like the travel expenses (given a conference such as FOSDEM, not SCALE, to give an idea). And before anybody tries to misrepresent what I wrote — I don't intend to charge anybody for my usual tinderbox runs; they run and they'll keep running for as long as I have time to dedicate to them. As I said before, my employer (who's sponsoring hosting and bandwidth) uses libav in production, so it actually influences further the fact that the default run is libav-bound — although you could call it a self-fulfilling prophecy, as the fact they run libav is further influenced by the fact that they employ me, but c'est la vie.
