[Top][All Lists]

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

Re: [Pan-users] Policy discussion: GNKSA

From: Heinrich Mueller
Subject: Re: [Pan-users] Policy discussion: GNKSA
Date: Sun, 03 Jul 2011 17:27:36 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110628 Thunderbird/5.0

On 07/03/11 13:03, Duncan wrote:
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. =:^)

I'll revert that. Sorry about that, I didn't know.

reply via email to

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