1 |
On 18/01/2013 07:12, Duncan wrote: |
2 |
>> Now with a bit of luck, the amount of logs to sift through for an |
3 |
>> ffmpeg-targeted tinderbox would be much less than those generated by |
4 |
>> tbamd64 (which uses glibc-2.17 and gcc-4.7), so let's say we end up with |
5 |
>> a total of 10/12 hr of work all in all? I wouldn't go as far as ask for |
6 |
>> my going hourly rate, but especially for ffmpeg, it would come for |
7 |
>> something a bit higher than a dinner at the next conference — more like |
8 |
>> the travel expenses (given a conference such as FOSDEM, not SCALE, to |
9 |
>> give an idea). |
10 |
> |
11 |
> So several days of machine time, and /very/ conservatively, at least a |
12 |
> work day of your time, more likely 1.5-2 workdays, maybe half a week. |
13 |
|
14 |
Yes that sounds about right about timing. |
15 |
|
16 |
> One more question. I've read about various tinderbox runs, and now we |
17 |
> know they take several days of machine time plus say 1-2 (surely more for |
18 |
> the really involved stuff, glibc and gcc touch about everything...) days |
19 |
> of your time. |
20 |
|
21 |
It gets trickier with gcc and glibc, because package A can stop package |
22 |
B, C, D and E from merging if it fails, so a single run never is enough |
23 |
for them... |
24 |
|
25 |
> Are you queued up with tinderbox runs, or is there room for more demand? |
26 |
|
27 |
I've got one run that is queued that I'm not running yet which is the |
28 |
pkgconf one — I'm considering setting up a clone of tbamd64 for that |
29 |
since the gcc/glibc/automake one right now it's taking a long time. |
30 |
|
31 |
> If someone like Shuttleworth came along and offered to sponsor you to |
32 |
> work on gentoo and tinderboxes full time, how far up could it scale |
33 |
> before it required more people, and would there be ever more tinderbox |
34 |
> possibilities or would the law of diminishing returns kick in? Would you |
35 |
> consider that or find it too boring or depressing to do full time? |
36 |
|
37 |
I'm not sure honestly if we're not very near already to that point of |
38 |
diminishing returns. For sure, if I was paid to do tinderboxing full |
39 |
time I would be spending more time on automating. In particular, having |
40 |
a quick way to search for open bugs for the package from the analysis |
41 |
interface would cut the time I spend on it considerably. |
42 |
|
43 |
While some people have complained about the lack of attached logs, I'm |
44 |
not going to focus on that just yet because for so many of the logs, it |
45 |
would require compressing them with xz and even then they might not fit, |
46 |
so it's not something I see much use for. |
47 |
|
48 |
One bothersome thing is that a lot of the current process relies on me |
49 |
keeping in mind packages and patterns I've seen before. You can guess |
50 |
it's not an easy walk to scale to multiple people this way. So fixing |
51 |
long-standing bugs to remove "not-so-false positives" that were already |
52 |
filed two years ago might be of help. |
53 |
|
54 |
Right now I guess one of the biggest wastes of time is the doc USE flag |
55 |
that I enabled globally on the tinderbox, to catch Ruby packages' |
56 |
failures, and is causing a bunch of other packages to fail as well as |
57 |
those conditionals are rarely tested at all. |
58 |
|
59 |
> So I know I've directly benefited from your tinderbox runs and other |
60 |
> projects you've done, and I really do appreciate it, especially as I know |
61 |
> much of it is volunteer, tho some is work related but benefits gentoo as |
62 |
> well. |
63 |
|
64 |
I'm glad you feel the tinderbox has helped — sometimes I'm honestly not |
65 |
sure myself. But a lot of the work that is done there couldn't be |
66 |
possible without things like IUSE defaults and REQUIRED_USE, as those |
67 |
used to waste much much more of my time just to follow the right |
68 |
dependencies to be aable to merge the packages. So I think Zac and the |
69 |
other Portage developers deserve most of the cheers there, as I've |
70 |
shown, I mostly just pour in the time. |
71 |
|
72 |
-- |
73 |
Diego Elio Pettenò — Flameeyes |
74 |
flameeyes@×××××××××.eu — http://blog.flameeyes.eu/ |