[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pan-devel] [patch] Accommodating Giganews users (20-50 connections)
From: |
Duncan |
Subject: |
Re: [Pan-devel] [patch] Accommodating Giganews users (20-50 connections) |
Date: |
Sat, 3 Sep 2011 10:49:21 +0000 (UTC) |
User-agent: |
Pan/0.135 (Tomorrow I'll Wake Up and Scald Myself with Tea; GIT 7b22759 branch-master) |
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