From owner-freebsd-ports@FreeBSD.ORG Wed Aug 16 12:37:32 2006 Return-Path: X-Original-To: ports@freebsd.org Delivered-To: freebsd-ports@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B32616A4DF for ; Wed, 16 Aug 2006 12:37:32 +0000 (UTC) (envelope-from novel@smtp.hispeed.ch) Received: from smtp.hispeed.ch (mxout.hispeed.ch [62.2.95.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id A789043EB0 for ; Wed, 16 Aug 2006 12:33:06 +0000 (GMT) (envelope-from novel@smtp.hispeed.ch) Received: from coredump.fannet.ru (R1-Vl6-82-116-56-21.fannet.ru [82.116.56.21]) (authenticated bits=0) by smtp.hispeed.ch (8.12.11.20060308/8.12.6/taifun-1.0) with ESMTP id k7GCX3L9002133 for ; Wed, 16 Aug 2006 14:33:04 +0200 Date: Wed, 16 Aug 2006 16:33:35 +0400 From: Roman Bogorodskiy To: ports@freebsd.org Message-ID: <20060816123335.GA42090@underworld.novel.ru> Mail-Followup-To: ports@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline X-PGP: http://people.freebsd.org/~novel/novel.key.asc X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on smtp-06.tornado.cablecom.ch X-Virus-Status: Clean X-DCC-spamcheck-01.tornado.cablecom.ch-Metrics: smtp-06.tornado.cablecom.ch 1377; Body=1 Fuz1=1 Fuz2=1 Cc: Subject: ports tree tagging again X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2006 12:37:32 -0000 --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I. Problems There are few things that I don't like in freebsd ports: 1. Binary packages are almost useless The chance to install all that you need using 'pkg_add -r' and some given time are very low. Some packages are outdated, some of them was not build because something of its dependencies failed, etc. That's very annoying... so you have to build almost everything yourself. It's just a waste of time, esp. if you have not very fast box. And it's not always possible to set up a local box for building packages, etc. 2. Port tree is unstable IMO, port tree is not very stable. I mean: we're all human and more or less often make mistakes and inaccurate commits. So you cannot be sure that if you cvsup/portsnap your tree, it will not break something (e.g. because of some typo). It's OK to have such errors in general, and we can do nothing with it, but there are a lot of silly errors which could be avoided and you definitely don't deal with on a stable system. II Solutions Yeah, I'm going to talk about ports tree tagging again :-). So what I propose: having HEAD and STABLE (or whatever you want't to call it,=20 so e.g. not to confuse with src/) branches. Committers commit all=20 patches to HEAD first. Then they wait for two things: - For next run on pointyhat to find out if package builds well (for a start, we could wait only for 6.x/i386 builds) - User feedback. Like, if there's no complains like "ahh, it broke everyhting, ahaha, please backout!", so everything's ok If both conditions are meat, the commit may be backported to STABLE. After some time, when the dust will settle up, STABLE will be really 'stable' and most of the ports in STABLE would build OK. So package building will be much faster, cause all ports will be in a rather good shape and it won't happen that a dozen ports fail just because of dependency problem. So we could have more or less working binary=20 packages ready to use, and always more or less stable branch. Now, when you cvsup ports, you cannot be sure everything works, moreover, something really importand maybe be broken, like e.g. bsd.sites.mk typos, etc. And it will cause extra pain cvsupting the tree again. So for systems where you care about stability, you could use STABLE. And about freezes, we can make them shorter with such an approach. We could tag RELEASE_X_Y of STABLE, no HEAD, so it would not take much time to fix all issues. And HEAD still will be open. Note that I'm not proposing keeping RELEASE_X_Y as security branch like it was proposed several times, though it's not incompatible with the approach described above. Comments are welcome! --ReaqsoxgOBHFXBhH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iQCVAwUBROMQn4B0WzgdqspGAQI95AP+Imfp2yv3hjhRsGmw/8SIn8GE3Ioiv+pE PPTwyoptsxytn3vO8CANQgBCSNaKNkNjxdrcahYeoN+1PlwJjeOsmlmNmrxxjTMO zlB7ALaTrFnghIVgBnIxb3E/ILBh6ZVsqglxHJgz3eM5RFfe5i/COg9Ad+fM5hMB WDZ0mFzQotc= =mSj0 -----END PGP SIGNATURE----- --ReaqsoxgOBHFXBhH--