22.0 default configuration [was: 22.0 Release Status: Important news]

Andy> At 20:24 14/01/01 +0900, Martin Buchholz wrote: Andy> I'd really like us to revisit this since we have never Andy> actually made a decision. I believe that I have nuked pretty Andy> much all the widget bugs in the X version as well as the Andy> windows version - so I would like to know what in particular Andy> means that we have to switch it off by default? I'm sorry, maybe this is my bad. Perhaps I should have clarified the policy earlier, but I've been hoping for discussion from the Board. Martin has expressed his opinion several times. The only support for it is his unquestioned general expertise, to which I have given due consideration. Against that, he has pointed to no specific bugs or incompletenesses. In favor of continuing present policy (detailed below), I count o the unanimous silence of the rest of the Board as tacit assent o the expert opinions of the implementors of each feature as clear indicators in favor, and o the fact that the very risky features are on CVS branches and not planned for immediate merge to the release line as reason for delaying decision on those until we've got something to look at. As of right now 0. The proposal, which was not disapproved by the Review Board and I am therefore implementing, was to take big risks for the potential big wins of "GTK" and "Mule on NT," moderate risks for the very nice features "pdump" and "widgets," and minor risks for the remaining recently finished or nearly done stuff. This remains Release Manager policy. It is subject to Board override or me changing my mind. I've seen no hard evidence to make me change my mind, and no sign whatsoever of a Board minority against it, let alone enough of a majority to be called an "override." Specifically: 1. The widgets are _in_ the release and _on_ by default on all platforms until I see either (a) bug reports that indicates that they shouldn't be (Martin's whinging is not a bug report) or (b) a Board override. Tester releases will reflect this. 2. A similar policy applies to the portable dumper. Martin, please make configure{.in,} reflect the above policy. (If you haven't time, I'll do the best I can, but I don't have a lot of experience hacking configure.) As for the big risky features: 3. Mule on NT is _in_ the release, but the merge work will be done on a branch. If the merge is going to be as late as Ben currently believes, it will _not_ be merged into the release branch. Then it becomes Martin's problem, or my successor's if we are so lucky as to find one. The next decision point is when Ben asks for a merge or Feb 1, whichever comes first. 4. A similar policy and decision date applies to GTK. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."