Date: Sat, 25 Jan 2014 21:18:09 -0500 From: Aryeh Friedman <aryeh.friedman@gmail.com> To: Alfred Perlstein <alfred@freebsd.org> Cc: FreeBSD Ports ML <freebsd-ports@freebsd.org> Subject: Re: What is the problem with ports PR reaction delays? Message-ID: <CAGBxaXm8VJYVaFtcNvZH4FbMCxEw1gUsiOUQqx3o6nrcUTr5eQ@mail.gmail.com> In-Reply-To: <52E46D44.6050403@freebsd.org> References: <CAHcXP%2Bf6e-t--XbQPTH1goJp_CL7P=zTj5trZVWd4YZ_EsO9gw@mail.gmail.com> <CAGBxaX=t3e5SXoBDHnzAbx=SWbEFMJHNPQL13FnwNgKWM3gCiA@mail.gmail.com> <CAHcXP%2Bew5qt5hc9Y%2BR_njPkfhUMsDDAqNk9aYSacV4PwBmqjfw@mail.gmail.com> <CAGBxaXnXwo4JxnRdffZfdvfETfhgJNkFM-N23H1SOT0G3-oMwA@mail.gmail.com> <CAE-m3X2dQTTsbrTJg2iPT3qkfq7h9U8oGbRZXGAXH%2BJ2T4MFNw@mail.gmail.com> <CAHcXP%2BdtHPHT%2BFD8RdcqhGANBPf1Gk4N4coEpZY-eAuQE3iZtg@mail.gmail.com> <CAE-m3X2rWk-0k_yH1PK0iN_5YhvSh1UsV0VCrroJq==687X1ZQ@mail.gmail.com> <52E43A80.4030501@rawbw.com> <CAGBxaXnfb2yPZZCaf6mYzASzT13b68A8iPT6eUwUdU9W1ya_Qg@mail.gmail.com> <52E44BC1.7040404@rawbw.com> <CAGBxaXkCWAAfA%2B7x9-icTwO4Vd78EGOeh5-4eG3DUJ_gGVHT1g@mail.gmail.com> <52E46D44.6050403@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jan 25, 2014 at 9:04 PM, Alfred Perlstein <alfred@freebsd.org>wrote: > On 1/25/14 3:48 PM, Aryeh Friedman wrote: > >> On Sat, Jan 25, 2014 at 6:41 PM, Yuri <yuri@rawbw.com> wrote: >> >> On 01/25/2014 14:44, Aryeh Friedman wrote: >>> >>> The key seems to be that no one has time to do the stuff they really >>>> want >>>> to do (get new ports into the system)... to that end automating >>>> everything >>>> that can be automated is sure help free up comitter time so they can >>>> look >>>> at what is interesting >>>> >>>> Yes. I just can't imagine any generic port tests that can't be >>> automated >>> and coded into the script once and for good. >>> Ideal system should be like github with the added automated testing >>> between pull request submission and merge. It should either fail and >>> notify >>> the submitter, or succeed and notify the committers. >>> >>> Git hup (or *ANY* remote service for that matter) is a no go IMO >> > > You just don't get it. > > Again, you just really, really, don't get it. > > You WANT a gateway to a remote service that the project does not have to > handle. > I am sorry your the one who does not get it.. not everything is either testable remotely or should be... how do you propose to test device drivers for example? > Why? Because then we offload the problem to another org. > With a hybrid cloud with most of the work being done on the commiters/developers machine where is the overhead? > > The FreeBSD project should be about innovation in OS design, platform and > software. Ops work is bunk and just slows us down. > Sorry to tell you but the ability to handle a complex automated system is one of the key things a OS must do... what better test then to build it self? > > The more we can outsource the better we'll be. (and what if that service > blows up? well we move on! it's simple!) > What a total cop out if the service blows up fix it... or should we end up with some of the real atrocities of linux like I/O times that are impossible (claiming it takes less then a second to copy 10GB for example)... note the above timing issue it makes resource scheduling next to impossible in a distributed environment if you get different timings for the same operation... bottom line writing and maintain a OS *IS* about operations and nothing else. > Continuing to insist that we run the services ourselves it just wasting > our limited resources. Not only that but we get emotionally attached to > technologies that are old, dying and dead when off the shelf stuff works > just fine. > I never said our selves it is outsourced to the developer/maintainer with 100% automated stuff... once I am doing with the next small version of petitecloud I will post the 6 line script we use to test the port (including cranking up a few vm's)... have fun doing that anywhere else > > -Alfred > -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGBxaXm8VJYVaFtcNvZH4FbMCxEw1gUsiOUQqx3o6nrcUTr5eQ>