> - Platform support. Ostensibly, we support a huge universe. In > actuality, a probably much smaller set currently really works. > Pragmatically, we should probably promise an even smaller one.
ctwm has a long history, and twm fills in more years before that. So it deals with a whole lot of platforms, many of which don't exist now (or a decade ago. Some not even _two_ decades ago). It came to life during and in the aftermath of the Unix Wars, when there was huge divergence between allegedly similar systems. That's not 2014, though. Currently living systems are mostly much more similar and much more compatible. So I propose we strongly narrow the scope of what we target. The various BSD's and Linuxen and Solarisoids are all alive and used, and we should keep working on. They're all similar enough that we should probably only encounter minor build difficulties like we saw on the runup to 3.8.2; easy to keep up with. Being a common item on older or weaker systems, we should do our best to keep going on not just recent releases of them, but multi-year and even ~decade back versions, even if out of upstream support. Still probably not posing any huge problems; most post-2000 systems aren't going to have huge lacks. What about other semi-living POSIXites, like AIX and HP/UX? They still exist to some extent in workstation roles, though they're not exactly growing in those niches. Or even holding marketshare steady. What about OS/X and/or Darwin? That's not dead, but how many people are running X and ctwm on it? And ctwm is a strong candidate for use by people with 20 year old systems kept running for nostalgia or such reasons... In general, I'm going to suggest that if somebody around wants to use such systems, great. Make it known, keep it tested, and be ready to contribute fixes when something breaks. If you're active about it, we'll agree to also put some effort into avoiding breaking extra stuff on you. But lacking that, we won't make any promises about keeping them working, and may even actively break them. Writing this kind of code is hard enough, without also worrying about whether what you write will work on a 20 year old proprietary horrific SysV/BSD blended stepchild. We don't need extra barriers to contribution. The code is full of minor ifdefs and such for odd systems that, given the above, we can stop caring about. Most of them, though, I don't think we need to go to any work to proactively remove, as they're relatively isolated and not hurting much. However, there is the major case of VMS, which deserves special attention. It's a long way from all the *nix-alikes ctwm runs on, and the support for it is in many places very invasive; large sections of #if/#else'd conditional code make some parts of the codebase hard to read (even breaking brace-matching). Lacking somebody really watching it, it's highly likely to break from other chances, and I wouldn't even want to give odds that we didn't break it from 3.8.1 to 3.8.2. So even more than other systems, we definitely need somebody engaged keeping it up, or it's going to rot very quickly. Unlike the above systems, where conditionals are fairly isolated, this case is so intrusive and ententacled into the code that if we don't have somebody who wants to keep it up, I'm inclined to go all grim-reaper on the whole thing and eliminate the mess. Should we care more about it than DEC^WCompaq^WHP does? -- Matthew Fuller (MF4839) | [email protected] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
