This email won't really address your points, but as a GIMP dev-let who 
is both new (wrote my first big patch a few weeks ago) and old (been 
hanging around #gimp for 5+ years), I think I can add an interesting 
perspective here.

First, a large part of the learning curve is figuring out GIMP's 
dependencies and how it interacts with them.  A large part of my own 
difficulty in getting up to speed has been figuring out how to track the 
flow of execution through GTK and through GLIB/GObject.  As I've looked 
at the GIMP code over the years, this has become easier and easier.

In my case, forcing myself to think "ok, GTK isn't magical, it's just C. 
  Callbacks are just function pointers.  State is just structs.  Events 
are just callbacks." has significantly helped me avoid being intimidated 
by the code — I can use my C skills to figure out things that at first 
seemed foreign and confusing.

The next thing is that it's hard to get a high-level picture of what 
connects to what.  I spent a few weeks spelunking through the code, 
trying to track down where a color-management regression was introduced. 
  When mitch mentioned the specific call-site that was broken, I was 
able to whip up a working patch in a day.  I think a high-level 
document, even simply explaining what the different top-level source 
directories are and what functionalities are contained, would be really 

Finally, it's both a blessing and a curse that so much happens over IRC. 
  It's good because it enables communication and action to happen much 
more quickly than if all communication were by email.  It's bad because 
the communication is so time-sensitive.  I think this is a large part of 
why non-Europeans often find it so difficult to get up to speed — all of 
the knowledgeable folks tend to be around at the same time, and they 
also disappear at the same time.

To respond in part to your proposal, I think one potential challenge 
with a bootcamp-type thing is that understanding GIMP relies so heavily 
on understanding its dependencies.  For instance, an experienced C dev 
and an experienced C/GTK dev will need to start in entirely different 
places, and any sort of GTK instruction beyond "here are the docs; 
they're nicely hyperlinked, have at" will take a long time.

To be clear, I definitely think a bootcamp-like thing (where the time 
spent is amortized across a number of folks) would be valuable, 
especially if the content is sufficiently compressed that people from 
different timezones can look at a log and follow along after the fact. 
It could also provide a good springboard for deeper questions about 
GIMP's structure or where to start digging to accomplish a more specific 


On 01/27/2011 09:43 PM, Eric Grivel wrote:
> I am getting the impression that the Gimp project is trapped in a
> chicken-and-egg problem with regard to attracting new contributors,
> where the few core developers are too busy maintaining the product to
> spend a lot of time helping new developers come on board.
> Gimp is an extremely large and complex system. I am a fairly experienced
> coder myself, and have recently submitted patches for two open bugs. But
> those were easy ones, not really related to any Gimp structures but
> basic "C" bug fixing. I have looked at some of the other outstanding
> bugs and for most don't have a clue where to start, or how to make sure
> that my fix fits in the vision, or that it doesn't break something else.
> At this point, knowing how busy the core Gimp developers are, and
> recognizing that it will take more time for them to walk me through a
> problem and a solution than it would take them to just fix the issue
> themselves, I am hesitant to ask for a lot of help. On the other hand,
> the idea of just delving in and figuring it out myself is quite daunting.
> Which is where my thought of a "boot camp" came in. What if there was a
> group of potential new developers all struggling with the same learning
> curve? Wouldn't it be great if an experienced Gimp developer could lead
> the whole group through a series of exercises, designed to gain
> experience and understanding of the Gimp and Gegl internals.
> This would require some serious commitment of time by one or more of the
> Gimp developers, and would mean other work wouldn't get done. The
> potential payoff however in the form of bringing one or more additional
> Gimp developers up to speed could be significant.
> Eric
> _______________________________________________
> Gimp-developer mailing list
> Gimp-developer@lists.XCF.Berkeley.EDU
> https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Gimp-developer mailing list

Reply via email to