duration of the ports freeze

[David Southwell]

On Saturday 01 December 2007 05:22:51 Mark Linimon wrote:
> On Sat, Dec 01, 2007 at 03:08:43AM -0800, David Southwell wrote:
> > I must say I am having difficulty understanding the policies applicable
> > during ports freeze.
>
> I had hoped that http://www.freebsd.org/portmgr/qa.html and
> http://www.freebsd.org/portmgr/implementation.html would have been clear
> enough on what the policies are -- that was the motivation for writing
> these documents.
>
> > The freeze seems to be of longer duration than originally expected
>
> As are most of them.  Welcome to the world of software engineering
> schedules :-)
>
> > I would however like to ask, on the basis of what is being learned now,
> > how could the length freezes be diminished on future occasions?
>
> After the 5.3 release, there was a lot of discussion between the ports
> management and release engineering teams on how to do exactly that.
>
> To some extent we're dependent on the state of the source tree; changes
> that affect the ABI cause us to have to go back and re-do package sets.
> The release engineers are now much more aware of this impact that they
> were in the past.  However, .0 releases are particularly difficult on
> this front, since we have to live with any ABI mistakes for several
> years.  Thus, it's worth a delay to avoid having to support a bad or
> questionable implemenation.  Unfortunately, these are often not caught
> until the prelease starts to get widespread testing outside of the
> developer community.
>
> Another cause is that we're trying to get as many packages buildable and
> useful for release as we can.  This is particularly important for the
> non-i386 architectures, which do not have as large a user base.
>
> Note: this time we waited to start the freeze until nearly the RC1 date --
> in the past, we had done it earlier in the beta cycles.  There's nothing
> to be done when RC1 slips, however; we want to have as good a package
> set entering RC1 as we can get.
>
> In the meantime, the number of working packages is probably close to an
> all-time high numerically (I don't have enough sense of historically to
> say percentage-wise, although I suspect it's a recent maximum).  Folks
> can help out by trying to install systems just from the packages and
> letting us know what problems they find.
>
It seems to me we have a good definition of the problem but, at the risk of 
giving offence, I am going to suggest that we have gone about solving it the 
wrong way. I am going to propose a solution that some may find controversial.

Before I do so let me  step outsiide the freebsd environment and ask what our 
comments would be if MS$ were to announce that they were about to release an 
upgrade to their operating system and until the new upgrade had been released 
upgrades to existing applications would be barred. I am sure we would all 
agree that that was ridiculous. But that is the result of our current 
practice.

What proportion of freebsd users will immediately upgrade to the new 
releases?? Maybe 5% or 10% at the most. Mosty users will stick with their 
existing release. This means that 90 - 95% of users are being seriously 
inconvenienced by the existing port freeze methos. The question is can we 
find an alternative??

How about maintaining the port tree as usual during the pre release period. By 
default all releases in the tree prior to a selected date should incorporate 
a release dependency in their makefile that would NOT include the pending 
future release.

As each port is tested against the new release its release depency would be 
changed and upgardes could continue to be added to the tree as normal.

This would mean the majority are not being inconvenienced by the needs of a 
tiny minority to artifically hasten changes to ports to ensure they are 
compatible with the new release.

At the moment the tail is wagging the dog and it is becoming less and less 
acceptable that we should continue to operate in way that many may feel is 
somewhat quaint but seems IMHO to be increasingly arcane and out of touch 
with the needs of most users.

David Southwell