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 _______________________________________________ Pan-devel mailing list Pan-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-devel
