Google
 

Digg Links

Tuesday, September 26, 2006

Boring documentation

OK, after debating all the GUI Ebuild Builder thing and considering responses I got about it, I have to agree: it may not be implemented soon. There are issues to be solved to consider such thing in the first place, and they do require some effort to solve them.

So, in meantime, I thought about solving the problem by doing something else:
1. Redefine it. Which problem exactly GUI Ebuild Builder is trying to solve? Maybe we're trying to solve the wrong problem.
2. Try to solve the "original" problem some other way.

I believe that "original" problem is being documentaion. I know, I know, documentation is there for a reason. But for an occasional user or for initial steps it is huge, intimidating and boring. It is boring to read piles of docs just in order to start and create some simple ebuild, and it has no appeal at all for an occasional user.

So if we try to solve the "boredom" problem of getting familiar with docs (or any info for that matter) at the beginning of the process, we may get more attention from potential users, and more people may try to get into portage/ebuild development.

I have a suggestion as to how potentially solve this problem, and it's in the works as I write this. More details later (maybe few days)

3 comments:

Eddy Mulyono said...

A 20 minute ebuild tutorial? (like those web framework tutorials...)

Alex said...

:-) sorta

Steve Dibb said...

Another problem (heh) is that the ease of creating an ebuild highly depends on how easy it is to actually install the program.

Writing an ebuild is actually pretty simple. Writing an ebuild for a program that has crappy Makefiles, confusing configuration options, and non-standard installation procedures is a real pain.

That's what makes it hard -- upstream deviating from simplicity.