Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 16 Aug 2006 19:36:46 +0200
From:      Jean-Yves Lefort <jylefort@FreeBSD.org>
To:        Roman Bogorodskiy <novel@freebsd.org>
Cc:        ports@freebsd.org
Subject:   Re: ports tree tagging again
Message-ID:  <20060816193646.dbda70b7.jylefort@FreeBSD.org>
In-Reply-To: <20060816123335.GA42090@underworld.novel.ru>
References:  <20060816123335.GA42090@underworld.novel.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
--Signature=_Wed__16_Aug_2006_19_36_46_+0200_JeNVERiJLup.6e9h
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, 16 Aug 2006 16:33:35 +0400
Roman Bogorodskiy <novel@freebsd.org> wrote:

> I. Problems
>=20
> There are few things that I don't like in freebsd ports:
>=20
> 1. Binary packages are almost useless
>=20
> 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.
>=20
> 2. Port tree is unstable
>=20
> 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.
>=20
> II Solutions
>=20
> 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
>=20
> 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.
>=20
> 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.
>=20
> 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.

I agree with your analysis and solution.

--=20
Jean-Yves Lefort

jylefort@FreeBSD.org
http://lefort.be.eu.org/

--Signature=_Wed__16_Aug_2006_19_36_46_+0200_JeNVERiJLup.6e9h
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)

iD8DBQFE41euyzD7UaO4AGoRAt+JAJ9K9TqViRw9Tx9gYpF4dyNgAJ3IugCdHwis
Zw5BnjD/YjnZvSSxFpGMDo8=
=Ms2k
-----END PGP SIGNATURE-----

--Signature=_Wed__16_Aug_2006_19_36_46_+0200_JeNVERiJLup.6e9h--




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