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