On Thu, 9 Apr 2009 18:21:55 +0200 Patrick Lauer <[email protected]> wrote: > > Which is why we are not talking about enabling it for the tree. We > > are talking about enabling it for a subset of the tree that's > > guaranteed to have been tested by it. > > So you propose to make a new EAPI that about 2.5% of the tree can use?
Of course not. No-one's stupid enough to think that's even remotely true, so please don't say things like that. Most packages that have tests have working tests. For those that don't, the tests have to be restricted. All this proposal does is ensures that that happens in a progressive, incremental and safe way. Had src_test been introduced after EAPIs came along, this would already have happened. > And it is still the same stupid idea. We have FEATURES="test" for > those who care, and if you look at the amount of bugs that causes > already I see no sane way to make it default. It causes lots of bugs because it's not the default. > Why would you enable it by default just to disable it by default in > those packages where it is the most important? If packages are failing tests, either it's a legitimate reason, in which case it needs to be fixed, or it's not, in which case it needs to be restricted. The problem is, currently there's no way for users to know which is which. With an EAPI mandated src_test, users will know that any failure that gets to them is legitimate. > Tell you what. Provide patches for all open test failure bugs and > provide a list of all packages where tests are slow (for certain > values of slow we'd have to agree on) and you can resume pushing your > toy ideas. There's no need to. That's the beauty of this proposal. As packages are moved to EAPI 3, any package with broken tests can, at the maintainer's choice, either get RESTRICT=test (which they should have been given already) or get fixed tests. This is no more work for maintainers. All it does is makes sure they do something they should be doing already, and in the process makes things much safer for users. Again, this has all already been covered. -- Ciaran McCreesh
signature.asc
Description: PGP signature
