[Pan-users] Re: New version of pan ?

[Duncan]

Petr Kovar posted on Tue, 25 Jan 2011 02:47:09 +0100 as excerpted:

> So with regard to the long-awaited 0.134 release, [... s]tay tuned,

=:^)

FWIW... one thing that Charles has suggested, move quickly to a 1.0 
release and go from there.  Of course that'd be upto you and khaley, but 
if you decide to do it, I'd suggest at least a short 0.134 as what amounts 
to an rc.  Let the various distribution maintainers as well as the users 
kick it around for a few months, then, if there aren't any big 
regressions, consider moving either that code or something close, before 
you start integrating a lot of new features that would need further 
testing, to the big 1.0.

Just a thought.

I've some mixed feelings on it as there's at least one feature that hasn't 
been restored to the "new" C++ branch, the old rules feature, to actually 
do something (like auto-download, auto-mark-read, auto-delete) with 
messages based on score among other things, but as Charles pointed out, 
there aren't /that/ many around that remember that far back, and a 1.0 
release /would/ make some news and send a message that pan isn't dead yet.

The other thing that has been talked about for years, before a 1.0 
release, would be a manual.  But of course that needs someone to volunteer 
to put it together.  There've been various people start on it over the 
years, and it's /possible/ the last person to do so, who had a good start 
going shortly before Charles went into quite mode again, still has his 
archive around, if anyone's interested.  But practically speaking, I don't 
believe it's worth waiting around for unless someone picks it up pretty 
much immediately and there's active progress and continued work on it over 
some months, to the point pan itself is ready.

Meanwhile, one other thing that had been kicked about, either for 1.0 or 
possibly for a 1.1 or 1.5 (arguably the feature would merit more than a 
minor version bump, thus the 1.5 argument) or something shortly 
thereafter, would be at least a limited (that is, as single-part) binary 
posting ability.  Doing single-part isn't all that hard, according to 
Charles, and with one beta (IIRC before the switch to C++ tho, so quite 
some time ago and any code from then would be pretty much worthless now) 
there was actually a non-functional GUI for it, before Charles deactivated 
it as he wanted to do it "right" (that is, multi-part, possibly with par 
support, etc) or not at all, so not at all it has been, and we've always 
pointed to newspost or the like for folks wanting to post binaries.  But 
personally, I'd love to see at least single-part bin-posting, as for many 
including me, that'd be all we really needed... for posting the occasional 
screen shot or whatever, and people that needed more could still use 
newspost or whatever they're using; it wouldn't change anything for them 
but would vastly improve things for those who only need single-part 
attachments only once in awhile.  But while even single-part bin-posting 
would be useful: the very fact that pan has been able to do without it to 
this point supports not holding up 1.0 for that.

Oh, and another long-standing feature request, but DEFINITELY nothing to 
hold-up for as it has been around since before scoring (back then it was a 
trinary kill/normal/watch, not the nearly continuously variable scoring 
pan has had for years), so well previous to the 0.90+ series, would be 
making scoring possible on all headers and the whole post after download, 
not just on the overview data.  Such scoring wouldn't be as efficient as 
over-view-only scoring, but it'd make possible such things as killfiling a 
user who deliberately abuses from header changes to avoid killfiling, but 
whose x-complaints-to, organization, and/or other headers or the body 
content itself, remain consistent enough to filter by.  I've wanted that 
ability for a very long time and there's a bug from I'd guess at least 
five years ago posted to that effect, but Charles marked it "bluesky", as 
something that would be nice... "someday".  Maybe I'll get lucky and get 
it for pan 1.5 or 2.0? <shrug>

There is one very frustrating but equally long-standing bug having to do 
with pan not seeing new posts in groups just subscribed (or freshly 
visited without subscribing) if there are cross-posts between it and a 
long-term subscribed group, that I'd love to have fixed before 1.0, but 
I've not been able to sufficiently narrow it down or describe it well 
enough to really form a good bug report, and as the bug has persisted for 
years, I don't see that it's practical to hold up 1.0 for it, either.

(FWIW, the bug triggers for me on gmane, on the 
gmane.comp.freedesktop.xorg.announce and gcfx.drivers.ati groups, which 
I've subscribed but don't get any posts to, because apparently there's at 
least one cross-post to a group I've followed for much longer, that's 
triggering this bug.  Similarly, gmane.linux.gentoo.devel.announce and 
gmane.linux.gentoo.project are "dead" groups for me due to this bug, 
because I've long followed glg.devel and there's been quite some cross-
posting, triggering the bug.  If I erase all pan's state and data files 
and start pan pointing at an empty dir, so my past group history isn't 
around to interfere, I see posts in the groups in question, but as soon as 
I restore the history from my regular groups, I can't get posts to the 
affected groups again, tho the old ones fetched without the history remain 
and can still be viewed.)

So if we/you do believe a "quick" 1.0 is warranted, I'd say

1) $elease 0.134 quickly, as an rc

2) Have people contact the distro maintainers and get them to test and 
release it quickly, for this spring's 6-month releases.

3) With 0.134 safely tagged, continue developing pan for six months or so.

4) If there's no "weird stuff" reported for 0.134, release essentially 
that same code, plus very minor fixes if any, as 1.0

5) If there's been further 0.1xx releases in the mean time, bump them 
accordingly, to 1.0.80.x (saving 1.0.x, x < 80 or pick an appropriate 
number, for bug-fix-only) and discontinue the 0.1xx series.

6) Any major new feature code gets added to the 1.0.80 (or whatever) 
series for a 1.1 or 1.5 (or whatever) release.  Or do the old kernel odd-
minors are testing, even minors are stable, thing.

7) Such new-feature code might include at least single-part attachment 
posting, rules/auto-actions, full-header/body scoring, etc.

8) Add a manual if/when possible, ideally for 1.1/1.2 or 1.5/2.0 or 
whatever, but don't hold them up for it either, unless there's serious 
manual activity that warrants doing so.

9) If my bug or other major bugs are ever fixed, get them in whatever 
current series, right away (unless of course the fix is huge, my bug at 
least has been long-standing enough, possibly the entire 0.90+ series and 
maybe even back into the 0.15- series, it's not worth potentially 
introducing major new bugs in a stable series for).

Or... just continue with the 0.xxx series.  It's not as if we're going to 
run out of numbers before it turns into 0.xxxx any time soon.  But a 1.0 
release /would/ likely trigger a lot of reviews, etc, which could bring in 
some new blood... as much as we're likely to see given the application 
space pan is in, anyway.  (Of course, the benefits of "new blood" just for 
the sake of it could be questioned too, maybe we don't want to make waves 
and simply continuing the 0.xxx series is better?)  Either way's fine with 
me, but it's up to you devs, in any case. =:^)

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