Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 1 Dec 2007 11:56:42 -0600 (CST)
From:      Stephen Montgomery-Smith <stephen@math.missouri.edu>
To:        David Southwell <david@vizion2000.net>
Cc:        freebsd-ports@freebsd.org
Subject:   Re: duration of the ports freeze
Message-ID:  <20071201114644.H16007@cauchy.math.missouri.edu>
In-Reply-To: <200712010940.32888.david@vizion2000.net>
References:  <33640.194.74.82.3.1196149681.squirrel@galain.elvandar.org> <20071201105443.K15697@cauchy.math.missouri.edu> <47519484.6000408@gmail.com> <200712010940.32888.david@vizion2000.net>

next in thread | previous in thread | raw e-mail | index | archive | help


On Sat, 1 Dec 2007, David Southwell wrote:

> On Saturday 01 December 2007 09:06:12 Aryeh M. Friedman wrote:
>> Stephen Montgomery-Smith wrote:
>>> On Sat, 1 Dec 2007, Aryeh M. Friedman wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>
>>>> Stephen Montgomery-Smith wrote:
>>>>> On Sat, 1 Dec 2007, Aryeh M. Friedman wrote:
>>>>>> Stephen Montgomery-Smith wrote:
>>>>>>> Aryeh M. Friedman wrote:
>>>>>>>
>>>>>>> For some reason, people contributing to this mailing list
>>>>>>> are getting frustrated because some of the applications are
>>>>>>> now getting to be about a month old.  But why should we
>>>>>>> expect to have the latest and greatest in version number of
>>>>>>> application? It is because this is what we usually have,
>>>>>>> and so a periodic hiccup is out of the ordinary and so
>>>>>>> frustrates us.
>>>>>>>
>>>>>>> But suppose you are running Red Hat Linux instead.  Do you
>>>>>>> also get the latest and greatest in this super timely
>>>>>>> manner?  (To be honest this is not a rhetorical question,
>>>>>>> but my guess is "no.")
>>>>>>>
>>>>>>> In fact, who feels this frustration.  Is it the ordinary
>>>>>>> user? Or is it us port maintainers who wish they could get
>>>>>>> their more recent PR's accepted?
>>>>>>>
>>>>>>> Surely this frustration is felt by us because we have
>>>>>>> information that things could be a little more up to date.
>>>>>>> But if we weren't in the know, then we wouldn't be so
>>>>>>> upset.
>>>>>>
>>>>>> I am not suggesting we do a major overhaul before ports are
>>>>>> unfrozen... what I am suggesting is there is always room for
>>>>>> improvement and the frustrations voiced should be looked as
>>>>>> an opportunity to improve it instead of us (the complainers)
>>>>>> crying in our milk.
>>>>>
>>>>> I feel that your deflection of the points I made was a little
>>>>> unfair. My question is - why exactly is there a frustration?
>>>>> Is it because the FreeBSD community have somehow set
>>>>> expectations to be "totally up to date" a little too high?  Are
>>>>> we simply expecting more from FreeBSD than we get from Linux
>>>>> distributions or MS, simply because the average user has
>>>>> tremendous knowledge and insight into the internal development
>>>>> process?
>>>>>
>>>>> Remember, I'm just an average user, just like you.  I have no
>>>>> special axe to grind in defending FreeBSD.
>>>>
>>>> Even though this is best answered in a more systematic way (an
>>>> "official" review of the entire problem set) here are my reasons
>>>> for being frustrated:
>>>>
>>>> 1. There as has been some work that I am aware on ports I use
>>>> that has not bean released during the freeze for various reasons
>>>> (such as miro and qemu patchs [enable the use of physical drives
>>>> and run vista without crashing]).   None of them are pressing
>>>> enough for me to bypass the ports system because everytime you do
>>>> so you complicate upgrading (have fun keeping track of what you
>>>> installed from ports and what came from vendor tar's)
>>>>
>>>> 2. As a developer I have 3 ports I would like to release ;-)
>>>
>>> But this agrees with my original assertion - that the frustration
>>> is from the port maintainers and originators, rather than the port
>>> users.
>>
>> Actually item 1 is more important to me then item 2.
>>
>>> What solution would you propose.  The only one I can think of is
>>> that we have a ports-stable and a ports-current.  But I can see
>>> many people not liking this idea.
>>
>> An other solution (and one suggested by Huffman) is create a matrix of
>> what stuff has been tested against and on a port by port basis I can
>> set a tested vs. untested flag for what set of depenancies to use.
>> This is not much different then your idea just more fined grained.
>
> This is rather akin to my suggiestion made earlier today:
> which read:
> *****************
> "
> 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.
> "
> **************
> I think we are on similar tracks. Unless we get somnething like this we are
> going to face increasing difficulrties as time goes on. The number of ports
> will continue to increase and as the length of the freeze will therefore tend
> to increase proportionally (if not exponentially).
>
> The balance needs shifting and a method  that does not demand a freeze is now
> IMHO essential.
>
> David

These are all reasonably good suggestions for how to get around the ports 
freeze.  But they will come with a price, namely someone has to implement 
these changes (which I guess one of you would do), but also someone has to 
manage these changes and sort out the inevitable problems that will 
accompany them.  In other words, it will be quite a big logistic exercise. 
Furthermore the FreeBSD project tends to be conservative and resistant to 
big changes.

So what I think you need to do is to really convince others that the port 
freeze is not just an inconvenience/frustration (and personally I agree 
with you here), but that it is a major shortcoming with the current 
system.

For example, it is now clear to me that Aryeh is a cutting edge power 
user.  It is understandable that to him that this ports freeze is a major 
inconvenience, but it is also obvious that he has the technical 
capabilities to work around it.  His voice, and others like him, is not 
likely to sway the FreeBSD project.  It needs a lot more average users who 
are also complaining.

This is why I compare FreeBSD with other OS's and their distributions, and 
ask the question - is this frustration there simply because we know so 
much about the inner decision making as to why there is a ports freeze?


So here is another suggestion.  Perhaps those who really want the latest 
and greatest could implement a private ports-current.  This would look at 
all the extant PR's that are wating for the ports freeze to finish, and 
implement them.  Sure it would be a hassle to maintain, and a headache 
when the freeze is over to put things back.  But there is a similar hassle 
to adopt the proposed schemes for everybody, and it just isn't clear that 
this is something that would benefit many.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071201114644.H16007>