From owner-freebsd-arm@FreeBSD.ORG Wed May 6 01:56:26 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29ECB8F9; Wed, 6 May 2015 01:56:25 +0000 (UTC) Date: Wed, 6 May 2015 01:56:13 +0000 From: Glen Barber To: freebsd-arm@FreeBSD.org Subject: Heads-up regarding arm/armv6 snapshot builds Message-ID: <20150506015613.GF67741@hub.FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wtUqn8XWZYmnPFNh" Content-Disposition: inline X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 01:56:26 -0000 --wtUqn8XWZYmnPFNh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [re@ in BCC.] Before I proceed with what I'm about to say, I want to be absolutely clear that I love the path Crochet has paved for the FreeBSD Project. Crochet, however, moves entirely too fast, and in that rapid pace of change comes backwards-incompatibility. For example, it took me two weeks to figure out that the broken builds for the snapshots we (RE) provide on FTP were because of the rename of 'AutoSize' -> 'Growfs'. In the general case, this would be fine, however Crochet has yet to branch a 'release' tag. In other words, everything in the top of the tree is a moving target, and tracking a specific commit revision is not only non-ideal, but not at all productive. That said, this week's snapshot builds, those that have just finished (or failed, as several cases may be), will be the final RE-provided snapshots built with Crochet. I simply cannot keep up with the rapid change list of Crochet on a weekly basis, and we as a team cannot possibly be expected to modify release build code during the release cycle. Especially when the change needs to occur when we switch from -RC3 -> -RELEASE builds. The lack of integration between the two systems has become far too painful at this point. I, with my RE hat on, have decided to focus the majority of my time over the next few days on the ^/projects/release-arm-redux branch, decoupling Crochet from the process entirely. Again, while I love Crochet for the general usage, its rapid change now has become extremely problematic to track for release/snapshot builds. This email isn't to complain about the state of things, but to clearly outline the minimum requirements (a.k.a., rules that must be met) for future arm/armv6 (and any other architectures that may arise in the near future). As of this point, the only "rule" moving forward is, if your platform needs u-boot, there *must* be a corresponding port in the Ports Collection. (See the various sysutils/u-boot-* ports for examples.) This is a requirement, not a request. We will no longer fetch u-boot sources from arbitrary FTP locations, vcs-of-the-day repositories, etc. As of this writing, the board we currently build that does not have a corresponding u-boot port is the ZEDBOARD kernel. This also brings to mind another few inconsistencies that prevent the use of Crochet moving forward - the port provides something Crochet does not expect and/or cannot use. For reference, see this commit where I've managed to work around an issue that I'm extremely unclear of the reasoning: https://svnweb.freebsd.org/base?view=revision&revision=282515 These types of "fixes" are not acceptable solutions, and moving forward, we cannot proceed as we have been. It does not scale well between the FreeBSD sources and Crochet sources, and definitely does not scale between the FreeBSD branches for which we provide arm/armv6 snapshots. Interested parties that want to help can take a look at the release-arm-redux branch mentioned above. But I strongly encourage those that want their SoC to continue to be supported when the branch is merged to head (and subsequently to stable/10) to make a port of the u-boot where it is required. Thank you. Glen Hat: RE --wtUqn8XWZYmnPFNh Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVSXS3AAoJEAMUWKVHj+KTYWIP/2kb7SNdf4P/3G5s4lpc3XPU FrXKn5yQQ3xX+SHNQplblojjRzrloCsfJdhoR8Ty4+xMNzaJGy30CC6HNfxgKhMz 5+vdYiGagM+Bqz7VGIdOTzfqJWZepigrLTQKqFwh52rp4hosjTppmE+jMK8EtMTy 0ogfT3aq+AWtvjzBgBvx6l/FuzJFPZhP81e5tobsZKuGXYDi/JOG/kXnCVEeXfTe nkeqO3Bp5QijyG3PoGWhYl1wC70olYcwCEvW+ybSZL6GrEDJuDifNlxN4JiZnoJa 6kSeo6AqiwAibS+AzPqqWEQGzqk+EOGDM/4B+wZm0YGHpXBsr+Ev9cji7Cl9axe5 Y3fMf/tEXqkjg27i7tb3NS31fblVxBeYyEBLcYCSXVWr/22v9Zrxe2hk6ZFaXzBp Y3dIlFjYA/LBjnmZwTrZRMC4f+SUos9h2TSRHhI4i4/NDLAr3E4BOkPnNtA8BttP 16n2j5CtteHm1vQ4oRHxZ91MukKSltq1Ct0OF4G8HDBZAUSt+dVIF8/pO0F7ZVf0 v/VaqXcbOTq8GyzJFi1Zqp6r/eaV+WQlj0i3k2kOWOQaYW7KIXqqpgwDtsg7CqQg Ma+7FePhfTC+aNHloH0RffhyS80t3elTj91xnzbWfcP3OyZEYsM16m695lqnU9tG HEaoD9ll2AUb+ISFrwE/ =0HYj -----END PGP SIGNATURE----- --wtUqn8XWZYmnPFNh--