From owner-freebsd-ports@FreeBSD.ORG Sun Jan 26 02:18:10 2014 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6DB19B1E; Sun, 26 Jan 2014 02:18:10 +0000 (UTC) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 366111D2C; Sun, 26 Jan 2014 02:18:10 +0000 (UTC) Received: by mail-pb0-f43.google.com with SMTP id md12so4620723pbc.16 for ; Sat, 25 Jan 2014 18:18:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=to4I0l4RW60lo1RcT0lVS+yYEKFlNGOhWjj9ylCHCM8=; b=y0ZakUFFLfAJ2NbSAwteH+M3z7xTTjIO8MpoR/3ahCdxeX+5iajG9uK8HA5/yzCvLe OsTmS1Zyif4UjIN/4pJ/E0gBd/UaQRbIoD4YV5n0fq4TB5Ux3fwaTuWhj1I3eKnoWENc Wl31iqdFASNM8oxAc7SDbjMf7Z8NJGc6xp2KUkCkKf3KbxidVijjdvVrhfUJMp/VU6bx gusDLd/TijMFbM3os+KUx87iKCsQQtVNYtPuGldUyPCSVmpMRh3pF8rCf6ihWBPh4zuI h6fR1UjF3ws80C5QYEzoiaspUtMmHQvnUZ5KC0Q/706CE6VJ4xxdZKtSyyZ2Zt0Ceko0 +Ylw== MIME-Version: 1.0 X-Received: by 10.66.121.234 with SMTP id ln10mr22615665pab.20.1390702689852; Sat, 25 Jan 2014 18:18:09 -0800 (PST) Received: by 10.68.155.38 with HTTP; Sat, 25 Jan 2014 18:18:09 -0800 (PST) In-Reply-To: <52E46D44.6050403@freebsd.org> References: <52E43A80.4030501@rawbw.com> <52E44BC1.7040404@rawbw.com> <52E46D44.6050403@freebsd.org> Date: Sat, 25 Jan 2014 21:18:09 -0500 Message-ID: Subject: Re: What is the problem with ports PR reaction delays? From: Aryeh Friedman To: Alfred Perlstein Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: FreeBSD Ports ML X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 02:18:10 -0000 On Sat, Jan 25, 2014 at 9:04 PM, Alfred Perlstein wrote: > On 1/25/14 3:48 PM, Aryeh Friedman wrote: > >> On Sat, Jan 25, 2014 at 6:41 PM, Yuri 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