Hello -- 2009/2/27 Dominik Vogt <[email protected]>: > On Tue, Feb 24, 2009 at 09:49:00PM +0000, Thomas Adam wrote: >> Hello, >> >> I realise this might seem controversial, and indeed this question has come up >> from time to time, but this time I will ask it and give proposals; the >> question is: >> >> When will FVWM 2.5.X go stable? > > The simple truth is: Never, if nobody works on stabilizing it.
Heh, well that's true indeed. But it's also knowing which bits need stabalising as well. :) >> If one looks in the docs/ directory in the FVWM CVS repository, >> there's all manner of TODO lists and disjointed ideas without any >> structure -- that's fine, and in fact some of the items therein are >> already present in the current 2.5.X tree, so I suppose I ought to go >> through and consolidate and clean up those items already done. > > You should look at the file doc/todo-2.6. It was an old attempt > to list the open issues before 2.6. There should be something in > the mail archives too. I've spent about the last three hours looking through the Jitterbug (which is a disaster in usability and User Interface Design, by the way) and I have come to the sling-shot conclusion that most of the entries in there are *so* old (mostly in excess of eight/nine years) that if there's problems still existed today in 2.4.2X or 2.5.X, *someone* would have complained about it since. Of course, I suppose the converse holds true that people have, and no one has gone back to close the bug report. >> Is there a concrete roadmap for transitioning the current unstable >> branch of FVWM to stable, and effectively deprecating FVWM 2.4.X? I > > No. Any help is welcome. Right -- in that case, I am proposing I should go through the entire bug database and try and reproduce as many of the bugs therein as I can -- I am though limited by hardware. I do not have access to an HP-UX machine running some antiquated UNIX. At a pinch I have access to SunOS here at home (nothing quite like CDE! Although I think it's more likely running olwm ISTR) which I could potentially use. The only question I'd have about doing that: do you (Dominik) or anyone else have any recollection as to how the Jitterbug database is/was organised? >> appreciate that's a bold step, even with the current state that 2.5.X >> is in, but note that: >> >> - Almost everyone I have advised over the years, I have suggested they use >> 2.5.X, without any ill-effects. >> - 2.5.X has many "modern" features in other WMs, namely: Colorsets, EWMH, >> etc. >> - 2.5.X has the concept of the Test command, deprecating InitFunction (which >> one still has to use when using 2.4.X), not to mention FvwmTheme still. > > At least, we need to discuss D.2 in the todo-2.6. Also, I really > wouldn't like to have a half working FvwmProxy in a stable > release (E.6 and E.7). With regards D.2 (key release bindings), I remember sometime in FVWM 2.3.X we had just that but it was very problematic. In all my years of supporting FVWM, I have only come across half a dozen people requesting this. And I can't say it's something I myself would find particularly useful. When time (heh) permits, I will look into E.6 and E.7 assuming no one beats me to it. >> For many many years, the manpage has several commands on deprecation >> (AddToDecor and friends being an obvious example). There is no way in hell >> that we can ever change this in 2.5.X without introducing significant syntax >> changes for .fvwm2rc. The same goes for any further expansion on things like >> Style commands (InitWindowStyle, separation of style matching to use >> name/class/resource cumulatively, etc.) >> >> We might as well cut our losses and admit these changes just won't get done >> now, but will in the future. > > The vague plan was to do all the cleanup work in 3.0 which may > well never be released at all. Well that's fine, but the more that happens before then, the better. >> Hence, I propose we brainstorm (and I do mean >> this) plans on what needs to be done for the current 2.5.X branch to mark it >> as stable, and, whilst we're doing it, those items we might want to actively >> work on in 2.7.X -- perhaps even with an eye to FVWM 3.0? > > What we really need are people who do the tedious coding work. I > had ambitious plans for 3.0 (lots and lots of work), and either > they are dropped or we find someone to code them (of course (sh) > would have to write everything I tell him/her ;-) ) Ha! Unlikely. :) I don't mind the "tedious coding work" but it's still knowing -what- that is which alludes I think most of us. >> I'm willing to do all the preliminaries, providing though such a step isn't a >> waste of my time -- i.e., I am happy to go through docs/ and consolidate some >> of the ideas in there removing those items that have already been done, as >> well as augmenting some of the documentation with newer ideas (such as the >> conversation Dominik and I had on window styles, per my InitialMapCommand >> patch series). If this is the sort of work that would make this viable, I'm >> up for it. >> >> Only at this rate, I can see us never releasing FVWM 2.5.X -- there >> has to be a point at which we say: "OK, it's a stable candidate", >> even if that means cutting our ideas short as a result. > > We really weren't this far away from 2.6 on our last attempt. > Well, I didn't look into most of the bug reports for years now. Can we then officially retire the Jitterbug? It's awful, no longer maintained upstream, and frankly we had a much better success rate tracking bugs on this mailing list. > It's hard to tell sor me how stable 2.5.27 really is. You time > would definitely not be waset if you to update the todo-2.6 file > as a first step. Already underway... -- Thomas Adam
