Re: [Pan-users] Coding guidelines?

[Duncan]

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