Date: Sat, 01 Dec 2007 13:28:01 -0500 From: "Aryeh M. Friedman" <aryeh.friedman@gmail.com> To: Stephen Montgomery-Smith <stephen@math.missouri.edu> Cc: David Southwell <david@vizion2000.net>, freebsd-ports@freebsd.org Subject: Re: duration of the ports freeze Message-ID: <4751A7B1.6030409@gmail.com> In-Reply-To: <20071201114644.H16007@cauchy.math.missouri.edu> 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> <20071201114644.H16007@cauchy.math.missouri.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Stephen Montgomery-Smith wrote:
>
>
> 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.
It is a price either paid up front (like we are suggesting) or paid
later when the now barely maintainable ports system finally
collapses. My main issue is the lack of good depenancy tracking
(leaving it to the preview of each port I think is asking for it in
the long run) and some rather inconsistent behaviour between say the
following three options:
cd /usr/ports/{some metaport}
make install
portinstall {some metaport}
and
pkg_add {some metaport}
An other side issue is the system needs to allow for greater
grainlarity (which is only possible once better dependancy tracking is
done). For an idea what I am talking about compare say make to cook
and cvs to aegis.
>
> 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.
My arg is the system is starting to show the strain of 15k+ ports with
metaports needing to track hundreds of dependancies.
>
> 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.
The fact that it is inconveint for any given person or wither or not
they have the skill to by pass the system doesn't let the system off
the hook.
>
> 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?
And this is no reason not to seek continuous improvement and overhaul
of subsystems that are really showing their age. The ports system is
essencially unchanged since at least 1995 when I first started using
FreeBSD.
>
>
> 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.
The worst of all suggestions on the table.... it creates more work and
many more possibilities for inconsitencies then even the current
system also how do we reconcile the diffs between how I might fix
something and port manager might... I think one look at congress
should show this totally fails.
- --
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
iD8DBQFHUaew358R5LPuPvsRAuJCAKDNP1p3Ar2ooqEE9Yzz2L+OhSIDBgCeLe9F
LGnHduLEXMB4olzLXlcRGwI=
=kIB1
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4751A7B1.6030409>