2016-05-19 17:18 GMT+02:00 Thomas Adam <tho...@fvwm.org>: > As I understand it, FVWM was written with extensibility in mind, and hence > could be extended through the use of modules. Although the core of FVWM is > quite a bit larger now (read: some of the things ther could be modules, but > hey-ho, one for another time), there are at least quite a few modules which > change FVWM's behaviour. > > Long ago when developers were more active, getting the code into FVWM was > easier, and perhaps more importantly, the maintainability was easier, since > the author(s) of the code had a vested interest in keeping it alive. > > But those days have ended, as far as I am concerned. People have lives, and > have moved on, or simply don't use FVWM anymore. That's OK, and that's what > happens with software over time. But the hole it leaves is almost always > *somebody else's* mess. In this case, right now, that mess is mine.
I definitely see you point - and agree that what FVWM should do is to provide a stable module interface that could support modules. The modules themselves would not have to be maintained by FVWM developers and should neither have to follow the release cycle of FVWM. If someone has an urge to see one of the modules you are removing to survived it is no problem for that person to set up a separate repository and maintaining that module outside of the core FVWM. I'm one of many only FVWM developers who lurk in the shadows. I follow the mailing lists, but have not been using FVWM myself for some time since I'm stuck with Windows development at work, and mostly use my home PC for surfing or gaming, so I've drifted away from X development. If I'm ever getting back I'm sure I'll need to spend some time at updating my config files since I'm quite sure Ive been using FvwmTabs.
