Date: Tue, 02 Jul 2002 18:44:07 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Jan Lentfer <Jan.Lentfer@web.de> Cc: freebsd-alpha <freebsd-alpha@freebsd.org> Subject: Re: List of ports that can be compiled with compaq-cc Message-ID: <3D2256E7.596D91F9@mindspring.com> References: <3D21F1C8.2010708@web.de> <15650.6127.427432.57976@grasshopper.cs.duke.edu> <3D22188C.2000603@web.de> <3D222E25.62D5E4D0@mindspring.com> <3D222EF3.8070700@web.de> <3D223E91.A71CC743@mindspring.com> <3D224716.901@web.de>
next in thread | previous in thread | raw e-mail | index | archive | help
This discussion would probably be incredibly interesting to the "Open Ports" people... Jan Lentfer wrote: [ ... ] I find what you've chosen to quote and not quote very interesting. You suggested getting together a list of ports that work with the Compaq compiler. There is no possibility that such a list could be resonably current, maintained, and relevent. Therefore, I cut to the heart of the problem you were apparently trying to solve: availability of ports that could be compiled with the Compaq compiler. Your original posting made an incorrect assumption, that what was missing was the act of identification, and that such identification would be persistant, or at least remain valid for a significant period of time. --- So let's say that you found V volunteers. Each volunteer could manage status on M ports per month. This gives you a queue fill rate of V * M total ports/month: R(F). Call the total number of ports P. If the queue drain rate were 0, then that means your task would be complete in P/(V*M) months. So far, this is based solely on the participatory nature of the group of volunteers you assemble: it is not a case of "IF", but instead of "WHEN". But, of course, the queue drain rate is not 0; it's positive, and it case more than one contributory factor: o New ports One of the issues you have to consider is that there are new ports being added all the time. Therefore, P is not a constant, it is an increasing amount. P has a rate of increase, which we shall call R(P). Now there are two cases: your rate of fill exceeds the rate of increase of P; thus, you have a convergent series: R(P) < R(F) Or a divergent series: R(P) >= R(F) In the divergent case, your project never completes, and, in fact, loses ground relative to the total number of ports. Thus, after you start the project, a consistently decreasing percentage of ports have been vetted by your volunteers. However, this is a linear relationship; thus it's barely possible that you can keep up by increasing V, as a linear scaling factor. In other words: add volunteers. For the sake of argument, let's say that, in fact, you are capable of fielding sufficient volunteers that you can catch up with the number of total ports at some point... that, in fact, we are talking about a nominally convergent series -- in other words, let's assume that it's worthwhile to embark on your project in the first place. What are the other factors? o Updating of already vetted ports People will continue to update ports. As FreeBSD itself goes forward, ports will require new patches for include files, among other things, which will damage the ability of an already vetted port to be compiled with the Compaq compiler. At this point, we have a loss rate; this rate is equal to the rate of ports update, R(PU), multiplied by the number of already vetted ports (a linearly increasing value) divided by the number of total ports (a linearly increasing value). We have already accepted that these values are converging. Therefore, we now have an exponential rate of increase in the number of ports that will not compile with the Compaq compiler. This exponential is based on the fact that, as the number of total ports increase, the number of ports that have not been vettwed will increase, and the number of vetted ports which will be modified to the point of having invalidated the vetting, will also increase. At this point, you have a linear queue fill, with an exponential queue drain. It is not possible to overcome this. Even if you were to drive through with a high enough initial R(F) that you were able to outpace the rate of increase in new ports, R(P), and thus "catch up" with the total number of ports, at some point, the constant fractional rate of modification per port, multiplied by the number of total ports, will cause the number of updates to exceed the the "spare cycles" obtained by "catching up" with the total number of ports; i.e., you will get to the point that: R(U) > R(F)-R(P) "But wait!", you say, "The value R(U) is fractional! Not all updates will break a preexisitng vetting!". Yes, this is true, as far as it goes. However, the vetting is only valid with regard to the ports where the vet date is after the last update date (or the creation date, if there have been no previous updates). As soon as a port is updated, it becomes suspect, and must be revetted. Even if the result of this is that the vetting maintains its previous validity. HOW TO FIX THINGS So how do you escape the fact that you've built a damped, driven harmonic oscillator, where the damping force currently exceeds the driving force, but both the damping and the driving are increasing, and the total damping relative to the total driving is decreasing... and you see a point in the future where it will be overwhelmed? The answer is that you need to remove the exponential coupling for the driving force, so that both progressions are linear. We've been assuming that a large enough V will maintain the: R(P) < R(F) relationship. This is true in the decoupled case. THe way this works is that the required volunteer effort for vetting is a fraction of the effort required for inital porting. Thus we have a ratio of volunteer porters to volunteer vetters that is able to maintain a higher fractional rate of increase, so long as the ratio does not exceed some small sigma -- to return to our analogy, the increase in damping force is faster than the increase in driving force. [ there are a number of factors, like the fact that Alpha is itself a minority platform, which affect the ultimate value of sigma; but all wee care about is its value after these factors are taken into account ] How to decouple? The way you need to decouple is by enlisting people who are not volunteers as involuntary volunteers. The easiest way to do this is to enforce the use of your vetted values, and to enlist the ports volunteers themselves -- also, unwillingly -- through complaint-coupling. To do this -- to have this emergent property -- the system you devise to approach this problem needs to have the necessary attributes that cause the coupling itself to be an emergent property, while at the same time damaging the coupling effect of the ports modification. The simple way to do this is to: 1) Set the inital rules to lower participation for your own volunteers. The way to do this is to build the vetting in as a switchable preset that is there for your own people to use in the vetting process. In other words, you are building a system with the lowest sigma you can get. In this case, the way to do that is to build the Compaq compiler support into the base ports system in such a way that it is non-intrusive for other users of the ports system. I've already described how to do this. To be more generic, rather than explicitly expecting the Compaq compiler, you could also support the concept of an "ALTCC" -- an alternate compiler, being agnostic about which compiler it is. 2) Reduce the breakage rate, and retarget problem reports This is devaluation of the effect of P(U) to zero. The simplest way to do this is to permit the conversion, after the point where you "catch up", of the Compaq compiler from a permissable option to a dependency. In other words, you make the ports that *can* be compiled with the alternate compiler *prefer* the alternate compiler, initially. Then you make them *require* the alternate compiler. At this point, vetting failures as a result of R(U) are self-flagging, and generate complaints to the maintainers of the ports, not the maintainers of the vetting process. This all presumes that the initial assumption: R(P) < R(F) is true... and that you "catch up" with the total number of ports before you throw the "requires" switch. So... it;s possible to build a system with the emergent properties that you want it to have, and get those properties as an indirect, rather than a direct effect. > Again, sorry if I am not very firm with hows-and-whos of FreeBSD, but > please be a little more easy on me..... This has nothing to do with "the ways of FreeBSD"; it has to do with emergent properties of Open Source Software projects, in general, and how to manipulate the minimum necessary sets of values in order to obtain the desired results. If you start off with just a vetting list, you are doomed to failure; it is a foregone conclusion, a mathematical certainty. Likewise, if you fail to provide a mechanism for coupling the negative attractors to the other side of the equation you are writing. If you want to succeed, you will examine your queue fill and drain rates, and your pool retention time, relative to the existing system that you are attempting to leverage to obtain your results. Note that my suggested methods of achieving this are not necessariy optimal; they are, however, workable and, I think, fairly *close* to what the optimal solution would have to look like. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D2256E7.596D91F9>