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 language, if possible. But the
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 exceptions and issues an
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. Debian has a similar p
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 could provide CI test
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
>> upstream-provided test suites. IMHO, src_test() wou
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 maintainter-provided tests yo
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 basic functionality of the merge
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 provided by upstream, and
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 merged
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 upstream. My point is that
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" and in contrast t
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 testing
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
> >> also annotate that somehow so I don't waste hours running a
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 gives zero signal on whether I should add the
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
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 in the stabilization
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 provided by upstream, and d
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 package
> that has been merged
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 could
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
> controlled by a USE flag. T
Hi,
I am a student selected for GSoC 2016. One of the things in my proposal
requires the ebuilds to carry a mechanism to test the built software by
running some script provided by the maintainer of the ebuild.
This would be basically similar to whatever tests an Arch Tester would do,
however made e
21 matches
Mail list logo
