Re: [gentoo-dev] Proposal for changes for the next EAPI version

On 18/05/16 01:44, Kent Fredric wrote: > On 18 May 2016 at 12:35, M. J. Everitt wrote: >> Yes, whilst that's a special case, it would be desirable to collaborate >> with another maintainer/team/project to devise a test schedule that was >> independent from the target

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On 18 May 2016 at 12:35, M. J. Everitt wrote: > Yes, whilst that's a special case, it would be desirable to collaborate > with another maintainer/team/project to devise a test schedule that was > independent from the target language, if possible. But there will always > be

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On 18/05/16 01:14, Kent Fredric wrote: > On 18 May 2016 at 04:05, Sébastien Fabbro wrote: >> Basically CI for ebuilds: it could be implemented as a script living >> in the package directory, something like a .travis.yml in the GitHub >> repositories or may be an EAPI change.

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On 18 May 2016 at 04:05, Sébastien Fabbro wrote: > Basically CI for ebuilds: it could be implemented as a script living > in the package directory, something like a .travis.yml in the GitHub > repositories or may be an EAPI change. Debian has a similar project > [1]. Upstream

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On Tue, May 17, 2016 at 12:05 PM, Sébastien Fabbro wrote: > On 17 May 2016 at 08:34, Luis Ressel wrote: > >> >> Automated post-merge tests sound kinda dangerous to me. And I don't >> think there's any stipulation about src_test() only running >>

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On 17 May 2016 at 08:34, Luis Ressel wrote: > > Automated post-merge tests sound kinda dangerous to me. And I don't > think there's any stipulation about src_test() only running > upstream-provided test suites. IMHO, src_test() would be a good place > for most of the

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On Tue, 17 May 2016 13:07:43 +0530 Pallav Agarwal wrote: > Tests run in src_test are provided by upstream, and does not > guarantee that a package that has been merged will actually run on > the system. If the maintainer could add a couple small scripts to > check

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On Tue, 17 May 2016 15:53:34 +0200 "M.B." wrote: > Am 17.05.2016 um 09:37 schrieb Pallav Agarwal: > > For normal users we wouldn't. But currently, arch-testers need to > > make a judgement call on what to test when a stable-req bug is > > filed. Tests run in src_test are

Re: [gentoo-dev] Proposal for changes for the next EAPI version

Am 17.05.2016 um 09:37 schrieb Pallav Agarwal: > For normal users we wouldn't. But currently, arch-testers need to make a > judgement call on what to test when a stable-req bug is filed. Tests run in > src_test are provided by upstream, and does not guarantee that a package > that has been

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On Tue, May 17, 2016 at 7:25 AM, Pallav Agarwal wrote: > Because we are already expecting an arch tester to conduct tests for the > package. And knowing what to test is something I expect to come more > easily from the maintainer. > It would come even more easily from

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On Tue, 17 May 2016 07:26:03 -0400 Michael Orlitzky wrote: > We already have "emerge --config" which is expected to be run after > the install process has completed, so I don't think that this is too > much of a stretch. Maybe call the phase "pkg_test" analogous to > "pkg_config"

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On 05/17/2016 06:01 AM, Pallav Agarwal wrote: > Hi, > You are right, of course. > The target is to standardize something that would encourage maintainers > to actually provide non-upstream scripts to test packages. At the same > time, it should be possible to use those scripts for automated

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On Tue, May 17, 2016 at 4:27 PM, Rich Freeman wrote: > On Tue, May 17, 2016 at 5:15 AM, Kent Fredric > wrote: > > On 17 May 2016 at 20:46, Tobias Klausmann wrote: > >> And as for my pet peeve, tests that are known to fail, can we >

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On Tue, May 17, 2016 at 5:15 AM, Kent Fredric wrote: > On 17 May 2016 at 20:46, Tobias Klausmann wrote: >> And as for my pet peeve, tests that are known to fail, can we >> also annotate that somehow so I don't waste hours running a test >> suite that

Re: [gentoo-dev] Proposal for changes for the next EAPI version

Hi, You are right, of course. The target is to standardize something that would encourage maintainers to actually provide non-upstream scripts to test packages. At the same time, it should be possible to use those scripts for automated testing without human interference. Even if they are provided

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On 17 May 2016 at 20:46, Tobias Klausmann wrote: > And as for my pet peeve, tests that are known to fail, can we > also annotate that somehow so I don't waste hours running a test > suite that gives zero signal on whether I should add the stable > keyword? Even a one-line hin

Re: [gentoo-dev] Proposal for changes for the next EAPI version

Hi! On Tue, 17 May 2016, Kent Fredric wrote: > On 17 May 2016 at 19:37, Pallav Agarwal wrote: > > For normal users we wouldn't. But currently, arch-testers need to make a > > judgement call on what to test when a stable-req bug is filed. Tests run in > > src_test are

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On 17 May 2016 at 19:37, Pallav Agarwal wrote: > For normal users we wouldn't. But currently, arch-testers need to make a > judgement call on what to test when a stable-req bug is filed. Tests run in > src_test are provided by upstream, and does not guarantee that a

Re: [gentoo-dev] Proposal for changes for the next EAPI version

For normal users we wouldn't. But currently, arch-testers need to make a judgement call on what to test when a stable-req bug is filed. Tests run in src_test are provided by upstream, and does not guarantee that a package that has been merged will actually run on the system. If the maintainer

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On Mon, 16 May 2016 18:13:33 +0530 Pallav Agarwal wrote: > What I'm suggesting is to add a new function post_install_test. The > function will run only if the build is being run for stabilization > (either as a part of automated stabilization, or manual) which can be >