------- Comment #8 from manu at gcc dot gnu dot org 2007-02-13 16:55 ------- I wish to answer this because I am also a newbie and I understand your frustration. On the other hand, I also understand why the current situation is as it is now.
(In reply to comment #2) > It is not practical for gcc outsiders to submit patches, > the requirements are too exacting and complex. E.g. see > http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00072.html > which demands a testcase (something which is IMO unclear > in the "contributing" URL you gave). The requirements are documented. Unfortunately, the documentation is divided among many places and not in the best form. It would be superb and very welcome if someone took the responsibility of summarizing, re-writting and improving the different pieces, so they can be as clear and simple as possible. (Like a step by step guide on how to contribute, maybe especialised for different user-cases). Sadly, experienced people don't have time (and perhaps are not very well suited) for this job. Someone brave needs to step up and take the burden, perhaps seek collaborators among other frustrated newbies. Another problem is that as soon as a newbie becomes experienced with the procedure, then the interest in improving the docs fades away :( > It is unlikely my first (or second) attempt at a testcase > will be flawless. It doesn't matter, reviewers should catch any flaw and patches are regularly submitted many times. It is part of the learning proccess. Flawless patches are accepted earlier, though. ;-) > Similarly, I am asked to document this warning > (which I find odd, since there are lots of undocumented -Wextra warnings). > Do I need to fix the "broken" existing warnings too? The response was > unclear. That is not an excuse. There are things that are historically wrong. New mistakes cannot be justified based on past mistakes. New warnings should be documented. Normally, you don't need to fix anything that is broken already as long as it is not closely related to your patch. If the response was unclear, you have to insist. No all mails are neccessarily read by all people and people are busy busy busy (or on holidays), so sometimes your mail will get lost. Wait one week and insist again. Wait another week and keep insisting. Eventually someone will answer. Short and polite emails get more answers than angry, long rants. This also applies to patches. If you patch is not reviewed: wait one week and insist. Repeat until reviewed. > The only requirement I can confidently handle is fixing the warning strings. > And are these *all* the requirements? I doubt it. It is very likely that if a reviewer finds an obvious mistake in your patch, he/she will not review in deep the rest of it and just move on to the next patch. You will need to send it again and wait for the answer. At first you will make a lot of mistakes but that is normal. My first patch was rejected several times just for the Changelog format. In a few iterations your patches will be almost perfect. > On the other hand, such issues are trivial for veterans such as yourself. > Could you please handle this for me? I would greatly appreciate it. That is a sad misconception. Bootstrapping + testing take time even if there are no failures at all. Adding testcases takes time. Having patches around takes thinking time. Keeping track of submitted patches and pinging reviewers take time. Fixing minor issues in patches takes time. Committing patches takes also a little amount of time. Of course, the total time could be trivial if you had nothing else to do. But if the issue is minor and you are busy (or you are not paid for fixing it and just prefer to invest your time in something else like your family), then it is already too much time. Also there is the issue (I guess) that if sloppy patches are regularly fixed by reviewers, that will advocate more sloppy patches which in turn will make reviewers more unwilling to review patches. So please, reconsiderate your stance, and resubmit your patch. I am sure your contribution will be appreciated. Thanks in advance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16302