xf86CheckBeta() and friends

Stuart Kreitman Stuart.Kreitman at Sun.COM
Fri Nov 12 09:28:14 PST 2004


Daniel Stone wrote:

>On Fri, Nov 12, 2004 at 07:46:15AM -0800, Stuart Kreitman wrote:
>  
>
>>I would like to see an explanation in the email archives that briefly
>>explains what it is and why its undesireable. (tho the StrongBad
>>argument was a chuckle)
>>    
>>
>
>If you compiled XFree86 with a certain set of flag (USE_FLAG or
>something, and BETA_EXPIRY, ...), it would produce a binary that would
>not work after a specified date.  This was used for *binary-only* beta
>releases of XFree86, where they wanted to ensure that people would
>upgrade after a certain date (i.e. planned release).  After this date,
>the beta version would just exit(1).
>  
>
thanks, that makes the function clear.

>It's bad because we don't want to walk this route.  It's circumventable
>by just recompiling the thing (this scheme depended on no-one but the
>gatekeepers having the source, and man if that isn't the worst idea for
>X.Org), and keeping it around despite the chance to remove it would just
>show bad intentions, IMHO.
>
>So, in a nutshell:
>  * only useful for the situation where the X.Org server is
>    closed-source
>  * hopefully that never happens
>  * shows bad intentions towards our users by timebombing the code
>  * sucks
>
>  
>
I really don't understand this reasoning. It plays very circular:
"Its bad because we don't want to  walk this route... bad intention.."
I don't grok the highly technical postscript: "sucks". I'm afraid
this response is fully opinionated.

The intention of this timebomb is to protect non-developes from
inadvertant deployment of the Beta version with the associated
risk of  frustrated users and support calls.  One could argue that
effective use of version control can  achieve the same effect in a
less obtrusive manner, or that there's a security risk. I don't know.(tm)


Can someone speak to 1st or 2nd hand experience with the
CheckBeta() working well or poorly?






More information about the xorg mailing list