Re: [Pan-devel] [patch] Accommodating Giganews users (20-50 connections)

[Duncan]

Conrad J. Sabatier posted on Sat, 03 Sep 2011 02:03:15 -0500 as excerpted:

> I'd like to submit the following simple patch for inclusion in the
> master repo, to accommodate users fortunate enough to have a Giganews
> "Diamond" account, to allow them to use their full 50(!) connections.

http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/12518

That explains the situation in general and includes a workaround that 
does NOT kill pan's 100% GNKSA approval.  You don't indicate whether you 
were aware of that or not.

You can read the debate about it on the thread (and a following one, see 
below), but at least so far, it doesn't appear there's consensus on 
breaking GNKSA as we'd be doing, altho as I explain, I don't personally 
believe the
4-connection limit should have ever been part of GNKSA because by the 
time it /became/ part of it, the problem was in general already solved, 
by necessity, by server-side connection control policies.

Meanwhile, even the GNKSA folks themselves seem to think of it as a 
historic document whose current relevancy is questionable at best.  At 
the very least, it needs a major overall for the connections point and 
perhaps a bit of tweaking to a couple others.  Here's the second thread 
discussing that:

http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/12551

(FWIW, as I follow my lists as newsgroups on gmane, using pan, I can 
simply find the post I'm after in pan, toggle view-headers, and grab the 
web permalink from the Archived-At: header that gmane adds.  It's 
possible to get different views by changing the host name, to 
comments.gmane.org, for instance.)

IMO, especially since the directly-editing-servers.xml workaround exists, 
some community consensus should be reached before this is changed in the 
official version, and if it IS changed, we at minimum need to kill the 
use of the GNKSA seal on pan's homepage at pan.rebelbase.com since we'll 
no longer be compliant and shouldn't represent that we are.  Of course, 
it can also be noted that since I'm not the coder, it's not my opinion 
that ultimately counts, but rather, that of KHaley and PKovar, the 
holders of the keys to community release-precursor git repo and the 
official gnome repo (which pulls from khaley's lostcoder repo on github), 
respectively. =:^)  But I'd guess they have similar feelings on community 
consensus.

Meanwhile, while I don't believe consensus (except to wait a bit for the 
dust to settle) was reached in the last round, a followup thread would 
seem reasonably timely, IMO.  After reading the above threads, I'd love 
to have someone else start the thread this time, laying out the options 
and presenting your argument in favor of one of the following choices, as 
I see them (or another if you see it):

1) Retain the status quo.  Pan keeps its 100% GNKSA seal, AND the ability 
to work around the 4-connection limit by directly editing servers.xml.

(I'm arguing in favor of this, short-term, but am neutral on it longer 
term, as long as some consensus can be reached.)

2) Dump GNKSA entirely, arguing that its time is past.

(I don't believe this one will work with pan's currently active 
community, who after all must have some interest in the general 
principles of GNKSA or they'd likely be using some other client.  
Entirely repudiating GNKSA would also leave pan rather rudderless in a 
number of other policy areas as well, an outcome at least I personally 
would find unfortunate, to say the least.)

3) Effectively keep GNKSA as policy (with or without retaining overt 
public mention), but with a definitive statement that we believe the 4-
connections thing no longer applies if it ever did.

(This is my own second choice, likely more practical than my ideal one, 
#4 below, but my biggest worry is that it would then lead to a slippery 
slope into #2 above, and I believe both I and most of the community in 
general favor, often quite strongly, the other points of GNKSA, and thus 
fear anything that might lead pan away from them toward #2.  Thus, a 
strong policy favoring GNKSA but for this one exception, strongly enough 
that any (other) violation of it would be considered a bug worth a high 
priority rating, is a policy I could easily support.)

4) Work in cooperation with the GNKSA folks on a new revision, likely 
rewording the connections point to emphasize using each connection to its 
full potential but noting that it's server policy that determines the 
number of allowed connections, and possibly making other, likely minor, 
tweaks as well.

(This one is my ideal.  Given the reply from the GNKSA folks discussed 
primarily in the GNKSA thread (#2) above, it's quite possible they'd be 
reasonably cooperative, and *MIGHT* even be willing to turn over the 
domain so someone demonstrating enough interest in an updated project.  
(This keeping in mind that they took over from the original author, 
themselves, thus GNKSA v2.0.) But to do it successfully requires someone 
with more leadership and motivation toward it than I have, personally.  
If you believe you have that leadership and motivation, GREAT!  
Meanwhile, as you can gather from the thread, Joe Zeff has been the self-
volunteered contact point between pan-users and GNKSA.  Presumably you'd 
initially coordinate with him.)

As I suggested above, I'd very much like someone else to take the lead on 
this next round, if you believe you're up to it, especially if you want 
to take a pro-change position, because I'm not as opposed to medium-term 
change (with consensus) as it might appear from my opposition to the 
short-term change without getting some general community consensus 
first.  But I find it hard to argue for the medium term change without 
volunteering to take the lead on the GNKSA revision, and I don't really 
wish to be that lead, so I fear I come across as more conservative 
especially in regard to an ultimate change on connections than I really 
am, and I'd very much appreciate someone ideally volunteering to lead #4, 
but I'd settle for #3 under the right conditions, which pretty much 
include at least at minimum, someone else believing in them strongly 
enough to argue the case.  But if you strongly believe in #2, dumping 
GNKSA entirely, and can make a solid case for it, I'd love to see that as 
well, tho I'd be taking an opposing position of course, in ordered to try 
to develop the best possible policy for pan going forward out of the 
ensuing debate, thus to hopefully avoid its strongest negative, the 
potentially rudderless bit.

Because I simply don't see the viability of #1 longer term, given both 
the GNKSA people's view that its time has passed and the practical issues 
with a 4-connection limit.  All that's really missing, then, is for 
someone to present a suitably strong case for a reasonable alternative, 
after familiarizing themselves enough with the history to at least make 
the case.  If you're that person, great, we've found you.  Just put 
together your case and let's see it.  =:^)

Please make your case, if you choose to of course, on the user list. =:^)

-- 
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