From owner-svn-src-all@FreeBSD.ORG Thu Dec 4 21:35:09 2008 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F31F1065679 for ; Thu, 4 Dec 2008 21:35:09 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by mx1.freebsd.org (Postfix) with ESMTP id 26F9E8FC1A for ; Thu, 4 Dec 2008 21:35:08 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so4064347rvf.43 for ; Thu, 04 Dec 2008 13:35:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=2IX/OP+lIlA0paSb45aXeRX6uVQJg+zchs9jkmbe0Tc=; b=MpDgDOoOQse0a6Jb9RHSMcwpr/dG9J4/P1rK6lDtAPrfbmVtcRIsBmE/APL73HJXQC kImvPIqypgtgM4yZMbO/dJ7fzCjqk9ug0zp50oKk96i9YJDiv21XLqS1VaMSrvmZr/fl 8L5ySA3DWNlA2XxQIo0lc9/4GH88TkCmQ0AAc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=xGLiaVhIr8oKLvup3NapM8Lww8jvGbPqpojTUOBHwegzBG6Ong4NiVcP2Vfu+JWya3 zLlh96XTzFRsJ4jS3aqTgu41y2PV5DxL34l0mf0TVgG1IH2WtcYAMiDbtwVFFKWxCpFM 21LbOjgu3LzWCRzcNiX224L30JjJId/LjJNnQ= Received: by 10.141.176.4 with SMTP id d4mr7140842rvp.285.1228426508691; Thu, 04 Dec 2008 13:35:08 -0800 (PST) Received: by 10.140.158.13 with HTTP; Thu, 4 Dec 2008 13:35:08 -0800 (PST) Message-ID: <7d6fde3d0812041335u3134209at5a5f792e56290399@mail.gmail.com> Date: Thu, 4 Dec 2008 13:35:08 -0800 From: "Garrett Cooper" To: "Alfred Perlstein" In-Reply-To: <20081204194813.GT27096@elvis.mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <49338E98.7020104@freebsd.org> <20081201132554.GD27096@elvis.mu.org> <20081201.221040.-1350500631.imp@bsdimp.com> <20081204095756.GP27096@elvis.mu.org> <863ah4158t.fsf@ds4.des.no> <20081204163542.GQ27096@elvis.mu.org> <86k5afyhrb.fsf@ds4.des.no> <20081204180837.GS27096@elvis.mu.org> <86vdtzx0ns.fsf@ds4.des.no> <20081204194813.GT27096@elvis.mu.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, kientzle@freebsd.org, svn-src-head@freebsd.org, Dag-Erling Sm??rgrav , "M. Warner Losh" Subject: Re: svn commit: r185499 - head X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2008 21:35:09 -0000 On Thu, Dec 4, 2008 at 11:48 AM, Alfred Perlstein wrote: > * Dag-Erling Sm??rgrav [081204 10:21] wrote: >> Alfred Perlstein writes: >> > No, I'm trying to get a simple target that makes sense that will >> > prevent people from breaking tinderbox. (failing that then turning >> > tinderbox off because it's too complex) >> >> Perhaps if you tell me what it is about the tinderbox that you don't >> understand, I could help you understand it. > > I think I have all I need right now. I was getting confused > because I was being told by multiple confused developers that > "tinderbox" was different things because it's complicated. > > We should probably review all these committers and paddle them > or yank their commit bits for being stupid or something. > >> > Lets just say it takes a developer about an hour or two to be >> > "enlightened" as to a new system instead of just being told "hey >> > run this one liner", you've just soaked up $number_of_committers * >> > $enlightenment_time man hours. >> >> What is new about the build system? And why do you think it's a bad >> idea for committers to understand how it works? Do you really want to >> run an operating system written by people who do not understand how it >> is built? > > It should not be a requirement that a developer need to know > all this stuff. And by stuff I mean "how to roll my own tinderbox". > > I do find it amusing that you're asserting that _I'm_ saying this > when I'm the only one it appears that could fix this target. :) > > I'm more concerned about developing anything where I have to work > with people that don't take input on issues, yell at people for not > understanding complex systems and winge for god knows how long about > a 20 line patch just because it wasn't exactly "how they would have > done it"... WHEN IN FACT THEY REFUSED AND WOULD NOT HAVE "DONE IT". > >> > That and, since the process requires "enlightenment", you've caused >> > that developer to "page out" whatever they had in their head to work >> > on, _every time they commit_. Soooooo frustrating. >> >> I wonder - does anybody else than you have that problem? Don't you >> think that once people understand how the build system works, they would >> be able to do this without much thought? As a bonus, they will also >> know how to rebuild just the parts they modified, instead of the entire >> tree, shaving hours off the edit-compile-test cycle. > > Yes, that's great, but it should be optional. We shouldn't beat > things into people. > >> > And I'm done too! >> >> But in the process, you managed to piss off just about everybody who had >> an interest in the matter. > > That was your choice. So far I'm not aware of anyone that's quit > freebsd in the past few years due to anything I've done. > > (really done now) :) > > -- > - Alfred Perlstein Don't mean to stir up the hornet's nest any further, but I wanted to help constructively with this `issue': 1. I can see the logic behind what Alfred's doing, and I agree with it 100% with the following `terms': a. For generic kernel / userland codebase changes, a `tinderbox' target like Alfred put in, would be best for determining issues over the entire system. b. For codebase changes that are target/arch specific or contain target-specific driver code (for instance a MIPS specific net driver), it wouldn't really make sense to run Alfred's tinderbox for everything. c. For commit and after a merge, Alfred's `tinderbox' target should be executed. 2. I honestly think that the tinderbox target should be renamed to tinderfarm though, because I see the argument that DES is noting, mostly because of continuity. I do think that keeping a tinderfarm build target within the make system would be beneficial though, as it would allow the tinderbox Perl script to shrink and DES and I would be able to work out an agreement for making a tinderbox (/ tinderfarm?) script to be used as an overall functional and regression testing framework. 3. Devs understanding how the build system works to the extent where they can dig up manpages and become more proficient if necessary is crucial. I've seen some very negative effects of using wrapper scripts to execute builds, and I'd rather we not go this route, if at all possible. However, having a more abbreviated way of expressing builds is nice though, because most folks maintain this logic in wrapper scripts in local workspaces, and this information quickly gets out of date as time progresses :). 3. As for the issue with make universe, isn't there an equivalent to :: in pmake like there is in gmake? Targets can fail to build, but at least it'll continue moving on, and if the output messages are proper, one can note: `blah target failed' *shrugs*, and keep on moving on. Most devs should be using a break on build error make mode, whereas overall tinderfarm executions on the freebsd project servers shouldn't fail, IMHO. Thoughts? -Garrett