duration of the ports freeze
peter.thoenen at yahoo.com
Sat Dec 1 05:30:53 PST 2007
David Southwell wrote:
> On Saturday 01 December 2007 Pav Lucistnik <pav at freebsd.org> answered part of
> the question:
>> On Friday 30 November 2007 21:47:07 Jason C. Wells wrote:
>>> Peter Jeremy wrote:
>>>> On Fri, Nov 30, 2007 at 03:04:14PM -0600, Mark Linimon wrote:
>>>>> On Fri, Nov 30, 2007 at 07:50:02AM -0800, Jason C. Wells wrote:
>>>>>> It wouldn't surprise me if portmanager is hoping that KDE 4.0 will go
>>>>>> prime time real soon. That's my big conspiracy theory.
>>>>>> package builds out the door. The Razor, and past experience, would
>>>>>> suggest that sweeping changes would delay all that significantly.
>>>>> As a corollary, KDE4 will not hit the ports tree until after 7.0 and
>>>>> 6.3 are released.
> .> >
>>>> We lucked out last time and got current updates of both gnome and kde.
>>>> "It would be a pleasant surprise if portmgr were able to take KDE 4.0 to
>>>> prime time real soon."
>>> I must say I am having difficulty understanding the policies applicable
>>> during ports freeze.
>> What criteria are used to determine whether an update is allowed or barred
>> during the freeze?
> Pav Lucistnik <pav at freebsd.org> answered part of the question with this
>> David Southwell píše v so 01. 12. 2007 v 03:08 -0800:
>>> What criteria are used to determine whether an update is allowed or barred
>>> during the freeze?
>> 1) Security update
>> 2) Build fix on one of the release platforms
>> 3) Major runtime fix
> This seems sensible unless:
> a) The freeze is unduly long (I would suggest more than two weeks)
Actually IIRC when 5.0 and 6.0 first came out they had *unduly* long
port freezes also, more so than the normal X.1, X.2, X.n release cycles.
I think the issue is the large number of ports than simply break on a
major release (gcc4.x is causing problems w/ 7.0 I believe) and then
trying to create 7.0 specific patches or ween them from the release iso.
As such, this takes time.
>> I would hgowever like to ask, on the basis of what is being learned
>> now,how could the length freezes be diminished on future occasions?
When the port freeze first hits I believe they always release a URL to
all the packages currently having build problems on the forthcoming
release. If you want to cut down on the time of the freeze, try
arbitrarily fixing some of them so the port managers don't have to. Not
all ports have diligent maintainers and not all ports even have
More information about the freebsd-ports