Hi Steve,

On Tue, Jan 25, 2011 at 09:35, Stephen Greenwalt wrote:

Where can I help? Here's an ultra-short overview of my background:

I'm not a developer, but an long term Gimp user. I would suggest: 1. Go into the IRC channel to get direct feedback from the developers. 2. Try to checkout and compile the latest version from the git repository. 3. Have a look into the bugs with the gnome-love keyword: https://bugzilla.gnome.org/buglist.cgi?quicksearch=keywords%3Agnome-love+product%3A%22GIMP%22+ 4. Talk about the bug you are interested in. (IRC or mailinglist) 5. Add a patch to the bugreport.

Alternativ you could help with gegl, have a look at this mail: https://lists.xcf.berkeley.edu/lists/gimp-developer/2011-January/026046.html

Regards, Tobias

On Tue, Jan 25, 2011 at 12:35 AM, Stephen Greenwalt < stephengreenwalt@gmail.com> wrote:

Where can I help? Here's an ultra-short overview of my background: ...

Here's one suggestion that you could probably work on immediately, and would prepare
you to work on other things if you are interested. Gimp has a plug-in called Lighting Effects
that simulates the results of shining lights on 3D-deformed images. It is pretty fancy and
sometimes gives neat results, but the rendering procedure it uses doesn't work as well as it
could, because the triangles that it decomposes the surface into are too small -- you get a
lot of faceting effects that a better algorithm would avoid. Plug-ins are more or less freestanding
code, so it ought to be possible to improve the rendering without a huge investment of time in
learning the whole architecture of Gimp -- but you would learn a substantial amount about the
architecture as a side-effect of working on it.

-- Bill

On 01/25/2011 09:35 AM, Stephen Greenwalt wrote:

Where can I help?

It would be great to get help with bugs put on the 2.8 milestone: https://bugzilla.gnome.org/buglist.cgi?product=GIMP&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&target_milestone=2.8

Regards, Martin

On 01/26/2011 06:55 AM, Stephen Greenwalt wrote:

Here's one suggestion that you could probably work on immediately, and would prepare
you to work on other things if you are interested. Gimp has a plug-in called Lighting Effects
Thanks for the info. I have used that filter many times, and I will take a look at what you describe.

Thank you for the offering. I would like to point out though that it would be even more helpful in the long term if the plug-in was ported to a GEGL operation so that we can use it when GIMP does its processing in linear light 32-bit RGBA.

Regards, Martin

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

On Thu, Jan 27, 2011 at 3: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 ...
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 ...
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.

I find myself in the same situation. I popped up in late December with an interest in getting GEGL more fully integrated into GIMP (I'd like to see 8+ bpc support), and Øyvind gave me some pointers and partial code for what he wants to happen next (so I'm one of the time sinks he referred to a couple of days ago). I'm still working to figure out the seemingly recursive concepts.

Thanks, Pete

Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On 01/27/2011 04: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

I think there are some good points in Eric's comments.

I don't know quite how to describe it, but if the "boot camp" were virtual in some manner that others coming along in the future could learn from, but not be buried and obsolete issues a few years from now, that would seem to be the best of all worlds.

Perhaps something along the line of a highly structured web-based (not particularly email) "discussion forum" approach (using out-of-the box forum software) wherein each issue/subject/lesson was a tightly managed thread that allowed on-subject question/answer, but then the net of each answer gets integrated back into the initial lesson, making the lessons stronger over time.

And if a thread becomes obsolete due to advances in Gimp, etc., the thread can be archived.

Unlike a "normal" discussion forum, the managers would edit, amplify, rearrange or remove both questions and answers as appropriate to strengthen the lesson. After all, the intent is not a real discussion with expression of opinion, etc., the intent is a directed learning experience in which the teachers and students interact to hone the usability of the lesson.

Anything that will help to capture the knowledge and experience of the core developers can only help to keep Gimp vital in the coming years. We never know when any individual will no longer be available in Gimp's future, thus capturing that knowledge is really important.

Jay

On Thu, Jan 27, 2011 at 10:02 PM, Pete Bergstrom wrote:

On Thu, Jan 27, 2011 at 3: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 ...
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 ...
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.

I find myself in the same situation. I popped up in late December with an interest in getting GEGL more fully integrated into GIMP (I'd like to see 8+ bpc support), and Øyvind gave me some pointers and partial code for what he wants to happen next (so I'm one of the time sinks he referred to a couple of days ago). I'm still working to figure out the seemingly recursive concepts.

Feel free to drop by the #gimp and #gegl IRC channels to ask directed smart questions for understanding the code. Also be aware that some of the existing core contributors both dislike email in the first place, and are "cursed by knowledge" thus not the best people to write introductions to how things work; new-comers are in a better situation to do this. For the last few years GIMP (and GEGL) have been involved in Google Summer of Code which can be considered some form of such a boot camp - some of the students have also stuck around after their last money from google arrived, the common practice in the last years has also been that the domain experts have not neccesarily been direct mentors for students but "meta-mentors", giving guidance on irc in the public channels for any problems that might crop up.

/Øyvind Kolås

«The future is already here. It's just not very evenly distributed»
                                                 -- William Gibson
http://pippin.gimp.org/                            http://ffii.org/
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Maybe just a good documentation for GIMP source is needed? Once I tried to patch TinyScheme interpreter to make it work faster. In files I was working on was almost no comments.

Łukasz Czerwiński

On 01/27/2011 05:29 PM, Øyvind Kolås wrote:

Feel free to drop by the #gimp and #gegl IRC channels to ask directed smart questions for understanding the code. Also be aware that some of the existing core contributors both dislike email in the first place, and are "cursed by knowledge" thus not the best people to write introductions to how things work; new-comers are in a better situation to do this. For the last few years GIMP (and GEGL) have been involved in Google Summer of Code which can be considered some form of such a boot camp - some of the students have also stuck around after their last money from google arrived, the common practice in the last years has also been that the domain experts have not neccesarily been direct mentors for students but "meta-mentors", giving guidance on irc in the public channels for any problems that might crop up.

I've tried asking questions in the #gimp channel, but rarely get an answer. I guess the right people would have to be on-line for that to work. I'm thinking that maybe most contributors are in Europe or on the US West Coast. By the time I get off work (US East Coast), it's past midnight in Europe...

I'm not saying that the "boot camp" idea is the best solution. But I do have the impression there is a bit of a problem. I've noticed a lot of complaining about there not being enough people to contribute, and about it taking too much effort to bring new contributors up to speed...

Another thought: I do have some technical writing skills (although it is not my profession). If there are areas where I could write documentation, having support from the experts on my many questions, and have it end up on the developer.gimp.org, maybe that would help.

Eric

Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Eric Grivel wrote:

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.

The new people getting an education on GIMP from some sort of "boot camp" or Q&A with the developers should write down the information they learn in a public document. It will help others that are starting out. The information will be spotty at first but will gradually be filled in to cover most (all?) areas of GIMP over time as more questions are asked and answered.

On Thu, 2011-01-27 at 16:56 -0700, Stephen Greenwalt wrote:

* The project ought to be able to exist in a "bubble" . . . so as to avoid confusion . . . regarding copies of dependencies that might exist in the OS.

Automated builds are typically used to verify dependency issues on multiple platforms and I believe there is work being done on automated builds.

However, building from GIT does require building within a sandbox (a local directory tree) where you can build all the required pieces you don't already have or for which you need more recent versions. I talk a little about this on my book's blog: http://www.graphics-muse.org/artistsguide/?p=247

I added some scripts I use to keep my GIT tree build up to date on Fedora to the end of that entry today.

* Multiple different project versions ought to be able to exist on the same machine without stepping over each other.

There is little to prevent this now. When you build with autoconf you pass --prefix to the configure script for all the prerequisites up to and including GIMP. That gives you the sort of "bubble" you were talking about, to the extent it covers direct prerequisites for GIMP.

If you do this, then running GIMP is just a matter of setting the LD_LIBRARY_PATH and PATH to point to the installation directory (re: what you passed with --prefix). In this way, you can run many different versions of GIMP though not at the same time. The only place they overlap is the .gimp-x.y user directories. This can also be handled with a shell script that points .gimp-x.y to another directory with a symlink before it starts a particular installed development version.

* Shouldn't we standardize on a common development IDE (like Eclipse)? If I am missing something in that area . . . let me know.

IDE's are crutches. Based on the source tree I don't think the developers use them but I could be wrong. I don't even use IDEs for Java programming. Unless you include cscope as an IDE.

Don't bog down in the tools. Open the file and read it. That's how you learn code.

On 01/27/2011 10: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.

To be honest, I don't recall a single instance of when a question about the code has not been answered (when developers have been around). If you are unable to get in touch with core developers on IRC, feel free to use our mailing list instead.

It's just that it has to be new contributors driving the core developers, not the other way around.

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.

This is exactly why I have been setting up a nightly builder and trying to get everyone to write more regression tests: to make GIMP a less scary project to work on. If people can be confident that if they break something, our nightly builder will discover that, then people wouldn't be so afraid.

I believe our biggest development-technical mistake right now is that people don't write regression tests for new functionality they add. It is kind of boring and sometimes hard, but the long term effects of consistently doing this is priceless.

Our nightly builder is found at http://gimptest.flamingtext.com:8012/waterfall which curiously enough failed this night to my changes yesterday, but I fixed that already...

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.

Please please please don't hesitate asking for help, the worst thing that can happen is that you are ignored ;)

But don't underestimate the value of being able to understand code all by yourself. It takes some practice, but that skill is generic and will make you a better programmer in general.

Regards, Martin

On 01/28/2011 12:56 AM, Stephen Greenwalt wrote:

It is huge. Incredible, actually. Who wrote all of this? Wow.

To see who wrote all this, visit https://www.ohloh.net/p/gimp/contributors

A few comments:

* It seems to work best to put the entire project (all source, and all build product) under a project folder in the Home directory. * If possible, that should include a /copy /of any external dependencies . . . with environment variables (etc) adjusted accordingly * The project ought to be able to exist in a "*bubble*" . . . so as to avoid confusion . . . regarding copies of dependencies that might exist in the OS.

I've tried quite a few different setups, and I find this to be the best: http://www.chromecode.com/2009/12/best-way-to-keep-up-with-gimp-from-git_26.html

* Multiple different project versions ought to be able to exist on the same machine without stepping over each other.

As have already been pointed out, you can already do that, just use different --prefix:es

* If we do it right, compiling for Linux vs. Windows vs. OSx ought require no more than the flip of a switch. The Blender folks, and others, are moving in that direction.

I agree, we should make nightly .rpm, .deb, .exe and .dmg builds. Quite a bit of work left to get there though.

* Shouldn't we standardize on a common development IDE (like Eclipse)? If I am missing something in that area . . . let me know.

If you want a good IDE I recommend Qt Creator. If I were to start fresh today, I would probably use Qt Creator instead of Emacs.

Regards, Martin

On 01/28/2011 05:22 PM, Martin Nordholts wrote:

Our nightly builder is found at
http://gimptest.flamingtext.com:8012/waterfall which curiously enough failed this night to my changes yesterday, but I fixed that already...

It's not curious, it's the beauty of the nightly build. It breaks while it's fresh in your mind, and so more easily fixed.

Cameron

On 01/28/2011 05:01 AM, Michael J. Hammel wrote:

* Shouldn't we standardize on a common development IDE (like Eclipse)? If I am missing something in that area . . . let me know.

IDE's are crutches. Based on the source tree I don't think the developers use them but I could be wrong. I don't even use IDEs for Java programming. Unless you include cscope as an IDE.

Don't bog down in the tools. Open the file and read it. That's how you learn code.

Hi

Hmm I don't understand your reasoning. So you rather waste time manually refactoring Java code than using Eclipse' excellent integrated reafactoring features?

Regards, Martin

Von: Stephen Greenwalt

* It seems to work best to put the entire project (all source, and all build product) under a project folder in the Home directory. * If possible, that should include a *copy *of any external dependencies with environment variables (etc) adjusted accordingly * The project ought to be able to exist in a "*bubble*" . . . so as to avoid confusion . . . regarding copies of dependencies that might exist in the OS.
* Multiple different project versions ought to be able to exist on the same machine without stepping over each other.

Martin has covered that in http://www.chromecode.com/2009/12/best-way-to-keep-up-with-gimp-from-git_26.html

That's rather easy to follow, shouldn't take more take more than an hour*, even when running into each problem that's commonly encountered on a default Ubuntu install (i.e. no compilers, no developer files, ...) deliberately.

*assuming a broadband connection and something around a 2GHz system, otherwise add some buffer for download and compile times

* If we do it right, compiling for Linux vs. Windows vs. OSx ought require no more than the flip of a switch.

If you've got a build environment set up, it builds with the exact same commands.

* Shouldn't we standardize on a common development IDE (like Eclipse)?

Shouldn't be necessary - if you make sure that the IDE doesn't interfere with the autotools build setup and/or introduces its own project files, then you may choose any IDE you like.

Regards, Michael

On 1/28/11, Kevin Cozens wrote:

Eric Grivel wrote:

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.

The new people getting an education on GIMP from some sort of "boot camp" or Q&A with the developers should write down the information they learn in a public document.

Exactly. Write down the question, write down the answers. When the mass of 'write-downs" reaches a particular point, all the notes can be transformed into docs for beginners.

Alexandre Prokoudine http://libregraphicsworld.org

On Fri, 2011-01-28 at 08:39 +0100, Martin Nordholts wrote:

Hmm I don't understand your reasoning. So you rather waste time manually refactoring Java code than using Eclipse' excellent integrated reafactoring features?

Yes, though your evaluation of "excellent" could be argued as subjective. From my perspective, it's a better waste of time than wondering though the plethora of useless features of most IDEs. The best Unix developer I ever met (Ken Witte, Dell Computer) bounced around code 10 times faster than I've ever seen anyone with an IDE.

Any tool will do if you know how to use it. It's what you do with it that's important. That's what I mean by "don't get bogged down by the tools".

On 28 January 2011 17:58, Michael J. Hammel wrote:

On Fri, 2011-01-28 at 08:39 +0100, Martin Nordholts wrote:

Hmm I don't understand your reasoning. So you rather waste time manually refactoring Java code than using Eclipse' excellent integrated reafactoring features?

Yes, though your evaluation of "excellent" could be argued as subjective. From my perspective, it's a better waste of time than wondering though the plethora of useless features of most IDEs. The best Unix developer I ever met (Ken Witte, Dell Computer) bounced around code 10 times faster than I've ever seen anyone with an IDE.

Any tool will do if you know how to use it. It's what you do with it that's important. That's what I mean by "don't get bogged down by the tools".

You mean he could compile and edit different with the press of a single button instead of going to console typing make, shifting editors around etc? I use IDE's too and I find them extremely helpful. Using an IDE where everything is accesible from a single program does not seem counterproductive to me. Now if people like to do it the hard way, it's up to them, but trying to force your way to others, because you think it makes you...I don't know, a better programmer(which obviously isn't the case, this guy you mention would FLY if he used an IDE)?It makes me think of an elitist attitude that frankly, is not compatible with me. 'If you can't do it the hard way you're not good enough to be bothered with'. Don't forget that most people do development in their free time and having to learn all these tools just to do something they are already good at(coding) is very annoying. That -is- getting bogged down by the tools. Having people telling them that they are not good enough if they can't do it, is even more annoying.
Personally I'm still struggling with git right now and it would be great if I didn't have to surf around for information/tutorials. I have spent a couple of hours trying out things that could have been spent coding. Not everyone has this kind of patience I'm afraid..Take Blender for example. In their development pages they have extremely clear, newbie-oriented instructions on how to download the repository, compile on a platform-by-platform basis etc. Noone there said to people that the best programmers around know how to use svn and and we are not going to bother with you.
It's marketing I'm afraid(because I don't like marketing): make it easy for people to come and they'll come.

Lucasz, +1 for everything you've written!

I'd just settle for good step by step instruction on getting a windows cross compile working.

I've had no problem getting from git and compiling for Ububtu in a Ubuntu VM, but whenever I ask how to set up the tools for windows cross-compile I get hand-waving and "oh just redefine your compiler environment variables" but have never had luck.

A few people have posted that they'll put up steps, but Ive not seen anything, yet :(

(Still hoping though)

-Rob A>

2011/1/28 Łukasz Czerwiński :

I'd like to write a little bit on some of the topics. Q&A
I think that for a start a Wiki with Q&A edited by everyone could be a good solution. If it gets too complicated, it can be split in sections, pages, categories and so on.

Such a wiki has been started. Its hosted by me at http://gimp-wiki.who.ee and has been devised as unformal developer space. What it lacks is contributors. Joining easy. A request to me with desired wiki name and email and that's it. If you want to maintain the developer FAQ, please step up.

IDE

The wiki pointed out above already contains a howto for netbeans. Netbeans is the only ide Ive gotten to actually code-complete for me and allows me to navigate project in the manner I like. And before netbeans Ive used pretty much anything:P

Tutor / supervisor (an experienced developer) It's a good idea to choose one or two developers responsible for the whole "Newbie Developers Boot Camp".

We currently have exactly 2 active developers, me and mitch. And we do try to help out noobs as much as we can at #gimp. This is where the "noob bootcamp" happened at least for me. And when I joined #gimp for the first time with a bug on my mind my experience with C was very much limited. It has taken over 4 years to get into the codebase and develop a clue and I still have a long way to go.

From time to time I can see emails "Hey, I'd like to help you, but don't know where to start". Some people will get this knowledge on their own (or will try to get it from IRC channels), but some won't and aren't brave enough to spam all developers on a Gimp list with his/her newbie questions.

People who do this "Hi, im bored, give me something to hack" usually lack the commitment it takes to get into a large code base like GIMP. People who stick around and evolve into developers come to us with an issue or a plan. something they want to fix. And then they read the code and slowly get good enough. Thats the only way I know, that works. Have an idea what you want to change and then do it by asking questions. We like sensible questions. In fact, not asking questions is IMHO a good reason to flunk a student at GSoC mid-term :P If you want answers, join IRC. And stay connected long enough to answer. the last guy who did that(IRC name Acumen) had so bad connection that in the 10 minutes it took for me to see the question his link had already dropped and I had nobody to answer.

-- --Alexia

PS. Sorry for spam Łukasz, to was meant for the list.

On Friday, January 28, 2011, 19:08:43, Rob Antonishen wrote:

I'd just settle for good step by step instruction on getting a windows cross compile working.

I posted the instructions to the list some time ago:

Hi,

why don't put those instractions on the site? Can be a good start point.

Massimo

Il 28/01/2011 19.20, Jernej Simončič ha scritto:

On Friday, January 28, 2011, 19:08:43, Rob Antonishen wrote:

I'd just settle for good step by step instruction on getting a windows cross compile working.

I posted the instructions to the list some time ago:

?ukasz Czerwin'ski wrote:

Maybe just a good documentation for GIMP source is needed? Once I tried to patch TinyScheme interpreter to make it work faster. In files I was working on was almost no comments.

TinyScheme is another project with little to no documentation. I would be interested to hear about your work on TinyScheme and what documentation would have helped you. Feel free to e-mail me privately or send a message to the tinyscheme-issues mailing list (on SourceForge). Just remove [Gimp-developer] from the subject line.

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