"Ben Wing" <ben(a)666.com&gt; writes: Yes: Bug Fixes. Many people have given up using 21.5 while you where away. We'll have to get the current list of bugs on the table (while Stephen is secretly working on his XEmacs Bug Tracking System). -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

Ben> But what's missing? Besides the stuff you mention [1] [2] [3], I would say [4] move a bunch of cruft like Canna and Wnn support into modules. (I've done Canna, not posted yet though.) [5] translate .els and .elcs to UTF-8. This fixes reader breakage on strings for no-mule I think, we'd probably need to do something to make characters no-mule safe. [6] if Mule is going to be default, we _must_ have robust safe-charset support. [7] CText extended segment support for ISO 8859-15. [8] Custom support for Mule fonts. Stuff that should get scheduled but probably not for 22.0: [9] Xft support. [10] fontlock overhaul. -- 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.

* Stephen J Turnbull <stephen(a)xemacs.org&gt; writes: If it is just EFS and xemacs-base -- good. Bad, crazy, stupid, waste of time. -- |---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---| | XEmacs - The only _______ you'll ever need. | | Fill in the blank, yes, it's THAT good! | |----------------------------------&lt;steve(a)youngs.au.com&gt;---|

* Adrian Aichner <adrian(a)xemacs.org&gt; writes: Not needed to bootstrap PUI. I spent some considerable time doing just this. It is how I know that it shouldn't be done. Yes. Tramp doesn't buy us anything where PUI is concerned. We'd just only be adding dependencies to PUI. We'd be in a worse situation than we are now. Well keep on wishing, because for all of the mirrors that don't have a web server listening or don't have a web server listening in the right place you will still need EFS (or any other FTP solution). This is the case for the vast majority of our package mirrors. -- |---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---| | XEmacs - The only _______ you'll ever need. | | Fill in the blank, yes, it's THAT good! | |----------------------------------&lt;steve(a)youngs.au.com&gt;---|

Stephen J. Turnbull wrote: There is also the point that many companies don't allow direct ftp connections to the outside. They demand usage of an HTTP proxy. I have been sitting behind firewalls of customers and needed to download packages by hand, instead of being able to use PUI. (Not that I could use it in my current installation where it is broken in several ways -- without me doing any configuration changes, but that is an issue for a separate bug posting... ;-) Cheers, Joachim

Malcolm> I'll second this problem. My POE sits behind a proxy Malcolm> that requires authentication so I have t manually Malcolm> download packages as well. Could wget be used as an Malcolm> alternative transport? Well, here's what I had in mind. Break the package-get stuff into two parts, the package-and-archive-finding code, and the transports. Add some data to the package-get-base database so that a dispatch function could be written. Eg, specify archive locations as URLs and dispatch on the schema. Write transports to get the remote file and put it in a known place, then use standard local facilities (eg cp or mv, or tar --file=...) to do the unpacking. KNOWN-PLACE, of course, is a customize-able variable. Have a user configurable variable that associates transport schema (eg, ftp, http, scp, 6250bpi tape) to transports (wget, wget, TRAMP, Federal Express). The dispatch function looks up the desired transport and calls it. The transport API would be something like (transport REMOTE-FILE LOCAL-FILE &rest OPTIONAL-TRANSPORT-PARAMETERS). I think we be golden at this point, just need somebody to implement. -- 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.

On 2004-12-10 00:55, Ben Wing wrote: I second that.

Ben> Anything else? ms> - Xft Not for 22.0 unless ten times more progress than was made in the last two years is achieved in the next 3 months. -- 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.

ms> - Xft Stephen> Not for 22.0 unless ten times more progress than was made Stephen> in the last two years is achieved in the next 3 months. ms> You mean less than 10% is done? I don't think so. "Ten times" is a figure of speech, I don't know how to measure that. Try "not ready for prime time and no way is it going to be AFAICT." Show me; I'd love to have this stuff in. I'm really pleased with the way my branch is working for me, but I am not going to ask the Dev Team to support it, no way! It's just a sweet hack at the moment. IMO Eric's most recent patch is even less ready than my branch. I have no objection to saying the first thing we do after releasing 22.0 is integrate one of the Xft branches, and fast-track it to a release in 22.2. Or I'd be happy to roll 22.0+Xft releases from a branch the way Andy did the Windows code and Bill P did the GTK port. But at this point we have proof of concept, and no more. -- 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.

Eric> On Sat 11 Dec 2004 06:58, "Stephen J. Turnbull" Eric> <stephen(a)xemacs.org&gt; writes: Eric> I find this statement rather annoying. Why? It's simply the truth that that is my opinion. Given that I have the power to seriously hinder any attempt to get your code committed to mainline, I rather think I have the responsibility to say that publically. Among other things, that gives you the option of lobbying the Board for a more lenient standard starting _now_, if you want to. I'll oppose it, of course, but I won't hold it against you. Eric> My plan was to pull together instead of starting some sort Eric> of competition. That's not competition; I have no intention of merging my sandbox to the mainline without substantial improvements. (Among other things, CVS's deficiencies make any attempt to merge both ways an exercise in frustration; a branch is really only useful as a public history of a workspace up to a once and for all merger back to mainline.) I don't care "whose patch" gets in, and frankly I'd rather have you guys do most of the work, and a lot sooner than I'm likely to do it. IMHO the reality of infrastructure today is that if it's not available under revision control for anonymous checkout, it's not in play. Your workspace is closed; nobody knows how much you care or what changes you're making to the code, until you get around to publishing a patch. So there's nothing special about "my" branch vs your workspace, except that it (a) announces that I care about eventually getting this stuff into XEmacs and (b) makes plain what I'm doing (or that I'm doing nothing, which is equally important) at a given point in time. I think you should do the same rather than worry that you're not getting a fair hearing. You'll notice that I'm the only non- contributor (in the sense that although I've done work, I'm not planning to try to push it into an XEmacs release soon) besides Mike running any version of the Xft patch, and it's getting on three years old now. But I already have one beta tester that I know of; I doubt it will be very long before there are others. The CVS branch did that, not my code (which is mostly yours and your predecessors', anyway). Eric> My plan was to submit a patch against your Xft-branch pretty Eric> soon. Good. If it builds on at least two different machines, feel free to commit the patch to the sjt-xft branch while you're at it. It doesn't need my approval, just the patch to xemacs-patches, and a tag if there's a chance someone might want to run without your patch for any reason. This patch sounds more than big enough to need a "pre-commit" tag. Use something like "cvs tag sjt-xft-NNN" for the tag. No need for a post-commit tag, at least for now. "cvs update -j tag-thats-broke -j tag-that-works" means never having to say you're sorry. As long as the tag-that-works is fresh enough. :-) Eric> I hope that my contribution to your branch is welcome (given Eric> that it is technically ok). Sure. But it's not a matter of technical quality, really. It's a matter of design taste. If it looks like your patches would make it difficult to do things the way I think they should be done, I'll ask you to make your own branch. But until it actually comes to that, we may as well avoid redundant synching across branches and to mainline. Asking you to make a separate branch doesn't mean my branch is on the fast track, either, except to the extent that other developers trust my judgment more than yours. But I don't have a problem with you doing the work your own way, I'm just going to oppose committing it to the mainline until certain fundamental issues are settled. I do have a word of advice. Get one of the advanced revision control systems (to my mind that means arch or darcs) and do any merges in a local repository for the advanced system. Even if things work out that we can share the sjt-xft branch all the way to integration, it makes a lot of operations easier, and can be essential if whoever is handling "synch-to-mainline" flakes out for a month. -- 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.

Eric> Ok, I probably misunderstood. I just received the Eric> impression, that my patches to the Xft branch would not be Eric> welcome for some reason. Patches are welcome to the branch. I've been asking for an Xft branch for more than a year; I just decided that OK, I'll just do it. Eric> So, what do I have to do to get commit access to the branch? Send an SSH public key and a preferred nickname to cvs-manager(a)xemacs.org and one of us will add it (with approval of the Review Board, but that should be no problem). As nicknames either your first or last name is currently open, but you may pick another. Also, we will make an ＠xemacs.org address for you if you don't already have one. The canonical one will be eric.knauel(a)xemacs.org, but you can have a couple of nicknames as well. If you prefer to receive mail via the alias at an address other than the one in your "From" header, please indicate that as well. The purpose of the mail address is so that XEmacs people can contact you without having to look up your current address. You don't need to use it at all otherwise, and unless you do, it shouldn't "leak" out (and attract spam). We do appreciate the advertising if you use it. It's probably convenient to have the CVS nickname as one of your mail nicknames. Eric> Sure, if it makes things easier! However, I'm not sure if I Eric> understood that completely: which merges are you referring Eric> to? mainline =+========+======+======+=> \ | | A V V V / xft +----->+----->+----+ This kind of pattern is managable with CVS _if_ all the '+' nodes on the mainline are tagged. Typically, however, several problems arise. (1) ChangeLogs frequently cause conflicts because with all changes occurring at the top of the file, the likelihood of simultaneous changes on branch and mainline is very high. (2) Often you will either independently patch a particular bug also fixed in the mainline, or just "cherrypick" a single patch for it off the mainline. On the next update, you get a conflict there. (3) If you fix something on xft, and send the patch on to the mainline, you will get a conflict there on future updates. (4) If I'm doing the synch to mainline, but disappear for a month, you may decide to synch it yourself in your workspace. If it turns out we were working on synching simultaneously, one of us is going to have to abandon that workspace. If there are other important changes there, it's messy and tedious to winkle them out as a separate patch. So you are dependent for synchs on my schedule. All of these occur because CVS doesn't have any notion of "distance" between two revisions, and doesn't understand the idea that a _sequence_ of patches may be applied. The longer a branch lives, the more frequent the spurious conflicts become. The "advanced" systems do understand the idea of sequence of patches, and even the idea of subsequences. darcs will even pick apart a patch into hunks and rearrange them to minimize conflicts. darcs also has a "global rename" operator. arch gives the developer more control over how patch applications (merges) are done. Both automatically detect and avoid "spurious" conflicts due to previously applied patches. I don't yet have an opinion about which approach is better than the other, but both are far better than CVS for working on a long-lived branch. Working with _multiple_ related branches in CVS is impractical, but both arch and darcs handle this almost as easily as the simple branch shown above. For example, suppose you like my "face" work and I like your "menu" work, but you insist on UTF-8 for actual redisplay of Mule characters, while I want UTF-16. Both arch and darcs make the following pattern almost as easy as the simple branch. mainline =+===============+==+====+======+=> \ 2: :3 ^ ^ \ V : /5 / menu \ +--+--+--＠--+ /6 \ / ^ : :4 / +->+ :1 :3 : / \ : V V / face +--+-----+--+--+ Patch 1: you grab an early version of my face code. Merge 2: you update to mainline. Merge 3: we both synchronize to mainline. Patch 4: I grab the final version of your menu code. Merge 5: you integrate your branch to mainline. Merge 6: I integrate my branch to mainline. With an advanced system, all conflicts that arise are "real". Ie, you and I independently changed the same code. For example when I merge "face" to mainline, you've already merged your UTF-8 display code, and we will have to decide UTF-8 vs. UTF-16 once and for all. The advantages are (1) that we can postpone the decision until we have experience with both schemes, and (2) the advanced systems provide "undo" operations so we can back out a subset of your changes and merge in mine fairly easily if that seems appropriate. CVS can't handle this pattern at all, without extremely rigorous tagging discipline (basically, you'd have to tag _every_ commit, and keep separate records of the patch content for each tag). subversion apparently has problems with it, too. The problem is that since they don't understand (sub)sequences of patches, on merge 5, you'll get conflicts from merges 2 and 3 which are already in mainline, on patch 4, I will get conflicts from patch 1 (which originated in my branch) and merge 3 (which you and I independently got from mainline), and merge 6 is just hopelessly complex, especially if we decide I was "right" about UTF-16 and need to back out your merged code, but just the UTF-8 redisplay part. Basically, that change will have to be made entirely by hand. For CVS, Ben has documented both the kind of branch-and-merge pattern that can be used with CVS and a "homemade" global rename operator in the XEmacs Internals manual. Speaking of manuals, apparently there's some problem with the package itself, so you can't just grab it with M-x list-packages yet, but my Texinfo version of the fontconfig manpage (with pretty substantial additions) is now in XEmacs CVS in the "general-docs" module. You can just build it with makeinfo and drop it in your INFOPATH somewhere if the package isn't available yet. -- 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.