On Fri, Dec 5, 2014 at 9:05 AM, James <wirel...@tampabay.rr.com> wrote: > Alec Ten Harmsel <alec <at> alectenharmsel.com> writes: > >> I have time next semester, I'll look into it > >> > Repoman false-alarms is another potential issue with this. >> Repoman can be improved ;) Repoman is already run nightly, I just don't >> think Gentoo has the manpower to deal with that stuff. > > Fantastic, GSoc for Alec with Rich mentoring! > > I bet our friends at RackSpace will provide all the virtual HorsePower > you need, should google not provide the hundreds/thousands or cores for > you to run on. > > With the evolving etest tool in hand, I'm sure I can put together > a very large pile of ebuilds that need parsing? >
My guess is that the hardware to run all this on is the simplest part of the problem. If somebody writes something good and we build the processes to support it, then I'm sure we can find donors to provide the CPU cycles. ChromeOS could probably steal whatever we put together so there is an obvious synergy there, and I'm sure Amazon/Rackspace/etc are always looking for use cases to show off. >From past feedback from Diego and such the biggest issue with any kind of tinderbox is dealing with the output. As has been pointed out there are folks running Repoman regularly already, and there have been past tinderbox efforts. The real issue is to improve the signal/noise ratio. You'll only get so far with that using code - there has to be process change to support it. If we were to do something like this long-term I'd envision that this would run on every commit or something like that, and the commit doesn't go into the rsync tree until it passes. If the tree goes red then people stop doing commits until it is fixed, and somebody gets their wrist slapped. That is my sense of how most mature organizations do CI. The tinderbox is really just doing verification - stuff should already be tested BEFORE it goes in the tree. There also shouldn't be any false positives. There would need to be a mechanism to flag ebuilds with known issues so that the tinderbox can ignore them, and of course we can monitor that to ensure it isn't abused. Basically doing this sort of thing right requires a big change in mindset. You can't just throw stuff at the tree and wait for the bug reports to come in. You can't just make dealing with the tinderbox the problem of the poor guy running the tinderbox. The tinderbox basically has to become the boss and everybody has to make part of their job keeping the boss happy. Then you have to throw in uncooperative upstreams. If you ARE the upstream then you can apply these practices yourself and have a build system that outputs zero warnings and all that. We're dealing with what we get, so we're going to have to set the bar considerably lower if we don't want to exclude anything from the tree which has a lousy build system. In any case, focus first on decent code with proposed procedures that help deal with the output. Don't go spending a lot of money on hardware or worrying about setting up clusters and all that. Of course, if you want to run stuff in parallel that is something you can design in from the start (and there is no reason you can't run it in a few VMs on your laptop - it will be slow but the focus is on ensuring that it works, not that it is fast). In the past I've seen lots of people focus on building empires with dreams of hardware and all that, and they end up with little in the way of donations and if they do buy hardware they end up with nothing to run on it. Write the code first and get it working at small scale. If you write the code, the hardware will probably take care of itself. People care about Gentoo, but they're not going to throw lots of equipment at somebody who has little more than an email chain to show up-front, and I doubt the Foundation is going to want to buy hardware before the code exists. The code will be hard. The culture change will be harder. The hardware will be easy. Bottom line - this sort of thing is a lot harder to pull off than it might first appear. I don't want to discourage anybody, but don't think that you can toss together a few lines in bash to do an emerge -e world and you're done. Of course, if you do want to do a manual run like this and manually submit bugs that have been manually screened for validity, that is always welcome. -- Rich
