I'd like to see more user submitted ebuilds make it into the tree..but whatever. My latest gripe is the test-request option, let's kill that bs right off. Kick it to wontfix or upstream or change it to wtf?, but I think packages are moving too fast in general for test-request. By the time users and devs figure out what happened with package x-1.0 and straighten it out, we can be up to package x-1.1-r3 and then any fix that went into the former package tends to wasted time on someone's part.
An example of the can be seen at http://bugs.gentoo.org/show_bug.cgi?id=23111 where a bug was filed because usbutils wouldn't compile against 2.6 headers ( no surprise there ) and a suggestion was made and asked for test-request, with a few flaws to the whole process- 1) The devs asked said user to re-emerge linux-headers, which with no official 2.6 headers in the tree at the time, would have kicked him back to 2.4 headers,solving the problem with the merge but not actually touching the real problem reported. This is probably acceptable by dev standards. 2) The user didn't respond back (bad user!!!) 3) I had a similar problem, saw I couldn't completely solve it but saw a way around it without requiring anyone to regress their 2.6 headers, and submitted my patch...where it still sits under the guise of test-request and is now pretty much useless as usbutils somehow worked itself out with regards to the 2.6 headers. So QA on new ebuilds is a bitch, and responsibility for them may preclude many of them from submission, but how about those patches to existing maintained packages? I'm sure that mine isn't the only such case...but that was 30 mins I could've spent wondering where those topless college chicks were at when I was college:) Please pay more attn to patch submissions, pretty please? --- Chuck Brewer Registered Linux User #284015 Get my gpg public key at pgp.mit.edu!! Encrypted e-mail preferred. -- [EMAIL PROTECTED] mailing list
