[Pan-devel] Re: Pan 0.14.2 Won't Compile

[Duncan]

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

Well... 

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 
watching.)

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

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