Re: gripes, etc.

[Havoc Pennington <hp redhat com>]

Andrew Sutton <asutton21 home com> writes: 
> 1. there's no roadmap.
> 
> i looked all over gnome.org for some kind of a product roadmap. i picked
> up the major categories of development (desktop, office and
> development), but there's nothing that seems to tie those together. any
> developer can walk thru the product list and pick out back-end,
> middleware, and user interface software, but it's confusing and time
> consuming.
>

http://developer.gnome.org/status/roadmap.html has some information on
the devel platform. It's in the process of being updated to reflect
current reality (but it isn't completely off-base, aside from
timelines).

> 2. i couldn't find any evidence of a steering commitee.
> 
> i found a couple of primary developers - but that doesn't seem to be
> quite the same. it left me questioning the future direction of the gnome
> component model and the directions that various applications are taking.
> for example, what's going to happen when corba 3 comes out. it defines a
> component model - a very comprehensive one too - i scanned thru the 500
> page spec a while ago.
>

There is a steering committee, but said committee doesn't actually do
what you want (plan the technical direction). The technical direction
is planned by the people involved in developing each technical area, 
i.e. the primary developers. So for example if you were interested in
CORBA 3 (and briefly, I think the answer is no we aren't going to use
their model, we're using the Bonobo model which is very COM-like), you
might mail the Bonobo developers or gnome-components-list gnome org 

We are in general reluctant to make web pages saying "the technical
direction is X, Y, or Z" because the technical direction changes a
lot, and the web pages just end up being wrong. Free software can
often end up being "whatever people contribute" rather than following
a master plan (though some contributors are employed by companies that
do have various plans, and we have a general group consensus on some
of the larger-scale issues).
 
> 3. no middle ground documentation
> 
> every piece of documentation i read on gnome.org and went from screen
> shots with brief capability descriptions to header files and
> documentation of function calls. the task of learning gtk and gnome is,
> for lack of a better word, a little daunting. especially, after coming
> home from a long day of coding for different systems. in short, there's
> either too little or too much documentation. somebody needs to draw the
> object model for gtk and gnome (since they're so obect oriented). uml or
> booch would be perfect. the learning curve for new developers can be
> significantly reduced (assuming they can figure out the notation).
> 

Agreed. Some of the books you can buy should help here; one of them is
even free at http://developer.gnome.org/doc/GGAD/.

> 4. i still didn't solve my problem
> 
> just a gripe in general. i think the linux development community could
> definitely benefit from a design tool like rational's modeller. imagine,
> making the right decisions early can save you from complete rewrites
> later (as technologies change and evolve). so, if there's one in the
> works... great!, otherwise... um... anybody want to write one? i have
> limited (read none) gnome development experience, but i can definitely
> contribute solid ideas.
> 
> imagine the possibilities... integrated development envirionment with
> design, gui development (glade), code generation, documentation
> generation, code editing (wouldn't be much of an ide without it),
> requirement tracking, bug tracking, configuration management... just
> thinking big :)
> 

Yes, we really want this. ;-) Unfortunately most of the IDEs currently
being worked on are still in the baby-step stages, as far as I've
seen. Also they tend to start with a text editor and grow hackish
mutations, or require you to use a specific language, or other flaws.

Havoc