On 11/06/12 05:45, Duncan wrote: > Diego Elio Pettenò posted on Mon, 05 Nov 2012 07:39:19 -0800 as excerpted: > >> On 05/11/2012 07:31, Steven J. Long wrote: >>> Are you really missing the fact that by testing someone's overlay, the >>> package would by definition not be in the tree, and you wouldn't have >>> to file any bugs at all, just (automatically) email the output back to >>> the overlay developer? >> >> Which means I wouldn't be filing bugs for the problems with the >> _existing_ packages that are in tree, which is what the users actually >> _use_ by default. >> >> If the users are forced to use overlays to get working packages, then I >> feel I'm perfectly right with screaming at the developers who are using >> overlays for development because they leave users in a sorry state. > > I'm not sure if this is what SL had in mind, but it's what I thought of > when I read his suggestion, triggered here by the "won't have to file > bugs at all" bit. > > What about doing overlays, but ONLY one-at-a-time, and ONLY on special- > request-runs, presumably immediately pre-tree-introduction? Among other > things that might help for stuff like kde where a whole slew of packages > are introduced to the tree (and should be tested) together, something > that's easier done from a staging overlay. > > That way, any overlay runs would be pre-requested by the overlay person/ > project, so they'd be specifically expecting results. Thus the "could > (if desired) skip filing bugs, just direct-mail" part SL mentioned, or > automated bug filing but in this case it'd be ENTIRELY by request and > expected, since they would have pre-arranged for the tinderbox run and > would be expecting/prepared-for the results.
I've been doing this for some overlays - kde, qt, sunrise It's still a lot of work to set things up (keywords, blockers, useflags mostly), and it takes lots of time - the "small" qt overlay took me about 4 days walltime to process (I'd estimate somewhere near a CPU-day) But why rely on Diego or me for such things? All you need to do is setup a chroot, configure it well, emerge `cat pkglist` and watch the fallout. > > Additionally, one-overlay-at-a-time would automatically mean what's ever > there is tested only against the tree and other packages in that overlay, > limiting the "where'd it come from" problem. Aye, it gives pretty good results, but comes with extra setup time. ... but as you mentioned, if the overlays provided specific files with e.g. unmask lists it'd be easier, and anyone with reasonably fast hardware can do it themselves anyway. Happy compiling, Patrick
