[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Pan-devel] Re: Pan 0.14.2 Won't Compile
[Pan-devel] Re: Pan 0.14.2 Won't Compile
Mon, 30 Jul 2007 14:42:52 +0000 (UTC)
Pan/0.131 (Ghosts: First Variation)
Michael Satterwhite <address@hidden>
posted address@hidden, excerpted below, on Mon,
30 Jul 2007 08:02:10 -0500:
> If 0.14.2 is not the version of pan that should be used, then the
> website shouldn't be recommending it as the stable version. A newer
> version needs to be promoted to stable, and a new fork made for beta
pan is at present in a rather inconvenient time/tech/tradition warp.
>From my viewpoint, the root of the problem was an incorrect estimation of
the time and work necessary to get current pan into tip-top shape. Back
in April of last year (2006), Charles came out with pan 0.90, a complete
rewrite into C++. He had been working on it for some time privately (no
one knew about it until then, but that's why he'd left the old C code
almost untouched for two years, many list regulars had begin to think he
had deserted us and pan was an orphan project, so we were pretty relieved
to find out he'd been working on the rewrite all that time), and
apparently thought it was pretty close to ready to go stable, but not
only "stable", but THE BIG STABLE, 1.0. He announced weekly betas, of
which I imagine he figured there'd be less than 10, so before pan hit the
turnover from 0.99, there'd be a stable 1.0 release. It kind of
surprised me that he shot for a 1.0 stable right off, but he did. If it
had actually happened that way, it would have been 10 weeks or so, say 12
with a couple extra weeks to be sure it was stable, so it would have been
released in July or so of last year (2006).
Needless to say in hindsight, that was a pretty drastic underestimation.
I couldn't even start regularly using the new version until 0.95 or so,
and there were some pretty big fixes up thru 0.108 or so. Even so, while
I had been telling people by the end of the year (2006) tho I didn't
expect it to take that long, by the beginning of July, both Charles and I
thought it was coming along nicely, and he said he couldn't see why 1.0
couldn't happen in August.
Well, August came and along with it a couple more pretty serious bugs.
August went. I reverted to saying "soon" for 1.0. Eventually the bugs
were fixed, but others not quite so bad appeared. Then we hoped to have
1.0 by the Debian freeze in Sept. It didn't happen.
By late November (Thanksgiving season, US), it was beginning to be
apparent not even my originally thought "cautiously safe" prediction of
"by the end of the year" wasn't likely.
Of course, by this time the weekly betas had Charles sort of burnt out,
and he took a week or two off a couple times. OTOH, he did a few 5-ish
day turnarounds as well. So anyway, the next symbolic date was the
beginning of April this year, a year after 0.90.
Well, here we are headed towards August, a year after Charles with my
agreement thought pan should be ready, and Charles, understandably burnt
out on the weekly betas, has turned his attentions at the moment to
another project. (I don't recall which one, nothing I'm involved in, but
someone on the list mentioned he was active on some project they were
That's the fast-forward version of the up-close view. Zooming out a bit,
there's another problem, hinted at above. Traditionally in the FLOSS
community, the 1.0 release is a *BIG* deal. You can have stable versions
before that, but 1.0 means you REALLY think it's ready for public
consumption, and is not only fully stable but generally mature and
functionally complete. With a 1.0 release, a lot of new people see the
publicity and try it. If they get turned off at that point, there's a
fair chance you'll never see many of them again. So 1.0 is a BIG deal,
and it *HAS* to be RIGHT!
That's a bit of a problem. Yes, the pan rewrite betas have been more
stable and in many ways more functional than the old "stable" pan since
0.112 or so (barring a couple individual bad betas and a series of about
four where the wrapping was bad enough to be almost unusable -- a
rewritten wrapping algorithm that took a bit to get the kinks worked out
of). Normally, we'd have another official stable by now, maybe even two.
Unfortunately, it hasn't been really stable enough for a good 1.0, and
since that's the intended next stable... well, there's the problem.
Compounding that problem is the fact that in at least one way, current
pan still isn't as functional as old pan was (tho it's way more scalable,
and better in other ways). With old-pan, it was possible to tell pan to
for example, auto-delete ignored articles, auto-mark-read those scoring
less than zero, and auto-download watched or indeed, all messages. That
"auto" functionality is still missing in the rewrite, and arguably, some
still on "stable" old pan will miss it. (In reality, the improvements
such as scaling and auto-multi-server handling make up for it in most
cases, and it can be worked around in others, but it's still popular
functionality that's now missing.) However, Charles says he's not going
to worry about that for 1.0 and has moved those requests to the 1.1
So that's where we are. 0.14.x is a deadend, code no longer supported,
despite it being officially "stable". The 0.1xx series is in general
more functional (with the named exception) and definitely more scalable,
and is as stable as official "stable", particularly against the other
updated software in a newer distribution. However, since 1.0 is the
announced next stable and we've been "not quite there yet", for an entire
year now, we're stuck!
OK, so I haven't confirmed this with Charles, but I suspect that his
thinking on taking this break, besides the fact that he'd worked hard and
was simply burnt out for the moment, is that it'll allow time for the
code to settle down a bit and any remaining bugs to shake out by general
usage. If I'm correct, when he returns, he'll make a few very limited
changes to the code to fix whatever bugs have been reported that can be
fixed in a strict freeze situation, likely release one or two final
"release candidate" betas just to be sure his final fixes didn't horribly
break anything else, and then declare 1.0.
After for better or for worse 1.0, we'll have a stable base to work on.
Charles has indicated he intends to tag a 1.0 stable branch, with any
post 1.0 stable branch bug fixes then released as 1.0.01, 1.0.02, etc,
while opening up development again on head, to eventually release 1.1.
There are currently several wish-list items slotted post 1.0, presumably
for 1.1 and beyond. I mentioned the auto-(delete|mark-read|download),
which is planned to be based on scoring. Implementing some form of
subscribed group categorization is on the list too. I believe those are
the two most popular ones, but there are others.
Charles hasn't indicated whether post 1.0, he intends to do fewer "big"
stable releases, multiple features, or more "smaller" stable releases,
only one big feature or a handful of smaller features introduced each
time for 1.1, 1.2, etc, but then having them come closer together.
Personally, I hope for the latter, shorter, smaller release cycles.
However, while I'm the most active and possibly the most senior list
regular, I'm not the one writing the code, Charles is (with occasional
patches as submitted by others). As they say, he who codes, decides, and
that's Charles. I and others do what we can to help the process along
and make Charles' job easier, but it's Charles' project and Charles
making the decisions, and that's the way it should be.
Meanwhile, those of us who don't code will be here, waiting like the dog
eagerly awaiting those ever so delectable table scraps. =8^)
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