[Pan-users] Re: 0.118 - Stop task doesn't work.

[Duncan]

walt <address@hidden> posted
address@hidden, excerpted below, on  Sat, 04 Nov 2006 22:57:07
+0000:

> On Sat, 04 Nov 2006 01:36:13 +0000, arndalebilo wrote:
> 
>> On Sat, 04 Nov 2006 01:19:49 +0000, arndalebilo wrote:
>> 
>>> I started downloading a large-ish (6000+ lines) article with attached
>>> binary by mistake.  When I opened the 'tasks' window and clicked the 'stop'
>>> icon the task's caption changed from 'running' to 'removing' but the
>>> download didn't stop until it had completed.  Clicking the 'delete' icon
>>> also didn't help.   
>>> 
>>> Am I missing something?
>> 
>> Clarification -just tried it again.
>> 
>> "stop" had no effect at all.
>> "delete" changed the caption to "removing".
>> 
>> Neither stopped the download.
> 
> I just opened Bug 370757 at bugzilla.gnome.org and labeled it 'blocker'
> because IMO this should be fixed before 1.0.  Not sure why no one else
> has confirmed.  It's quite obvious now that you pointed it out.
> 
> Duncan, can you reproduce this bug also?

I don't need to, as I know what's going on.  (I was going to reply to this
but guess I decided to check the rest of the messages and then forgot
about it, or something, so glad you replied so I see it again.)

In old-pan, when you clicked stop, it would finish the individual
post-segment it was downloading and then stop.  That was reasonable, as
chances were 50/50 that it was at least half-way done with the individual
part anyway, and they are small enough that even on dialup it's usually not
/too/ much of a delay, so rather than leave a half-part in the cache or
code special case handling to delete it, just finish downloading just that
part, and /then/ stop.

I'd be willing to bet that Charles took the same approach with new-pan --
except that new-pan has a critical difference.  Where the logical unit was
a single post segment/part in old-pan, one of the changes that made so
much difference memory-wise in new-pan was treating all the individual
posts that create a single file attachment as a single unit.  Often, that
single file attachment is fifty-ish individual post segments/parts.  Thus,
while old-pan would still quit reasonably soon finishing the
single-segment unit it was working on, new-pan takes far longer to finish
up the (say) fifty-segment still single-unit /it/ works on.  Particularly
for those on dialup or if the connection is very poor, that's going to
SUCK!!

You are right.  This needs to change.  The problem at this point is that
if I'm correct in the above, any change for 1.0 will require enough new
code, either to clean-up what's left, or to somehow split the single-unit
up and only finish the individual part (as old-pan did), or whatever, that
it's opening a big can of worms for this late in the cycle.  I'm honestly
not sure it's worth it for 1.0.

Now Charles HAS mentioned previously that he's prepared for a few more bugs
to show up with the wider exposure of 1.0 stable, and that if such should
happen, he plans to have a 1.0.1 or 1.0.0.1 or the like, much like the
(Linux) kernel's stable bugfix series (like the 2.6.18.2 that was just
released, after 2.6.18 stable and the first bug-fix 2.6.18.1).  What I'd
propose at this point is letting 1.0 out the door without this fix (unless
there's at least one other major bug to fix, thus delaying it anyway),
followed almost immediately with 1.0.900 or whatever, the first pre-1.1
beta.  The first fix in this beta would be the stop-task fix, however
Charles decides to code it up, possibly with one or two other simple
feature additions but nothing touching the same code area as the stop-task
fix.  If /that/ beta works fine, no bugs in the stop-task code, however
he has chosen to handle it, /then/ backport the stop-task code (but not any
additional features which might bring their own bugs) to the first 1.0
stable bugfix release, 1.0.0.1 or 1.0.001 or however he versions them.

See, the problem is that fixing this before 1.0, if I'm right on the size
of the code rewrite required for a fix, could easily trigger another
(say) four weeks of bugfix cycle releases.  IMO we're past the point at
which that's feasible.  The freeze is really that deep at this point,
and the risk that great for the amount of new code we are likely talking.
If it's not a security issue or a crasher issue or a corrupted data issue,
and this isn't, it's simply not worth opening the code up far enough to
let this -- with all the additional bugs it could bring -- in.

That's my take.  Now to go mention it on the bug.  Only I think I'll
simply point here for it as I think I made the point better here than I
likely could again.

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