Gentoo Archives: gentoo-dev

From: james <garftd@×××××××.net>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Tinderboxing efforts in Gentoo
Date: Sun, 04 Dec 2016 18:20:07
Message-Id: 0f71dbdf-cceb-cfa2-1b41-1acbe3a3e8e9@verizon.net
In Reply to: Re: [gentoo-dev] Tinderboxing efforts in Gentoo by "Michał Górny"
1 On 12/04/2016 12:47 PM, Michał Górny wrote:
2 > On Sun, 4 Dec 2016 16:58:26 +0000
3 > Markos Chandras <hwoarang@g.o> wrote:
4 >
5 >> On 12/03/2016 05:31 PM, Michał Górny wrote:
6 >>> On Sat, 3 Dec 2016 13:13:36 +0000
7 >>> Markos Chandras <hwoarang@g.o> wrote:
8 >>>
9 >>>> On 12/03/2016 10:41 AM, Michał Górny wrote:
10 >>>>> On Sat, 3 Dec 2016 10:35:32 +0100
11 >>>>> Patrice Clement <monsieurp@g.o> wrote:
12 >>>>>
13 >>>>>> Friday 02 Dec 2016 14:10:27, Michał Górny wrote :
14 >>>>>>> Hi, everyone.
15 >>>>>>>
16 >>>>>>> I've heard multiple times about various tinderbox projects being
17 >>>>>>> started by individuals in Gentoo. In fact, so many different projects
18 >>>>>>> that I've forgotten who was working on most of them.
19 >>>>>>>
20 >>>>>>> I know that Toralf is doing tinderboxing for most of the stuff.
21 >>>>>>> What other projects do we have there? What is their status?
22 >>>>>>>
23 >>>>>>> Is there anything we could try to integrate with pull requests to get
24 >>>>>>> a better testing?
25 >>>>>>>
26 >>>>>>> --
27 >>>>>>> Best regards,
28 >>>>>>> Michał Górny
29 >>>>>>> <http://dev.gentoo.org/~mgorny/>
30 >>>>>>
31 >>>>>> Continuous integration is all the rage these days and tinderboxing is the
32 >>>>>> obvious way to go concerning Gentoo. AFAIK, Toralf is the only contributor
33 >>>>>> doing tinderboxing out of his own will. In reality, we should have a team of
34 >>>>>> devs looking after our own tinderboxes instead of relying on the community.
35 >>>>>>
36 >>>>>> I'm wondering if we could start a donation campain for this project and ask
37 >>>>>> people if they've got spare machines laying around. I know a lot of folks are
38 >>>>>> reading this mailing list so maybe asking on gentoo-dev first for a start would
39 >>>>>> be appropriate.
40 >>>>>
41 >>>>> Hardware is not the problem. Lack of software is.
42 >>>>>
43 >>>>
44 >>>> Have you considered using openQA[1] like openSUSE[2] and Fedora[3] do
45 >>>> instead of reinventing the wheel?
46 >>>>
47 >>>> [1] http://open.qa/
48 >>>> [2] https://openqa.opensuse.org/
49 >>>> [3] https://openqa.fedoraproject.org/
50 >>>
51 >>> Do you by any chance happen to know how it maps to our needs?
52 >>> At a first glance it seems quite tangential.
53 >>>
54 >>
55 >> Depends on what you want to test. I guess openQA would be a very good
56 >> solution if you want to test a snapshot of the tree against the most
57 >> common scenarios for example
58 >>
59 >> - todays snapshot with plasma5
60 >> - todays snapshot with gnome3
61 >> - todays snapsnot with lxqt
62 >> - ...
63 >> - todays snapshot with a few tests against popular console packages
64 >> * can gcc build small C test files?
65 >> * does bash work?
66 >> * does coreutils popular tools work as expected?
67 >>
68 >>
69 >> Having such scenarios in place is probably a more realistic testing
70 >> approach than simply build everything with random USE flags just for the
71 >> sake of build coverage.
72 >
73 > I'm looking for something I could tell 'build this package on this
74 > commit (pull request)', optionally with some USE flags adjustment.
75 > And I'd like it to be fast, i.e. don't bother rebuilding whole KDE
76 > libraries every time a pull request requiring them is updated.
77
78 FAST? have you read about 'tup'?
79 http://gittup.org/tup/
80
81 I'm not sure you are interested in a streamlined build system, just for
82 CI/tinderbox, but tup is as smart/fast as it gets.
83
84 hth,
85 James
86
87
88 >