Rui Maciel posted on Sat, 31 Mar 2012 11:27:26 +0100 as excerpted: > Are there any coding guidelines set in place for the Pan project ?
I'm not sure if you had in mind the following, or more literal code format conventions, but FWIW... One thing that can get missed is that pan has been 100% GNKSA compliant for many years. With Charles, "tho shalt not break GNKSA compliance" was a hard and fast rule, but it has lost a bit of emphasis since he stepped down and others took over, and the GNKSA folks themselves are known to not be particularly worried about it in this post-ISP-provided-news era. Still, AFAIK, pan is still 100% compliant, with the 4-connection-per- server GUI limit (but pan honoring more if configured for it by directly editing servers.xml) definitely being the most controversial requirement, when paid servers often allow 50-ish connections. But with the direct- config-file-edit workaround, the pressure isn't as strong there as it might be. The pressure now is more the question of whether we as a pan community are ready to pass that line, and whether if once we did, that would remain the single exception or if pan would gradually lose many of the other GNKSA requirements (like the top-posting warning, too much quoted text warning, etc) that the community at least currently seems to be much more sure of and place much more value in, than the max-4-connections-per- server bit. I was the one that raised the issue last time it came up, but my interest isn't really in keeping a 4-connection limit, or even in forcing GNKSA if we agree to move on, but in getting community consensus for such a decision and making that choice deliberately, not by accident. For that, we'd really need someone to in effect be the champion for such a decision, both arguing for it persuasively, and providing a workable policy to replace 100% GNKSA, that wouldn't let the other bits of it that the community DOES value get trampled as well. So mainly, just be aware of GNKSA, and if you make changes that violate it, be prepared to defend them and realize what you're likely to be getting yourself into. =:^} Another point that can be missed, is that while pan is a gtk-based app, it doesn't require gnome, and there's a number of somewhat influential users (including me) that aren't interested in a pan that would require gnome. Thus, any additional gnome dependencies must be clearly optional. Heinrich has struck a reasonable balance, IMO, with the recently added help and pgp-signing/encryption options, which do require gnome components if they're enabled, but remain build-time options. Yet another point worth mention: pan is GPLv2 licensed and changing that would require some work. Keeping that in mind when evaluating further dependencies is useful. For instance, the new secure connection support now in git was originally implemented against OpenSSL, but that was later switched to gnutls, because openssl's license isn't gpl compatible. Considering that before the initial implementation would probably have saved some work. (Tho for all I know he already knew about it and it was simply easier to do that way, or done for porting experience, or whatever. I'm just glad the support is there, and the problem got worked out so I can still legally share a pan binary with someone if I want. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
