"Hello, World" report crashes Gnucash

Derek Atkins warlord@MIT.EDU
28 Feb 2001 12:22:26 -0500


Rob,

Rob Browning <rlb@cs.utexas.edu> writes:

> I think maybe there's some confusion here.  When a "real release" gets
> closer, there will always be the process of figuring out which systems
> we need to support, and how we have to support them.

Thanks.  That's really all I wanted to hear.  However, being on a RH
6.2 system, I would still like to continue working on Gnucash
development.  So, in some cases I think it's imperative to fix
the problem earlier.  For other cases I agree that it can wait.

> In this case, taking the gtkhtml issue as an example, it's my
> understanding, that it is *impossible* (or nearly so) for us to
> support the gtkhtml that comes on a *stock* RH6.2 system.  That
> doesn't mean that we have to (or necessarily would) force all 6.2
> users to upgrade their entire system to something else.  It means that
> we'll have to step back and ask the question you always have to ask on
> the development side: What should we do?  How to the costs of the
> possible solutions in terms of development time compare to the
> benefits and burdens those solutions will provide/impose on us and on
> the users.

Agreed.  I'm certainly willing to live without e.g. reports at the
moment, during the development cycle.  OTOH, I would feel extrememly
eited if, g-wrap didn't work ;)

Yes, these are important tradeoffs.  And I've been spending a lot of
my time trying to make sure stuff continues to work on 6.2, and
pointing out when stuff doesn't.  Most of the time the fixes or
workarounds have been trivial enough that they've been implemented.
In the case of e.g. gtkhtml there isn't a reasonable workaround.
Honestly, I'm not sure what the right solution is...

> In this case, off the top of my head, possibilities would include
> 
>   1) Require users to upgrade their entire system to RH X.X.
> 
>   2) Require users to upgrade some subset of their packages, using
>      packages either from RedHat or perhaps from us.
> 
>   3) Provide a set of 6.2 "helper" packages that install gtkhtml (and
>      dependencies) in a "sandbox" directory, and set up the gnucash
>      6.2 rpm to use those, via LD_LIBRARY_PATH or -rpath.
> 
>   4) Require users to build/install gtkhtml and friends to
>      /usr/local/foo according to a 6.2 recipie we provide.
> 
>   5) Provide a GIANT 6.2 RPM with everything needed statically linked.
> 
>   ... etc. etc. etc.

Again, agreed.  My personal preference would be 3, but again there are
a lot of tradeoffs here.  And yes, I _do_ understand them.  I've been
maintaining a __binary kernel module__ for Linux since 1994.  Do you
know how hard it is to maintain a module for the Linux kernel when you
can't release the source-code?  Talk about a release-engineering
nightmare!  I literally had to tell people "you can only run these
versions of the Linux kernel, configured in this particular way".  It
sucked hairy rocks.  Thank god IBM finally decided to open-source it
all.

> My point is that all of these possibilities involve tradeoffs, and
> figuring out which battles are worth fighting and how hard is an
> important and painful part of the development/release process.
> 
> Suffice it to say that we *will* address these issues at release time,
> but until a stable release is near, the longer we can delay, the
> better, because as time passes, the set of issues we'd need to address
> constantly changes.

Are you sure about that?  I would think that as new features are
added, "backwards compatibility" should be maintained.  When the time
comes when there isn't a reasonable means to do backwards
compatibility, then perhaps the list of issues should be kept in a
file somewhere.  For example, I didn't know about the gtkhtml issue
until today.  Is that in a README, TODO, or BUGS file?  Perhaps we
should create one?

> WRT RH 6.2, for now I think you can rest easy.  AFAIK, Dave has made
> it clear he plans for us to support 6.2, much to my guile and g-wrap
> related dismay :>

Yea, I know.  You've put a lot of work into g-wrap to maintin
compatibility with guile 1.3.  I know, I've helped test (as best as I
can ;) I'm glad that Dave is going to keep RH 6.2 compatibility.  And
as I said I can certainly live without some features for now.  But at
some point we're going to have to get those features working again,
and I hope that I can help there.

> Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930

Thanks,

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available