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@xxxxxxxxxxxxxxxxxxxxxx > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
