[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: On the nitty-gritty of user-experienced problems



On Fri, Jan 14, 2005 at 04:23:47PM -0500, Stuart Brorson wrote:
> Hi --
> 
> 1.  The reason most people use off the shelf distros is to avoid
> dependency hell.  You are currently trapped in dependency hell because
> you prefer to roll your own Linux system.  That's fine, but don't
> complain when you get bitten by dependency problems.  In any event,

The dependency aren't problems. The problems are caused by the fact
that the programs have flaws in usage instructions.

> I'd imagine you're smart enough to figure it out eventually.  And
> you'll be a more knowledgeable person for having been through the
> exercise.  
> 
> 2.  Please separate your GTK problems from your gEDA problems.  We
> can't help you with GTK, at least on this list.  

I don't think this should be separated. If you chose to build upon a package
which is problematic, you should be notified of the fact the package is
problematic.

I have to supply the details as a proof, otherwise I could have made it up.

> 3.  Please provide specific details about specific problems you
> experience with gEDA.  We developers can fix specific problems, but we
> can't do anything with generalized grousing.
> 
> 4.  As for step-by-step documentation about how to do things using
> gEDA. . . .  Well, I've written some, particularly about how to do
> SPICE.  Bob Wilson wrote an excellent tutorial about taking a board
> from schematic capture to layout.  Dan has also contributed a HOWTO,
> and Ales has written tons of documentation.  You are clearly a gEDA
> power user. Why don't you write some documentation to help newbies
> install and configure gEDA? 
> 
> 5.  Finally, as for including GTK in the install media, I have thought
> about doing that with the gEDA CD.  The problem is that GTK is fraught
> with dependicies, and I don't want to turn my fairly simple Python
> installer into a monster program.  Therefore, I support a few common
> Linux configs, such as RH9, SuSE9, FC1, & FC2.  I test the installer on
> these configs to verify that it works.  On other configs, you're on

OK, then write "For running gEDA, you need RH9, SuSE9, FC1 or FC2"
and I'll stop complaining and move on to Sodipodi to draw my
schematics :)

> your own; I can't test and support all possible Linux configurations.
> The same holds true for gEDA in general.
> 
> Note that this is a common strategy in the commercial world.  Reality
> is a very messy, complicated thing.  It's impossible to support

You don't have to mess with the reality outside. Just write what is
necessary and keep in mind how difficult is to fulfill it.

I could also instead of playing with transistor, put one ML6652 into
Ronja, and on complaints from users "minimum quantity of ML6652 costs
so much it ruins me" respond "that's your problem. Reality is a messy
thing and this is a common strategy in the commercial world."

> a program (or anything other engineered product) on every possible
> configuration which it might experience.   Therefore, one specifies up

Then please read again the features of Links:
http://atrey.karlin.mff.cuni.cz/~clock/twibright/links/features.html

It *is* possible. But if you believe from the start that it's impossible
(which is an untrue illusion projected upon you from how the things
are common to work these days), they you will never achieve it.

Be glad I don't complain about gEDA not running on svgalib, OS/2 pmshell
and framebuffer, and complain just about GTK+ ;-)

> front what the supported configurations are. Beyond that, the customer
> is on his own.

I think to be useful it's necessary to choose the supported configurations
set sensibly. And if the users report it's hard to achieve, I think it's
a regular complaint.

If my users on Ronja complain that it's hard to get HPWT-BD00-E4000, then
I can solve the problem for example by releasing infrared Ronja which
uses HSDL42?0, which is far more available ;-) (And this happened).

Cl<