On 18/01/2013 07:12, Duncan wrote: >> 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). > > So several days of machine time, and /very/ conservatively, at least a > work day of your time, more likely 1.5-2 workdays, maybe half a week.
Yes that sounds about right about timing. > One more question. I've read about various tinderbox runs, and now we > know they take several days of machine time plus say 1-2 (surely more for > the really involved stuff, glibc and gcc touch about everything...) days > of your time. It gets trickier with gcc and glibc, because package A can stop package B, C, D and E from merging if it fails, so a single run never is enough for them... > Are you queued up with tinderbox runs, or is there room for more demand? I've got one run that is queued that I'm not running yet which is the pkgconf one — I'm considering setting up a clone of tbamd64 for that since the gcc/glibc/automake one right now it's taking a long time. > If someone like Shuttleworth came along and offered to sponsor you to > work on gentoo and tinderboxes full time, how far up could it scale > before it required more people, and would there be ever more tinderbox > possibilities or would the law of diminishing returns kick in? Would you > consider that or find it too boring or depressing to do full time? I'm not sure honestly if we're not very near already to that point of diminishing returns. For sure, if I was paid to do tinderboxing full time I would be spending more time on automating. In particular, having a quick way to search for open bugs for the package from the analysis interface would cut the time I spend on it considerably. While some people have complained about the lack of attached logs, I'm not going to focus on that just yet because for so many of the logs, it would require compressing them with xz and even then they might not fit, so it's not something I see much use for. One bothersome thing is that a lot of the current process relies on me keeping in mind packages and patterns I've seen before. You can guess it's not an easy walk to scale to multiple people this way. So fixing long-standing bugs to remove "not-so-false positives" that were already filed two years ago might be of help. Right now I guess one of the biggest wastes of time is the doc USE flag that I enabled globally on the tinderbox, to catch Ruby packages' failures, and is causing a bunch of other packages to fail as well as those conditionals are rarely tested at all. > So I know I've directly benefited from your tinderbox runs and other > projects you've done, and I really do appreciate it, especially as I know > much of it is volunteer, tho some is work related but benefits gentoo as > well. I'm glad you feel the tinderbox has helped — sometimes I'm honestly not sure myself. But a lot of the work that is done there couldn't be possible without things like IUSE defaults and REQUIRED_USE, as those used to waste much much more of my time just to follow the right dependencies to be aable to merge the packages. So I think Zac and the other Portage developers deserve most of the cheers there, as I've shown, I mostly just pour in the time. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
