On 4 May 2010 09:12, Theodore Papadopoulo <theodore.papadopo...@sophia.inria.fr> wrote: > > - Code complexity: Doing even the simplest stuff in gcc requires quite some > time to a newcomer.
Do you have any suggestion how this could be enhanced? We know that better documentation may help, but at some moment one has to get the hands dirty and dive into the code. I think we are also happy to know if something is not intuitively located/named/documented. This is one part where one could learn *and* help a lot the project. In general, asking here or in the IRC will get you a quick reply, which perhaps is not so good because it doesn't actually fix the original problem. > - Time involvement: I can spend a few days (mostly over the week ends) or > hours after work and can > spend an equivalent amount of time for dealing with consequences of a > patch. I cannot afford to > spend weeks of work (except exceptionnaly if this relates to my work). On The time spent decreases a lot with increasing experience. This is also true for producing good patches, that is, patches that need little or no further modifications. Using the right tools can also save a lot of time (the debug_* functions in gdb, automatic scripts for bootstrapping/regression testing). > one occasion, I submitted > a prototype patch to remove default template parameters with some questions > whether the flag I used > was really available and request for comments.... The only answer I got was This is a problem of communication. Point 5 in http://gcc.gnu.org/wiki/GCC_Research: Your email/patch may not receive much feedback. There are many reasons for it, as listed there. The only solution is to insist. > my questions, I decided that the patch would anyway be never accepted (at > the time INRIA had no > copyright agreement -- and I'm still not sure I'm covered now --), so I > abandonned. Since then But then, why people are going to spend time reviewing a patch that is not going to be accepted? However, I strongly feel that this was not the reason for the lack of feedback. Probably, the fact that you were not using the appropriate functions was already such a show-stopper that reviewers didn't spend more time on the patch. > newcomer, but the effort to get accepted > is/was just too high. The criteria should be the same for everybody, but it is easier to get it right the first time if one has experience. Otherwise, more iterations are needed. Asking for clarifications, and perseverance are the only solutions. > - I'd like to help gcc not to fight/bother gcc people to get some more or > less trivial stuff accepted. Fighting: bad. Arguing politely and with sound arguments: good. Demanding: bad. Asking: good. It just depends on the tone. > I can very well understand that they have more important things to do..... > I must say though that I see some maintainers spending time to answer > beginner questions, and I > appreciate. In fact, sometimes I think maintainers spent too much time answering begginner questions instead of documenting those answers somewhere or fixing the reason for the question. ;-) > - Copyright assignment only comes fourth (and actually may be solved for > me). I believe anyhow that > most newcomers should first start with very small patches first (one > liners, documentation, style, unused > variables....). But those patch are often ignored (again, I can understand > that for a gcc developper that > might not be worth the effort). Really often ignored? I do not see this often, but I can imagine that it happens more to newcomers who do not insist when a patch is not reviewed. Unfortunately, many patches require "pinging", even when they come from experience developers. I added a note to the above page in the wiki. http://gcc.gnu.org/wiki/GCC_Research I don't know how this particular issue could be handled better. > - All in all, I believe that there is gap between skilled developpers and > newcomers. Once one is skilled enough > the list is very helpful. For newcomers, the answers form the list are just > not reliable enough (in terms of useful > answers). Again, I have seen recently some effort by a few developpers to > anser basic questions and that's good. > A slightly better way might be to offer mentorship (eventually pyramidal) > on some small projects in order to help > people jump in the bandwagon.... At least this is true for non-compiler > people as I'm. I think this is a really good suggestion. And I feel that many experienced GCC developers would be up for it if the "student" shows real interest. I am pretty sure potential mentors have many "beginner" projects in mind even simpler than those carried out during the google summer of code. Cheers, Manuel.
