[Alexandria-list] 0.6.3 Plans

[Cathal Mc Ginley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 28 Jan 2008 00:49:30 -0500
"Joseph Method" <tristil at gmail.com> wrote:
> > This seems like a lot of work. Do any other mid-sized programs do
> > this?
> 
> Well, it's a question of whether  a) to require that all the optional
> packages be installed b) not require them and provide instructions on
> the website indicating which to install or c) providing a virtual
> package so that a power user can opt out of installing the extra
> packages. I would say the goal is to avoid getting "where's the
> feature in the screenshot" questions, which is why I prefer a or c.

I suppose what I really mean is "What is the Debian way?"
(Unfortunately, we no longer have a Debian packager on the project who
can advise us in matters of the Debian Policy. But I *think* that
solving this issue with a virtual package would be contrary to
the policy.)

In any case, it might be the wrong approach - or rather a solution to
the wrong problem. I know that when I set up a sample deb repository
with gNewSense (an Ubuntu-variant) just before the 0.6.2 release, (to
test dependency handling, actually) I got a single-click install of
Alexandria through Synaptic, and all of the "Recommended" optional
dependencies were automatically marked for installation. This feature
is also available through apt-get and aptitude (by adding command-line
options, I think).

Once we set up our own deb repository (or when we get the latest
version of Alexandria back into Debian) we can just modify the
installation instructions we give to achieve this outcome. At the
moment our instructions are to run 'dpkg --install alexandria.deb';
optional dependencies are not automatically loaded, or even suggested.
(This was the problem recently encountered by Jack Myrseth, it seems.) I
just think the problem might fix itself when most of our users are
installing Alexandria via deb repositories.

> About the suggestion on the wiki page,
> 
> Exceptions in the application layer should no longer cause the
> application to crash. (In glade_base.rb, the event handling block
> should wrap the call to method(handler) in a begin and rescue.)
> 
> I have to think about this some more, but I'm thinking that any time
> an explicit crash occurs at that level we want to know about it and
> correct it. We want the user to send the bug with the exception
> message, rather than describe the error or broken behavior which might
> emerge further along. Usually crash errors provide a clue.

Well, I didn't mean that we should just squash all exceptions!

Exceptions in the application level don't necessarily lead to crashes;
they only become crashes when we don't have a strategy for catching
exceptions and we allow to program to terminate instead. What the user
sees is that pressing a button or something has caused the main
application window to vanish - the hallmark of an unstable program.

What I was thinking was that this particular location (GladeBase) would
be a good area to hook into some graphical exception handler,
explaining to the user that an unexpected error occurred and providing
the same stack-trace and version information that a crash report does -
just without having to terminate the program. This would make it easier
for the user to report the error to us.

   -   C.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: GnuPT 2.6.2.1 by EQUIPMENTE.DE

iD8DBQFHnXwgfMAUnRdb+8oRAmKIAKDK0uH5VEilY4JQn0+ZxS9nS4XPjACfQxD5
34vVuIfAmnmly2hpw8iTDqI=
=s1LM
-----END PGP SIGNATURE-----