Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild

[Diego Elio Pettenò]

On Fri, Jan 18, 2013 at 1:32 AM, Duncan <1i5t5.duncan@×××.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.