On Wed, 2007-05-02 at 01:12 +0100, Stephen Bennett wrote: > On Tue, 01 May 2007 19:46:56 -0400 > Daniel Gryniewicz <[EMAIL PROTECTED]> wrote: > > > There is one serious problem with this: Who's going to do the work to > > figure all this out for the 11,000 odd packages in the tree? This > > seems like a *huge* amount of work, work that I have no plan on doing > > for the 100-odd packages I (help) maintain, let alone the 4-10 > > different versions of each package. I highly doubt other maintainers > > want to do this kind of work either. > > Last I heard the intention was to tie it to the EAPI=1 bump, so that > packages can be updated one by one as they move to the newer eapi. > Current (ie EAPI=0) ebuilds will continue to function as they have done.
Sure, but now you're requiring me to go through all that extra work if I want any of the benefits of EAPI=1. Or alternatively, dooming us to support EAPI=0 forever, since I don't want to do that work. Or, third option, is that everyone marks their packages as "low priority tests, don't run them" just to switch to EAPI=1, and we have no gain over what we have now. Honestly, tests are nice, but too many of them are broken upstream, and we are not (and should not be, IMO) in the position of fixing them all. If a developer wants to work with her upstream to fix the tests in her packages, great and more power to her. Most of us are swamped just supporting them, let alone fixing test cases. You really need an upstream who cares a lot about tests for the tests to be meaningful and work. Lots of upstreams don't currently care, and have inherited obsolete and (now) broken tests from previous maintainers. I think this thread in general overestimates the value of tests in packages. I think we will find, if we go through the effort, that more of them are useless and/or broken than are useful. My 2 cents. Daniel -- [EMAIL PROTECTED] mailing list
