I'm sorry, I've been a bit preoccupied the past few days so I haven't been as responsive. You guys are coming up with some great ideas here. There is still a discussion going on within the advisory board as well. Hopefully we'll reach a consensus soon!
> *** Thank you for the detailed explanation. +1 for GNU DevelopMENT > Network. [0] GNU Development Network might be a good solution. I'll propose it. > Especially the part: "How to write languages other than C to GNU > standards/styles" rings true. I'm not the best person to talk about this, since I haven't been involved in the standards at all, but in general we maintain the standards in C because consistency between official GNU packages is important. It makes maintenance of the packages much simpler in the long run. I won't name names, but when we have packages that were written in other languages (Smalltalk, Eiffel, etc.) that subsequently become abandoned, it becomes much more difficult to find a new maintainer for them later on. In other cases, like C++, where the language standards seem to be a moving target, code falls into bitrot extremely quickly. Well-written C from 20 years ago will still build and work today, though. Now, that's just for official GNU packages. We recommend that most packages be written in C for the same consistency, however of course people will write in whatever language they want (I'm a big Python guy myself). Thus, perhaps a good thing for a GNU Development Network would be to develop some community standards and recommendations for other languages that GNU could endorse (I'd have to bring this up with Richard and the advisory board, of course). > The younger generation would certainly appreciate > autotools-for-PUT_YOUR_FAVORITE_LANGUAGE_HERE. Getting into details here, but there is autoconf-archive, which has some Autoconf macros for other languages, and pyconfigure which is a set of macros and templates for Autoconf and Make for Python. I would encourage the further development of packages like this for other languages. > Moreover, some alternate programs appeared. Some better, some better > maintained. Some using different approaches. For example, tmux as an > alternate to screen. Or Zshell, or Git... Some of them might integrate > the GNU project. I think the GDN could also address this part. As long as all the software is free software, there aren't any problems in principle. I would prefer, however, that all alternatives be given equal treatment, rather than seeming like we're pushing for one package over the other. Even more important, though, is that this should motivate us to contribute to and improve the GNU packages where applicable. I'm sure there were some interesting comments that I've failed to reply to. Please let me know if there's anything that needs a response. Cheers, Brandon
pgpfMBTdR33_L.pgp
Description: PGP signature
