Re: xoobr: whoa there baby! Not so fast!

SJT> That kills the packages lib-src idea dead, right there. SY> Not really. Most (all?) of what is in the current packages SY> lib-src are shell scripts. Stuff that doesn't need to be SY> built. Oh, of course, you're right about that. But they could also be rewritten in Lisp; most of them are in shell because that was quick and dirty and there was no particular reason to rewrite them when they were in core lib-src (which many of them were). SY> Things like EFS which uses FTP don't fall into this SY> [problematic] category. If EFS doesn't fall into this category, what does? From the point of view of core, because of the dependency on EFS for package install transport, it is the single biggest headache in the packages. What with Microsoft and Red Hat (not to mention various commercial Unix vendors) ftp can't even be considered a "standard" system binary. :-/ SY> Which is exactly why I gave a solution that can easily be SY> implemented now. [2] SY> Footnotes: SY> [2] Including the xoobr source tarball in the OO-Browser SY> package. I thought that was a substitute for the inclusion in core. Sorry! SY> [1] Steve, could you please start making very big, very public SY> announcements about our policy regarding the XEmacs versions SY> that we require our packages to support. I'm asking you SY> because I know you'll do an excellent job of it, you are a lot SY> more articulate than I am. :-) Well, that was done with release of 21.4.12. But I'll put something up on the website in a prominent place soon. Probably I'll just let fly with "what I think is the review board's sense of best practice" and label it "Request for Comments". Does that make sense, or should I be more cautious (ie, a formal patch and review process) until we have an agreed policy in place? The reason I'd like to do it that way is that (1) this is different from past policy and AFAIK GNU's policy, which is to reserve flexibility for the core team---it's worth making that public, and (2) although the sense of commitment to backwards compatibility is agreed (I think), details probably aren't. I think details should be resolved in a back-and-forth between the reivew board, developers, and third party maintainers. So the sense of the RFC would be "if you see a package or core feature your package depends on going 'the wrong way', speak up so we can answer and clarify the commitment." -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.