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
useful.
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
goal.
Cheers,
--xsdg
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
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
