1 |
On 12/04/2016 05: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 |
|
79 |
I think that both approaches are valuable then. We may need different |
80 |
set of software solutions though. Wouldn't, for example, Jenkins or |
81 |
buildbot do what you want on the per-package PR testing? And then you |
82 |
could use openQA to test the entire tree as a whole. |
83 |
|
84 |
-- |
85 |
Regards, |
86 |
Markos Chandras |