Re: [Pan-users] Quirks with ignored authors or posts

[Duncan]

Benjamin Esham posted on Tue, 19 Jul 2011 01:56:16 +0000 as excerpted:

> Hi Duncan, and thanks for your extensive explanation! I've been reading
> this list off and on for years, and I've seen you write some long
> messages, but I think this one takes the cake ;-D

Eh, this one was small, "only" some 381 lines, as reported by pan.

You got me curious what the (my?) record might be and I figured I'd 
probably had at least a couple 4-500 line posts here, so I checked.  =:^)

The longest no-attachment, no HTML/text double-message, no huge log 
included inline, post, since the first of August, 2002, when gmane 
started archiving this list, was -- no surprise -- mine.

That post is according to pan, one line short of 600 (599), including 
quotes.

What /might/ be surprising is the date, considering I've been posting 
here since 2002.  It was actually only a couple weeks ago, July 5, as a 
reply on SciFi's thread discussing his OSX issues and that he's 
considering switching to something else.  Here's the thread title for the 
record and if you're at all curious (not that you'd be at all interested, 
but one never knows...):

To explain why I'm unwilling to up date my glib/gtk+/etc libs ATM…

> Duncan wrote:
> 
>> There has been one release since then, 0.135, on June 5.  This one had
>> a few more minor features, but they're still feeling their way, so
>> nothing major yet.
> 
> It's great that development has restarted! On a slightly OT note... I
> recently pulled and built from K. Haley's pan2 repo on Github, but the
> binary's "About" screen still says that it's version 0.134. Was there
> just an oversight in setting the version number, or is there a more
> up-to-date repository I should be using instead?

I think that's simple oversight.  I use live-git too, so don't know 
what's actually in the release, but based on a comment someone posted, I 
think the official release tarball got the wrong version string too.

It might actually make sense to start bumping the version string as first 
commit after release, instead of doing it last thing before.  Especially 
since pan has a rather more convoluted development and release process 
than many projects, with the release being more or less a straight PKovar 
pull into gnome's git from khaley/lostcoder's github repo, then tarball 
and release without serious changes, since PKovar isn't himself a dev, 
but is none-the-less a critical part of the team, since releases simply 
wouldn't be happening at all, without him.

Meanwhile... the answer to your repository question isn't particularly 
simple, either. =;^D

It's probably worth keeping in mind how incredibly flexible git is, both 
in distributed repository management (with git-hub encouraging that as 
well), and within a repo at the branch level.

To my knowledge, there are at least four pan git repos on github,jlynch/
aexoden's, which I just found out about browsing github for this post but 
which seems to be active (very, 14 branches, see my branch discussion 
below), pkovar's, which I believe track's khaley's and should be the 
stablest as it heads for gnome/official, which it's likely very close to, 
(and btw, I noticed pkovar has pan's web site managed in a repo in his 
github account as well =:^), khaley/lostcoder's, which is the closest 
thing to official development upstream, and now hmueller/imhotep82's, 
which contains the latest experimental binary-posting code, etc.

Then within each repo is potentially N branches, tho as a practical 
matter the number of branches seem to have been kept to a relatively 
small number, so far -- likely far smaller than I would have had were it 
me -- one per feature/bugfix is the upstream git/linus/kernel 
recommendation.  Take a look at the kernel tip repo for what my repo 
would likely look like -- a dozen branches or more, some possibly with 
only a single commit changing one character in a single line, but each 
for an individual feature, with new new feature or potential bug-trace 
branches possibly sprouting and/or dying multiple times per day, so they 
can tell someone to pull and build X branch (instead of breaking out an 
individual patch) and tell them if it helped with a particular bug, for 
instance, plus a number of "merge-branches" where features thought worth 
keeping around and in common are merged for a period, until pulled 
upstream or eventually dropped, plus the for-linus current and next 
version cycle branches...  But be that as it may...

There are three repos and several branches that could be of actual 
interest.

In the lostcoder/khaley repo, you're probably following the "master" 
branch since it's the default.  I believe the "next" branch is what goes 
to pkovar, so it'd be the stablest.  Until a couple weeks ago, I was 
running "testing" here.  That's obviously going to be less stable, and it 
rebases frequently, so you see the same set of commits again and again.  
However, AFAIK it's going to be the most interesting (and sometimes 
broken).  There's also the "nntp" branch, but I've not a clue what that's 
about.

FWIW, the github branch list currently shows lostcoder/pan2/master as 
last updated May 30, testing as last updated June 27 and 108 commits 
ahead (of master), nntp as last updated May 31 and 7 commits ahead, and 
next as last updated May 29, one commit behind, one ahead.

So if it's upto date you're looking for and you want to stick with khaley/
lostcoder, try the testing branch.

The jlynch/aexoden repo looks interesting, especially with all those 
branches, which as I explained, is the way git-based development is 
/supposed/ to work, but it's brand new to me so I really haven't a clue 
on all those branches.

Then there's hmueller/imhotep82.  He's the one that's doing the pan 
binary posting work that has been the latest interest here.  He's working 
quite hard on it and a number of related features so his repo is 
currently fresher than khaley's.

He has three branches, master, experimental, and merge-with-lostcoder-
testing, the last of which he did at my request since I was on lostcoder/
testing previously.  Currently, master's last update was July 9.  
Experimental is one commit ahead on July 12.  And the lostcoder/testing 
merge is from July 8, 21 commits ahead and six behind master.

Obviously, if like me you'd be following lostcoder/master if you weren't 
trying imhotep82's binary posting code, you'll probably want the 
lostcoder/testing merge branch.  If you're more interested in following 
the latest for this specific feature, try master or experimental.

One caution.  He's testing xz compression support as well as posting.  xz 
compression support is definitely well beyond the nntp protocol and is 
only supported by specific servers.  I know little about it in relation 
to nntp other than that.  But that has been problematic for some testers 
based on posts here, with the discussion headed toward putting that in a 
separate branch, for now.  But it doesn't appear to have happened yet.  
See in particular the recent discussion between him and (IIRC) scifi, 
much of which we well over my head.

So, umm... take your pick of repo and branch depending on what you're 
interested in.  If you do mostly text groups and/or gmane, the binary 
posting stuff may well not interest you at all, in which case stick with 
khaley's or explore jlynch's, if you're upto it.  But if you want to play 
with the latest binary posting toys, hmueller's is the way to go.

And if you stick with khaley but want a bit fresher than master, try his 
testing branch.

>> PAN HISTORY IS BEING MADE!
>> 
>> And here news is supposed to be dying!
> 
> I just wish there were as many people on Usenet as there were even five
> years ago! :-) Although these days, I'm more inclined to read Gmane
> lists (as news) than actual newsgroups.

Indeed.  But in some ways, this is surely the mirror of "Eternal 
September", and as such, the /real/ traditionalists will surely be happy 
to have their relatively quiet and safe USENET back. =:^|

Meanwhile, I'd love to get back to non-gmane newsgroups, but 
realistically, it's probably much like my interest in scifi (books) and tv 
(in general), something I may now never really get back to.  While I 
can't really say it about TV, scifi and USENET at least I can honestly 
wish a very long and healthy future, but there's simply not the time I'd 
like to do everything I'd like, and those have simply but sadly fallen 
off the end of my priority list, for the most part.  Oh, well...  Life 
goes on...

>> Meanwhile, you /do/ know about the subthread-scoring feature, right?
> 
> Er... which part of all this is the subthread-scoring feature? Actually,
> I guess that if I keep "hidden" articles visible, then I can just select
> them in the article list and mark their entire subthreads as read. (Spam
> and trolls are infrequent enough in the groups I visit that this isn't
> impractical to do.)

Actually, I had started to include that but decided to ask about it 
instead.  Of course if I had included it, I'd have added another hundred 
lines or so and been closer to that 599 record... =:^P

What triggered the omit that and simply ask the question instead decision 
was the fact that, as I believe I mentioned, I prefer to see the 
subthreads of ignored posts here, as they often contain interesting 
information or amusing retorts of their own, and I'd hate to miss those.  
(Often, I find that side comments on entirely unrelated areas can be the 
most helpful, sometimes giving me clues about solutions to unrelated 
problems that I had been struggling with for quite some time, or that I 
see a month or two later on an entirely different group in an entirely 
different context but can now help with due to that chance side comment.  
And guess what, abusive posts have a way of triggering such side 
comments! =8^0  )

For the same reason I seldom ignore or even score-down entire threads or 
subthreads, tho it does happen, rarely.  Anyway, as a result, I'm not as 
familiar as I might be with pan's functionality in this case.  In 
particular, I know the adjust-the-subthread-score-manually method, but 
I'm in doubt as to the precise function of pan's ignore-thread menu item, 
whether it ignores the /entire/ thread or just the subthread.

By the time I realized that, however, I was already well into the 
explanation of how to do it manually, with the assumption that the ignore-
thread option did just that written into it, when I suddenly realized 
that my assumption might well be incorrect!  I had used the feature 
before but only a handful of times, probably at least a couple years ago, 
and chances are, I had done it the long way back then for the same 
reason, so even then probably didn't know for sure what the menu entry 
actually did!

And it wasn't a very convenient point to interrupt things and test, 
either.

At that point I realized I was going to have to rewrite at least several 
paragraphs, and chose instead to do a minor tweak to what /had/ been an 
/entirely/ rhetorical question, previously, making it not so rhetorical 
after all, and punt and delete the rest.

So that's how you came to get that now not-so-rhetorical question sort of 
hanging out there in the middle of nothing, without the answer I had 
intended to provide, making it indeed rhetorical had it actually worked 
as I originally intended.  I was rather hoping you knew the answer 
already and my punt would be sufficient, even tho the evidence was to the 
contrary or the topic wouldn't have come up like that in the first place.

q^:=  (Yes, I did reverse that smiley. I'm feeling rather contrarian ATM!)

So, umm... try the article, ignore thread menu option, and see if it 
ignores thread or subthread.  As long as you're viewing ignored already, 
if it ignores the whole thread, you can pick and article therein and edit 
article's watch/ignore/score, and remove the bad score, if necessary.  If 
ignore thread actually happens to ignore only the subthread, you can set 
a hotkey for that item if desired and it'll be easy enough to invoke.

If it actually does what it says on the label, entire thread, you can 
still use the long method which is still partially automated.

1) Select the root of the subthread you want to ignore. (This will 
probably already be ignored if a previous ignore author score triggered, 
so you'd have viewed ignored turned on.  Otherwise you'll get only a 
subthread of the ignored article and other subthreads would need scored 
separately, so it really DOES need to be the subthread root, the original 
ignored article.)

2) Add scoring rule (menu item or hotkey, if assigned).

3) In the resulting dialog, the second line is...

And the article's [subject] [is] [<textbox>]

4) Change [subject] to [references]

5) The [is] will change to [contains] automatically, and the [<textbox>] 
content will change to the message-id of the selected post, which if you 
did it correctly, should be the root of the subthread you wish to ignore. 
(This is the partially automated bit, it happens automatically once you 
do #4.)

6) That's the gist of ignoring subthread.  Just select the subthread-
root, add-score, and change subject to references.

7) Don't forget to change the rest of the dialog (group, score, expire-
time) as desired, and then add or add-and-rescore.


But do keep in mind one aspect I DID discuss in the first reply.  If you 
ignore (-9999) the entire subthread, sorting the new subthread roots that 
you need to ignore subthread on, from the ignored subthreads themselves, 
will be difficult.  Instead, I'd suggest using -9998 (1 point from 
ignored) for the subthreads.  That will color them differently so it's 
easy to spot the difference, yet they'll still be sorted right next to 
the ignored ones so you can do the unthreaded sort-by-score and get them 
all at once, if you like.

Meanwhile, at some point I'd like to see a checkbox preference:

[] Ignore replies to ignored posts, too.

That way, you could set it and have them ignored, as you prefer, while I 
could clear it and have them treated normally, as I prefer, without 
hassle for either of us. =:^)

Even better, that could be treated as another scoring increment, so users 
that preferred it could simply score down such articles by whatever 
number of points, still allowing those scored up by other factors to show 
thru:

Change the score for replies to ignored posts by [] points.

I could simply set that [] to 0, while you could set it to =-9999 (which 
means ignored, and stop processing further incremental scoring for this 
post), and people who wanted something in between could set it 
accordingly.  And if for some reason, people wanted to score UP such 
replies (perhaps they found my observation about such replies having 
valuable side remarks even MORE true, to the point they wanted to up the 
score), they could even do that. =:^)

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