<snip> > > > Er, no, I'm explaining why enforcing src_test for EAPI 1 will be > > > helpful for an awful lot of Gentoo developers. > > > > except that you back the tree into a corner that it cannot come out of > > Huh? Not at all. If a package can't use its test suite, the ebuild can > set RESTRICT=test. > > > > Please refrain from that kind of comment. It doesn't help anyone. > > > > the answer is the same: talk to the QA team to get the tree into a > > state where having src_test enabled by default is feasible and then > > the QA team can change the profile > > That isn't going to happen any time soon. There are too many changes > and the impact of turning it on is too high. A gradual migration via > EAPI is much safer and much more useful. > > > enforcing via spec is the wrong way to go here ... spec is for > > defining how the ebuilds work, not for forcing policy down peoples > > throats > > And whether or not src_test is called is part of how ebuilds work. > Policy is whether or not src_test is required to do something in all > situations, or whether it can be RESTRICTed out as necessary.
</snip> First off...wow...long time since I've been active...so if anyone wants to discount my comments based on that alone feel free. I'm trying to get back in the game and I think a few e-mails as participation might be best...hopefully you'll actually see me online soon. Now on to the real topic at hand. For src_test I see things this way. 1). Even though src_test is not mandatory in the here and now any package that provides a test suite that fails said tests has a bug. It may not be a critical bug but it is in fact a bug. 2). The proper fix, again in the here and now, for said bug is either to a). fix the test suite or b). add a RESTRICT="test" to the ebuild. Since sec_test is not mandatory however these things happen rarely if at all. With the above in mind I entirely agree that adding it as a mandatory phase for EAPI=1 makes sense. Think of it this way: 1). Developer A is bumping a package and is including some new functionality in his ebuilds that require something in EAPI=1, say for example a SLOT dependency. As such Developer A is already editing the ebuild *and* testing it. 2). As part of his test he checks if the built in test suite works, something he should be doing *anyway*. If it does great, if it doesn't then he has two choices, as above, fix it or add a RESTRICT="test", at *worst* adding 15 whole characters (16 if you include the extra carriage return he will need to add) to his ebuild. 3). Developer A then marks his ebuild as EAPI=1 and off he goes on to bigger and better things. This will allow a whole slew of VERY useful information to be available: 1). The QA team can now query the tree for packages that have known bad test suites simply by looking for ebuilds that have RESTRICT="test". As it stands now this is impossible to accomplish. 2). Interested volunteers, both developer and user alike, who are looking for ways to help out, can now be given a concrete list of known test suites to go and fix, this improves the QA of the packages in the tree. 3). The fact that a bug in the test suite exists is no longer hidden from view. 4). Since the test suites are now mandatory end users can feel more confident in the state of their installed software, this is no silver bullet but it is a step in the right direction. The *only* downside that I can see here is that by default the package installation process gets a little longer. To get around this some method of globally opting out of src_test should be provided to the end user, however since it is an on by default feature someone at least has *tried* the test suite. Again, since src_test would only be turned on by default for ebuilds marked EAPI=1, not globally for the whole tree, the only additional work required of developers would be to actually run the test suite and possibly fix a bug in one of two accepted ways. After all, the ebuild is being touched *anyway*. As with all the phase changes under discussion *no one* is talking about making a global tree change, src_test would just be default for those ebuilds that have EAPI >= 1. Just my 2 cents... --Dan
signature.asc
Description: This is a digitally signed message part
