This is a long post, since I tried to reply to all comments. This is pretty important to me.
On 14 Mar 2009 11:22:22 +0100, Dominik Vogt wrote: > > On Sat, Mar 14, 2009 at 07:32:19AM +0000, Mikhael Goikhman wrote: > > On 14 Mar 2009 00:15:03 +0100, Dominik Vogt wrote: > > [snip] > > > > * deb generation: unmaintained > > > * rpm generation: unmaintained > > > * html documentation: unmaintained > > > * perllib: unmaintained > > > > Someone else should answer about "html documentation", but the other > > things here work as intended without unexpected problems. I don't commit > > things without serious testing and thoughts forward. And they are not > > supposed to be broken if we just stick to our plan to release 2.6, i.e. > > not to make incompatible changes. > > > > What was your reason to say they are unmaintained and how do you define > > this? > > As far as I remeber: > > * deb and rpm: We got bug reports that nobody took care of. I remember patches that were sent and applied in one or another way. Do you know about any real problem with the current code that needs fixing? People here are busy, I am not an exception, but this does not mean they do not care anymore and it is unmaintained. > * html documentation: It's mostly unusable for me and way too > complex. There are be other, simpler ways to achive the same > benefits (asciidoc?). Although I fully share your sentiments here, I would like to hear the other side first, to decide whether it is actually unmaintained. Also I suggest when something critical like this is started next time, to warn the developers in advance that you will delete this new stuff the moment you feel it is not developed any more. I think this would be fair to know in advance. > * perllib: Changes in the module interface that are not > reflected in perllib (I really can't remember which). Sorry, but I prefer to think this is not true without a real evidence. Of course some cooperation from you would be nice, but not really necessary, perllib was transparently adapted to your changes and will hopefully be in the future. It is enough that you write cvs messages correctly and start a new thread each time you intend to break the module interface (potentially affecting all our 36 modules), then your changes are eventually noticed by me, Scott or someone else who cares. > [snip] > > > These are one of the relatively best maintained and documented > > parts in fvwm (given our total sorry state and compared to many > > actually forgotten parts). I just released the rpm package, so this > > part obviously works. > > [snip] > > > > * FvwmGtk: mostly useless because it has nothing to offer that > > > fvwm can not do in a different way; artificial dependency on > > > gtk > > > > FvwmGtk is actually useful as a nicely-looking replacement for > > FvwmForm or FvwmScript. > > And all of these are narly useless. Fvwm has the interfaces to > allow third party gui toolkits to control fvwm without need for > builtin modules. Clearly we have different meaning of "useful". I guess, had you try to write a whole new layer over fvwm. you would not want to declare dialog modules communicating with fvwm (FvwmScript, FvwmForm and FvwmGtk) useless. :) > > For me, this looks like wanting to remove FvwmConsole, just because it > > is useless without xterm and someone dislikes dependence on xterm, and > > since we already have FvwmTalk (or even FvwmGtkDebug) doing this task. > > Actually we removed FvwmTalk for this same reason years ago. It's > just an FvwmForm now. FvwmTalk is still available as a wrapper and my point about removing FvwmConsole is still valid. > Depending on xterm is not an artificial dependency. On one hand, every > X installation has xterm or some equivalent. Unfortunately this is not true for the modern systems for at least 5 years now. xterm is distributed separately from the X system, and usually is not installed for the default (GNOME or KDE) installation. > On the other hand, a different terminal can be used. So this is still another dependancy, just like gtk. Will we remove FvwmConsole because of this? We have FvwmTalk that does the same without a need in additional dependancy. [I know that you and myself use FvwmConsole, I think it is a fair suggestion, since you suggest to remove modules that others use using exactly the same reasoning.] > > Am I the only one who thinks it is good to have FvwmGtk (ported to > > GTK2), so removing it now would add redundant work and no value? > > The first time that anybody bothered to maintain FvwmGtk was this > very moment when we started thinking about removing it. Do you prefer modules that noone wants to update at all? Like old modules FvwmSave, FvwmSaveDesk, FvwmScroll, FvwmWharf, FvwmCpp, FvwmM4, FvwmDragWell and more. Still, I don't see any urgent need to remove any module before 2.6. > > > * FvwmGtkDebug: useful, but the dependency on gtk really annoys > > > me. It should never have been part of the distribution with > > > that dependency: it's simply not cost efficient. Could have > > > been written without gtk and without a gui. > > > > FvwmDebug is the simple version without a gui, however it is not > > interactive for the obvious reasons. > > I don't understand why you think "non-gui = non-interactive". > Assuming that FvwmGtkDebug is really for developers, To be interactive the module should both listen to fvwm and to the input (mouse, keyboard) in the same event loop. Don't you agree? perllib supports this for at least Gtk and Tk toolkits. It also supports a pseudo-toolkit mode using pure xterm, xmessage and similar "standard" X things. Also the idea was to be able to write a module that uses Gtk if presents and fallbacks to the pseudo-toolkit mode otherwise. But I didn't find the real application for this. Usually you need real full-featured widgets for a real-life interactive module. FvwmGtkDebug is really not simple to reimplement without gtk. > > And once again, fvwm does not depend on gtk, or xterm for that reason. > > Fvwm packages in Linux distributions *do* depend on gtk, and > that's the whole point. It also depends on xterm that is arguably less frequent on modern systems nowadays than gtk. > [snip] > > > > > going to be removed without even slight doubts makes me too nervous > > > > for no reason. I think there is a place for many options for everyone. > > > > Let's try to increase the options, not to decrease them. > > > > > > I think we should do quite the opposite. > > > > Possibly. But please in the next unstable branch, and preferably after > > discussion and voting. > > Then let's take a look at the individual items. > > * rpm and deb > > There may have been some discussion about the technical details, > but definitely no discussion about whether they should be part > of fvwm, and definitely no voting. I am not sure I understand your intend here. Do you want to vote on something that is maintained and useful and works correctly? I think we will not end this way, we may as well decide on voting on every commit. I suggested a different thing: voting after 2.6 about all unmaintained things to see whether they should be removed or not. > * html documentation > > Became a part of fvwm because people spent a lot of work on it. > It is *the* top 1 reason why I don't write features anymore: > I'm simply unable to write the documentation anymore. I really trust you to solve this issue in the best possible way. It is much less important for me than the other issues in this message. > * perllib > > Definitely no voting about it. Please reword this. I am not sure I understand your meaning. > * FvwmGtk > > Dumped in fvwm without a discussion about the taken approach and > was never commented by any developers. A typical case of > accepting third party work in fvwm without a maintainer. Matthias Clasen was an active developer on this list when I came. I would not call it a third party work. But why do you disagree with the idea to discuss and implement all grandiose ideas and cleanup after 2.6? A module is here for more than 10 years and I don't remember that a goal for 2.6 was removing modules. Regards, Mikhael.
