Skip site navigation (1)Skip section navigation (2)
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>