Rich Freeman <rich0 <at> gentoo.org> writes:
> 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. Um, it was a bit of humor ,on a serious topic, which I support. > 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. Sound like you have the issues well conceptualized? > 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. Are we talking about a database of know failures? Over time the database would grow quite large, but be very useful? > 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. Ah, yes; leadership is a fleeting quality. It always has been and always will be..... fleeting > 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. POINT very well acknowledged. Perhaps if we build something that ordinary coders can use and some folks with resources help those upstream application developers, then a few will participate with us? This is a huge problem for the scientific community. Because just because a large, complicated algorithm runs, does not mean it is correct or robust. They need tools built upon what your are designing for first the admins and the secondly for the upstream code developers. Once something is built for quality code check, and it is reasonable simple to depoly, I think at the very least many users of those codes will run these tools on open source code projects. Yes this is a huge effort, that is sorely needed, imho. We are all in this together. > 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). I totally agree. With excellent leadership, you can keep the secondaries like me, in-line. We do need a specification to begin with. Sure it will evolve, but specs help keep focus and priortize what tools get worked on and when, imho. > 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. Easy on the coffee. Now you are jumping to too many conclusions. I agree well need lots of thinking, planning and an overall robust architecture design and lots of code. Hardware never is a problem, us EE's are always way out front of the CS folk, imho...... And yes, let's get coding.......Um what's my homework assignment this week? > The code will be hard. The culture change will be harder. And that is why YOU are on the council. My prayers and old fingers are with you, brah! > The hardware will be easy. Hardware is FUN. Everybody loves new tangible goodies, kids through old folks. That's why my first degrees where in hardware (fluids and electronics). I then realize that the microprocessor is what animates the hardware and allows an EE to become lazy and successful. So I studied CS, got an advanced degree and continue to study, build and work on software. It never ends, so we must "bond" together to get codes to be what we need them to be. I know this assembler-->Haskel migration is hard on old dudes like me, it is very, very hard. All I ever do is read and learn new software tricks without ever mastering anything..... > 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. For me, you build things and manually test them. Then you automate what has worked manually. Sure it often occurs simultaneously, but things must be manual and partitionable to facilitate test and debug. I think with ample thought, planing and a cool, inviting plan, we can get many kids to participate in GSoC. If we "reach out" there are many other folks at various distros that have a high level of need (frustration). The gentoo rank and file experts may just be too busy, too burnt or disinterested. I dunno. Certainly there is a lot of horsepower in our ranks. I've had several grad students recently send me unsolicited email in search of tough problems to solve. Surely we can add some algorithmic challenges, centric on some of the newer languages to spice this up a bit for those "hungry brilliant minds" too? If Gentoo does not do this, Who will? Who else can (lead) this sort of effort? For whatever reason, I think this task has fallen on Gentoo. With the work of LikeWahoa, we can build a usb gentoo image that has this (GLEP) proposal, and the necessary tools to entire devs from other distros to download and plug in the USB stick. WE get them addicted to Gentoo via a live usb stick. They can hide, but it becomes easy to update the usb stick *everybody* can use it to come up to speed quickly and catch "gentoo fever". The fever allows folks to at least taste gentoo, read a bit and send in codes on this GLEP. I know many vikings working on some subterranean physics all looking seriously at gentoo. Gentoo on a usb stick allows for a liveGENTOO that can be easily updated and they can jump in and out of Gentoo, until the fever takes hold. Or some other kind of hook? Fishing was very difficult till the hook was refined. WE need a hook, imho. Easy Gentoo and a project to assist in testing code; you've got a killer idea there rich, and I'm glad to be on your team! James
