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. > 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. > 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. > 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). > 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. > 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 ;-) ) > 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. 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. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
