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. * html documentation: It's mostly unusable for me and way too complex. There are be other, simpler ways to achive the same benefits (asciidoc?). * perllib: Changes in the module interface that are not reflected in perllib (I really can't remember which). [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. > 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. Depending on xterm is not an artificial dependency. On one hand, every X installation has xterm or some equivalent. On the other hand, a different terminal can be used. > 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. > > * 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, > 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. [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. * 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. * perllib Definitely no voting about it. * 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. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
