Robert Kaiser wrote:
Rostyslaw Lewyckyj schrieb:
But of course with 2.3 almost here,
bugs with 2.1 or 2.2 or upgrade there-to will not be addressed.

Bullshit! The bug fixes will just be included in future releases. That
is, if good bug fixes are found - for this bookmark importing problem,
it's very hard to find one, because we don't even know the circumstances
when the problem happens.

Robert Kaiser


No, not Bullshit, but charging elephant shit :-)
Any person who is on say SM 2.2 and encounters bugs in that release,
will not be able to remain with the UI features of that release,
and just obtain fixes for the bugs/misfeatures in 2.2, without
needing to wait until some future SM 2?.x which will have new
mandatory features needing to be user debugged after the upgrade.
This 2?.x will of course, as happens with all new features code,
contain its own basket of fresh bugs.

How about changing the upgrade code by adding a programmed check for,
did the bookmark conversion happen? i.e.:
- Check the new bookmark data structure contents against the old
bookmark.html contents . If the conversion was faulty,
generate a debug dump report and send it to development central.
(some recording of circumstances might need to be saved at the start
of the process, on a contingency basis )
- Release this 'instrumented' code into the field.
Then you wouldn't have to wait for users to 'perhaps' report
the failures anecdotaly.

I believe that you would get faster results with this than by
reading, hunting in, the code, or with code walk throughs.
But Of course this would mean breaking the policy mandate of,
NO SPECIAL debugging/fix RELEASES.
--
Rostyk
_______________________________________________
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Reply via email to