On 12/04/2016 12:47 PM, Michał Górny wrote:
On Sun, 4 Dec 2016 16:58:26 +0000
Markos Chandras <hwoar...@gentoo.org> wrote:
On 12/03/2016 05:31 PM, Michał Górny wrote:
On Sat, 3 Dec 2016 13:13:36 +0000
Markos Chandras <hwoar...@gentoo.org> wrote:
On 12/03/2016 10:41 AM, Michał Górny wrote:
On Sat, 3 Dec 2016 10:35:32 +0100
Patrice Clement <monsie...@gentoo.org> wrote:
Friday 02 Dec 2016 14:10:27, Michał Górny wrote :
Hi, everyone.
I've heard multiple times about various tinderbox projects being
started by individuals in Gentoo. In fact, so many different projects
that I've forgotten who was working on most of them.
I know that Toralf is doing tinderboxing for most of the stuff.
What other projects do we have there? What is their status?
Is there anything we could try to integrate with pull requests to get
a better testing?
--
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>
Continuous integration is all the rage these days and tinderboxing is the
obvious way to go concerning Gentoo. AFAIK, Toralf is the only contributor
doing tinderboxing out of his own will. In reality, we should have a team of
devs looking after our own tinderboxes instead of relying on the community.
I'm wondering if we could start a donation campain for this project and ask
people if they've got spare machines laying around. I know a lot of folks are
reading this mailing list so maybe asking on gentoo-dev first for a start would
be appropriate.
Hardware is not the problem. Lack of software is.
Have you considered using openQA[1] like openSUSE[2] and Fedora[3] do
instead of reinventing the wheel?
[1] http://open.qa/
[2] https://openqa.opensuse.org/
[3] https://openqa.fedoraproject.org/
Do you by any chance happen to know how it maps to our needs?
At a first glance it seems quite tangential.
Depends on what you want to test. I guess openQA would be a very good
solution if you want to test a snapshot of the tree against the most
common scenarios for example
- todays snapshot with plasma5
- todays snapshot with gnome3
- todays snapsnot with lxqt
- ...
- todays snapshot with a few tests against popular console packages
* can gcc build small C test files?
* does bash work?
* does coreutils popular tools work as expected?
Having such scenarios in place is probably a more realistic testing
approach than simply build everything with random USE flags just for the
sake of build coverage.
I'm looking for something I could tell 'build this package on this
commit (pull request)', optionally with some USE flags adjustment.
And I'd like it to be fast, i.e. don't bother rebuilding whole KDE
libraries every time a pull request requiring them is updated.
FAST? have you read about 'tup'?
http://gittup.org/tup/
I'm not sure you are interested in a streamlined build system, just for
CI/tinderbox, but tup is as smart/fast as it gets.
hth,
James
