On Sat, Jun 12, 2010 at 11:16:02PM +0100, Michael Treibton wrote: > hi everyone,
Hello. > i've been reading with interest on this list for months that work is > being done to make fvwm-cvs stable. Since about 2003? Sure... :) > i see that there is a new fvwm-convert-2.6 script which has worked > with all my old config files - flawlessly - i dont get any errors from > fvwm using the converted configs and i dont lose any functionality > > could someone tell me what is left? i saw the todo-2.6 file but its a > bit over my head. can someone enlighten me what the timescales are? > whats outstanding that is holding up a release? Well, now that there's something approximating a converter script for taking 2.4.X configs and moving them over to what will be 2.6.X, the immediate job I am working on is an XDG menu replacement for fvwm-menu-desktop, since this is currently broken due to the fact that everything fvwm-menu-desktop assumes is considered legacy. After that, I need to go back and look at any queued patches which I have lying around -- either from myself or others and discuss whether or not they should be included in FVWM before a release. Really, the biggest thing here is to note any bugfixes which haven't been *reported*. I've fixed quite a few bugs in FVWM which have been reported by people only because I happen to scour most of the main Linux distro-specific forums for FVWM-specific problems [0]. I know we're never going to fix all bugs, and 2.5.X has been stable now for many years -- thanks to a lot of hard work from a lot of different people over the years. Even if we didn't get another bug report before the other work needed to be done for 2.6.0, I'd say it were release-worthy. You can gleam some of what's happening from this file: http://github.com/ThomasAdam/fvwm/blob/master/docs/todo-2.6 >From this list, I am actively doing: F2 F3 F4 needs discussion -- c.f. MAX_FUNCTION_DEPTH or similar in this scenario. Oh and the example under F4 is wrong, it should be: "xterm -T foo" Otherwise the thing won't recurse. I might fix this. One of the things I did start to do (before I went off on a tirade against fixing bugs) was to augment/improve the purify tests: http://github.com/ThomasAdam/fvwm/tree/master/tests/purify/ This really *is* something we should be doing before 2.5.X goes stable -- not only to ensure it's rock-solid, but to ensure that we haven't made any silly regressions. Not to mention, if FVWM 3.0 ever gets off the ground, 2.6.X is still maintainable, I don't want to have to really go back and maintain something which doesn't pass what I consider worthy tests [1]. So as for timescales: Personally, I am still working on my xdg-menu replacement, but it's slow since it's bloody boring, and the script I am basing it off pretty much sucks. So I am going through the XDG specification myself since that's easiest. The big problem though, is like FvwmTabs, this script *unavoidably* relies on external perl modules not under FVWM's control. In this case: XML::Simple which in turn has to depend on XML::Parser -- something I am not keen on for two reasons: 1. Downstream maintainers have to consider the impact of their dependencies. 2. Perhaps more importantly, we have a number of users who compile FVWM up themselves, or we have environments where FVWM is deployed in rather interesting circumstances (perhaps you've alluded to one below, in your deployment scenario?) -- out-of-the-box, FVWM won't "work", due to these external dependencies not being part of most base-perl installs. It was OK for FvwmTabs, that has a handy TK dialogue to tell you as such -- but for a script a number of people are using, and *will* be using, it's slightly frustrating. But neither am I about to embed my own XML parser into this shoddy replacement I am writing, and no, importing (ahem, *forking*) these perl modules into FVWM so we ship them regardless is *not* an option either -- in case you were thinking about it! So taking the extra dependencies is just tough really -- it's the lesser of two evils. So that's where we are. I am almost done with the XDG-menu work, I now need to make it an almost like-for-like copy to fvwm-menu-desktop, and deprecate some options that don't make sense from fvwm-menu-desktop anymore as well as write a manpage for it. Then it needs to go through a crap-load of testing on a number of different environments (I am hoping Dan Espen can help with this -- he likes these XDG menus a lot more than I do. :)). I don't know how long that will take -- my enthusiasm for the whole thing is driven only to getting 2.5.X stable, and not because I am enjoying writing this XDG stuff. :) :) If you or *anyone* else wanted to actually help, by all means look at writing more purify tests -- that alone would likely throw up some interesting bugs if they were structured properly -- I have several ideas on how to improve these tests, so if anyone is seriously interested, do please ask me! > i have an interest in this because i use fvwm as a deployment across a > network i maintain and having to recompile each release is annoying. > that's why i thought i would ask, as i dont think anyone is using > 2-4-20 anymore? Yes, people are using 2.4.20 as it's still supported. I hope that answers your question? Please note though -- and this is really important -- whilst I've generally used the first-person singular in this email ("I") -- there is more than one person here, I can only talk about the work I am doing though. :) -- Thomas Adam [0] It's frustrating that downstream don't seem half as bothered about informing upstream projects of such bugs, preferring to either bodge-patch something into their must-have-latest-bleeding-edge-version-ouch-I've-cut-myself release until such time that upstream magically get wind of this. Gentoo and Arch, you say? Yep. :P [1] I ran the tests fairly recently on FVWM-CVS and fixed a few segfaults, so it just goes to show the tests *are* critical to making a good stable release. -- "It was the cruelest game I've ever played and it's played inside my head." -- "Hush The Warmth", Gorky's Zygotic Mynci.
