Date: Mon, 1 Jun 2009 18:35:21 +0000 (UTC) From: "Bjoern A. Zeeb" <bz@FreeBSD.org> To: Ken Smith <kensmith@cse.Buffalo.EDU> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r193241 - in head: . sys/sys Message-ID: <20090601182802.N12292@maildrop.int.zabbadoz.net> In-Reply-To: <1243880140.25229.23.camel@bauer.cse.buffalo.edu> References: <200906011807.n51I7ccW086812@svn.freebsd.org> <1243880140.25229.23.camel@bauer.cse.buffalo.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 1 Jun 2009, Ken Smith wrote: > On Mon, 2009-06-01 at 18:07 +0000, Bjoern A. Zeeb wrote: >> Author: bz >> Date: Mon Jun 1 18:07:38 2009 >> New Revision: 193241 >> URL: http://svn.freebsd.org/changeset/base/193241 >> >> Log: >> Decrement __FreeBSD_version again to 96 as we are runing out of digits >> and want to be conservative - so not more than one version bump per day. >> >> Discussed with: jhb, kensmith > > It was noted we're close to running out of numbers we can use before we > hit code freeze and the branch for the release. Since we're entering > code slush at the end of today in theory all changes that would warrant > a bump in __FreeBSD_version are supposed to be done. But it wouldn't > surprise me if we have one or two or so things that come along between > now and when we hit code freeze and the branch. So we need to be a bit > conservative with this. Please be sure to coordinate anything that > might require a bump in __FreeBSD_version with re@ from now on. If it > turns out things do come along that require bumps we'll need to "batch > them up" having one bump represent several changes. Talking about "padding of structures", as this will be one of those changes most likely, I had suggested previously in private email: Can't we start collecting all those somewhere, perhaps on the wiki, and do one big padding day, one commit for all and everything? This would have several advantages: 1) no ABI breakage in HEAD as v-structs would possibly change in size 2) actual documentation of A|KB|PI relevant structures which would be good to have them written down finally after I heard people talking about this for multiple releases now. 3) a list of things we might need to work on in the future to reduce the problem and also a list for the time 9.x would come;-) just my 0.01$ /bz -- Bjoern A. Zeeb The greatest risk is not taking one.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090601182802.N12292>