From owner-cvs-all@FreeBSD.ORG Mon Sep 19 01:11:28 2005 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41C7E16A41F; Mon, 19 Sep 2005 01:11:28 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCBCF43D45; Mon, 19 Sep 2005 01:11:27 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id A45822C58; Sun, 18 Sep 2005 20:11:26 -0500 (CDT) Date: Sun, 18 Sep 2005 20:11:25 -0500 To: Ion-Mihai Tetcu Message-ID: <20050919011125.GD28903@soaustin.net> References: <200509182034.j8IKYCUv065506@repoman.freebsd.org> <20050918234714.41544927@it.buh.tecnik93.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050918234714.41544927@it.buh.tecnik93.com> User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) Cc: Clement Laforet , cvs-ports@FreeBSD.org, linimon@FreeBSD.org, cvs-all@FreeBSD.org, ports-committers@FreeBSD.org Subject: Re: cvs commit: ports/devel/portmk/Mk bsd.apache.mk bsd.database.mk bsd.java.mk bsd.port.mk bsd.port.post.mk bsd.port.pre.mk bsd.port.subdir.mk bsd.tcl.mk ports/devel/portmk/scripts distfiles.sh options.pl options.sh ranksites-fping.pl ... X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2005 01:11:28 -0000 On Sun, Sep 18, 2005 at 11:47:14PM +0300, Ion-Mihai Tetcu wrote: > > - Remove temporarily all eik's work. We'll try to find a decent way > > to deal with major changes. Of course we'll reuse his good ideas > > The ranksites* part would be very useful. The problem with eik's changes was that he combined refactoring with rewriting and this practice always makes it problematic to figure out exactly what has changed. So if some obscure problem showed up during testing (or worse, in production) -- and that is almost guaranteed with several thousands of lines of make/sh/awk/sed/ perl magic -- it would have been problematic to track it down. Since eik's last update to portmk just less than a year ago, a lot of infrastructure has changed -- we've committed a number of changes to bsd.port.mk. In particular, moving out particular pieces related to specific subsets of ports will IMHO help us to figure out what future changes ought to be. (Some of these we've already done; some, like bsd.database.mk, bsd.apache.mk, and hopefully bsd.x11.mk, lie in the near future). In addition, after reading through the bsd.port.mk PRs myself just yesterday, I have rediscovered that there was significant effort to create bsd.perl.mk, which foundered due to ongoing problems regression-testing against a number of perl ports that were not compliant with the assumptions built into it. I'd like to hope that we can restart that process as part of this rework of devel/portmk. (From the PR, it seems like the original submitter of it abandoned the idea in frustration. While I feel bad about this, there's no way to go back into the past and change that.) For those interested: http://www.freebsd.org/cgi/query-pr.cgi?pr=55515 . There are two major factors that I'm hoping will make a difference in the adoption of ports infrastructure changes going forwards, as opposed to a year ago: - It should now be much easier for individuals to do regression testing using the Marcuscom tinderbox code (http://tinderbox.marcuscom.com). This should make it much easier for many people to be testing proposed patches, and thus require less stopped and restarted runs across the whole set of buildenvs when they are tested on pointyhat. - We (the Project as a whole) now have a much better understanding of how FreeBSD ought to do Release Engineering in the future, including the effect that src QA (since it effectively determines the length of ports thaws) has on the ports tree development cycle. Hopefully this will lead to the tree being in freeze and/or slush much less of the time. To see how much this has hurt us in the past, see the last graph in http://people.freebsd.org/~linimon/schedule.html. mcl