Re-engineering the port system (was Re: duration of the ports freeze)

[Garrett Cooper]

On Dec 1, 2007, at 12:15 PM, Aryeh M. Friedman wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Erik Trulsson wrote:
>> On Sat, Dec 01, 2007 at 11:49:11AM -0800, David Southwell wrote:
>>> On Saturday 01 December 2007 10:28:40 Erik Trulsson wrote:
>>
>>>> Personally, as a user, I have never really been even slightly
>>>> inconvienced by any of the ports tree freezes.
>>> All I can say is bully for you! The question is how do we get rid
>>> of a p[roblem even if it is not a disadvantage for you
>>> personally. It is disappointing when one hears arguments not to
>>> change simply because one particular individual is not
>>> disadvantaged by a currently illogical and antiquated solution to
>>> a problem that will inevitably grow as the number of ports
>>> increase.
>>
>> I am quite certain that I am not alone or even unusual in not
>> having a problem with the current situation.  I believe that for
>> the majority of FreeBSD users the port freezes do not constitue a
>> major problem - or even a problem at all.
>
> First of all I am not in the least inconvenienced by the freeze as a
> user because I just ask maintainers for yet to be committed ports to
> send me the needed files.   My issue is the lack of longterm
> scalability of the system (some people say n years away where n>10...
> I am not convinced we should look at the actual curve before making
> any guesses).
>>
>> The current situation apparently constitute a problem for you,
>> which is too bad, but you have failed to convince me that you are
>> representative for more than a very small minority of FreeBSD users
>> - and it is of course not possible to satisfy everybody.  (And it
>> is anyway not me you need to convince, since I have no official
>> standing at all in the FreeBSD project.)
>
> I don't know about David but there is no issue for me beyond having to
> wait like everyone else but being involved with large system creation
> I understand the need.
>>
>> As for your earlier claims that the process is developer-centric
>> rather than user-centric, I would say that claim is just plain
>> wrong. If anything I would say the code-freezes of both the base
>> system and the ports tree is more inconvenient for the FreeBSD
>> committers and port mainttainers than for the average user. The
>> intent is to make sure each release is in good shape, in the belief
>> that this is what is most important for the average user (from
>> which follows that the state of the ports tree between releases is
>> of somewhat lesser importance.)  This belief might of course be
>> wrong, but so far little evidence has been given to contradict it.
>
> Like I said in a different subthread this is a problem that has been
> addressed theortically for a number of years.
>>
>>
>> It is disappointing to hear arguments to change simply because one
>> particular individual is disadvantaged by the current situation,
>> without any regard given to the fact that such a change might
>> actually inconvenience a larger number of people.
>>
>
> Thats why I changed the subject because it is clear to me at least
> none of the issues being discussed have anything to do with the
> current freeze.
>
>
> - --
> Aryeh M. Friedman
> FloSoft Systems
> Developer, not business, friendly
> http://www.flosoft-systems.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.4 (FreeBSD)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHUcDf358R5LPuPvsRAhnZAKDnGd6Bn8+iNjPG2kGuMQGi3HmSLQCdGvd9
> dCJX+QxW2QCULeOVCF9Hxms=
> =48q4
> -----END PGP SIGNATURE-----


	Perhaps a better way to approach these types of freezes is to freeze  
the tinderbox / build machines for the duration of the release, while  
the required packages are being made, then resync the servers after  
all of the packages have been completed. Or (if inconsistency with  
current release candidate users is an the reason) maybe have a built- 
in mechanism which would only sync with particular snapshots of the  
ports tree (or just CVS tag the snapshot accordingly), and provide  
users with nasty warning messages if they chose to update to a HEAD  
copy?
-Garrett