Gentoo Archives: gentoo-dev

From: Daniel Ostrow <dostrow@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
Date: Fri, 13 Apr 2007 20:02:41
Message-Id: 1176491864.6435.24.camel@ashe.anyarch.net
1 <snip>
2
3 > > > Er, no, I'm explaining why enforcing src_test for EAPI 1 will be
4 > > > helpful for an awful lot of Gentoo developers.
5 > >
6 > > except that you back the tree into a corner that it cannot come out of
7 >
8 > Huh? Not at all. If a package can't use its test suite, the ebuild can
9 > set RESTRICT=test.
10 >
11 > > > Please refrain from that kind of comment. It doesn't help anyone.
12 > >
13 > > the answer is the same: talk to the QA team to get the tree into a
14 > > state where having src_test enabled by default is feasible and then
15 > > the QA team can change the profile
16 >
17 > That isn't going to happen any time soon. There are too many changes
18 > and the impact of turning it on is too high. A gradual migration via
19 > EAPI is much safer and much more useful.
20 >
21 > > enforcing via spec is the wrong way to go here ... spec is for
22 > > defining how the ebuilds work, not for forcing policy down peoples
23 > > throats
24 >
25 > And whether or not src_test is called is part of how ebuilds work.
26 > Policy is whether or not src_test is required to do something in all
27 > situations, or whether it can be RESTRICTed out as necessary.
28
29 </snip>
30
31 First off...wow...long time since I've been active...so if anyone wants
32 to discount my comments based on that alone feel free. I'm trying to get
33 back in the game and I think a few e-mails as participation might be
34 best...hopefully you'll actually see me online soon.
35
36 Now on to the real topic at hand. For src_test I see things this way.
37
38 1). Even though src_test is not mandatory in the here and now any
39 package that provides a test suite that fails said tests has a bug. It
40 may not be a critical bug but it is in fact a bug.
41
42 2). The proper fix, again in the here and now, for said bug is either to
43 a). fix the test suite or b). add a RESTRICT="test" to the ebuild. Since
44 sec_test is not mandatory however these things happen rarely if at all.
45
46 With the above in mind I entirely agree that adding it as a mandatory
47 phase for EAPI=1 makes sense. Think of it this way:
48
49 1). Developer A is bumping a package and is including some new
50 functionality in his ebuilds that require something in EAPI=1, say for
51 example a SLOT dependency. As such Developer A is already editing the
52 ebuild *and* testing it.
53
54 2). As part of his test he checks if the built in test suite works,
55 something he should be doing *anyway*. If it does great, if it doesn't
56 then he has two choices, as above, fix it or add a RESTRICT="test", at
57 *worst* adding 15 whole characters (16 if you include the extra carriage
58 return he will need to add) to his ebuild.
59
60 3). Developer A then marks his ebuild as EAPI=1 and off he goes on to
61 bigger and better things.
62
63 This will allow a whole slew of VERY useful information to be available:
64
65 1). The QA team can now query the tree for packages that have known bad
66 test suites simply by looking for ebuilds that have RESTRICT="test". As
67 it stands now this is impossible to accomplish.
68
69 2). Interested volunteers, both developer and user alike, who are
70 looking for ways to help out, can now be given a concrete list of known
71 test suites to go and fix, this improves the QA of the packages in the
72 tree.
73
74 3). The fact that a bug in the test suite exists is no longer hidden
75 from view.
76
77 4). Since the test suites are now mandatory end users can feel more
78 confident in the state of their installed software, this is no silver
79 bullet but it is a step in the right direction.
80
81 The *only* downside that I can see here is that by default the package
82 installation process gets a little longer. To get around this some
83 method of globally opting out of src_test should be provided to the end
84 user, however since it is an on by default feature someone at least has
85 *tried* the test suite.
86
87 Again, since src_test would only be turned on by default for ebuilds
88 marked EAPI=1, not globally for the whole tree, the only additional work
89 required of developers would be to actually run the test suite and
90 possibly fix a bug in one of two accepted ways. After all, the ebuild is
91 being touched *anyway*. As with all the phase changes under discussion
92 *no one* is talking about making a global tree change, src_test would
93 just be default for those ebuilds that have EAPI >= 1.
94
95 Just my 2 cents...
96
97 --Dan

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies