[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Pan-users] Policy discussion: GNKSA

From: Duncan
Subject: [Pan-users] Policy discussion: GNKSA
Date: Sun, 3 Jul 2011 11:03:41 +0000 (UTC)
User-agent: Pan/0.135 (Tomorrow I'll Wake Up and Scald Myself with Tea; GIT 9996aa7 branch-master)

Looking at HMueller's git logs, I'm guessing he had no clue on pan's 
history and GNKSA when he did the following commit (log excerpt, there 
was more to the commit but this is the pertinent part for us):

commit 9f3b662bb94474c833a0c1af4d1a265e83279cd1
Author: Heinrich Müller <address@hidden>
Date:   Mon Jun 27 10:19:22 2011 +0200

    [+] changed max connections to 20

diff --git a/pan/gui/ b/pan/gui/
index a118661..6870b7d 100644
--- a/pan/gui/
+++ b/pan/gui/
@@ -252,7 +252,7 @@ pan :: server_edit_dialog_new

     // max connections
-    const int DEFAULT_MAX_PER_SERVER (4);
+    const int DEFAULT_MAX_PER_SERVER (20);
     a = GTK_ADJUSTMENT (gtk_adjustment_new (1.0, 0.0, 

I don't know how khaley/lostcoder and pkovar feel about that, but that 
would have been a DEFINITE no-go in Charles' pan, because it breaks the
4-connections-max spec of GNKSA.  Charles was quite proud of the fact 
that Pan got a 100% GNKSA rating, and he had put in quite some work to 
make (and keep) it so.

*HOWEVER*, there's a practical compromise that Charles implemented.
The GNKSA evaluation is on the GUI, not what people might enter in the 
config files by hand and whether the news client still enforces the GNKSA 
cap when the config file has been manually edited.

So since the C++ rewrite (aka pan2), the compromise was that users who 
had NSPs that allowed more connections could edit the servers.xml file 
directly and change the connection-limit setting themselves, and pan 
would honor it.


FWIW, the GNKSA spec is available here:

The four connections limit is a MUST (not a should), listed under point 
#19, "Be kind to servers, leave room for others".  As a MUST, if pan 
elects to change the GUI, pan fails a MUST and therefore scores an 
automatic fail.  100% compliant to full fail in one commit!


As I said, I'm guessing poor Heinrich had little idea the hornet's nest 
he was so industriously poking at =:^), so it's not really his fault.  
But since he did, I might as well take the opportunity to trigger this 
discussion, as we'd certainly need to have it eventually in any case.

I had actually been wondering when something that violated GNKSA might 
come up, figuring that the connections thing was likely the most 
controversial bit of it at least among pan users, as four connections max 
really does seem a bit anachronistic, when paid providers commonly offer 
up to 50 connections on a single account, and I had wondered what the 
general community reaction would be now that Charles isn't there to 
assert his "thus saith Charles, thou shalt not break GNKSA in any pan of 
mine!" that he always did.

So we should probably come to some sort of community decision on this.

GNKSA is pretty specific, 4 connections max, and it's a MUST, but there's 
an existing workaround for those who want it.  That /does/ seem a bit 
anachronistic, no argument there, but do we REALLY want to reject 
something pan has stood for for so long, with its 100% GNKSA seal of 
approval rating?  Given that there's a workaround...

Ultimately it's pkovar that will decide what gets in the official Gnome 
repo, and khaley that has been the "community upstream" for that, so 
whatever decision is made, they can certainly veto it if they like.  
However, I expect that if a consensus can be reached here, they'll 
probably honor that.

So, what does everybody think?

Personally, I'm fine with the hand-edit-servers.xml workaround, and I do 
place some value in GNKSA.  Not so much in this particular MUST, but 
certainly in some of the others, the warnings for too much quoted text, 
the warnings if it seems to be top-posted, etc.  I believe those have 
enough value to the community that we're unlikely to see them disappear 
immediately in any case.  But the GNKSA DOES provide a clear delimiting 
line, and once over it... will there be any turning back or will it be 
the proverbial slippery slope?

But I'm not so attached to GNKSA per se, and this one does seem 
arbitrarily low and a bit ridiculous besides, when the NSPs seem to have 
no problem implementing the caps they need in any case, and when people 
are paying good money for accounts with more connections and pan's GUI at 
least is getting in the way, at present.

So I'd prefer to keep the 4-connections GUI cap and the 100% GNKSA seal 
of approval, but it's nothing I feel incredibly strongly about, certainly 
not like top posting or HTML or the like.

But I DO feel reasonably strongly that if we decide to dump it, we ask 
PKovar to go ahead and remove that GNKSA seal and claim from the site 
right away.  If we're not compliant and we know it, better to face up to 
it than to wait for someone to test pan and ask that we remove the seal. 
(Whether there's a legal remedy or not shouldn't matter. Either we're 
compliant or we're not, and it's pan's integrity as much as the GNKSA's 
at stake if we're simply misrepresenting the case.)

Someone else's turn, now. =:^)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]