Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 6 May 2015 01:56:13 +0000
From:      Glen Barber <gjb@FreeBSD.org>
To:        freebsd-arm@FreeBSD.org
Subject:   Heads-up regarding arm/armv6 snapshot builds
Message-ID:  <20150506015613.GF67741@hub.FreeBSD.org>

next in thread | raw e-mail | index | archive | help

--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--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150506015613.GF67741>