This is the mail archive of the
mailing list for the GCC project.
Re: Creating gcc-newbies mailing list
- From: "Manuel López-Ibáñez" <lopezibanez at gmail dot com>
- To: gcc at gcc dot gnu dot org
- Date: Fri, 27 Jul 2007 11:26:22 +0100
- Subject: Re: Creating gcc-newbies mailing list
- References: <46A90E7A.email@example.com>
Since I have been around no more than one year, perhaps my perspective
could have some interest for the discussion.
I am not sure if a new list will help. Some have argued that long time
developers may be discouraged to participate in such list and that new
developers would be discouraged from participating in the main list. I
think both are pretty good arguments.
Nevertheless, I think the problems mentioned by Diego do exist. When
you are starting most of the questions seem silly. Many of them
actually are. When you gather the courage to send it, sometimes it
gets ignored or worse they point you to an amount of documentation
which is mostly irrelevant for the answer, or worst, it is incomplete
or outdated. Of course, this is not always the case and there are very
good reasons for it: people are busy, the question was
Just an example. There are people that post patches in bugzilla and
they seem interested in getting them integrated but normally they
break coding style or don't have changelog or didn't even run the
testsuite. Of course, the easiest answer is to point to the "how to
contribute" webpage. I have done it too. But I must admit that it is a
poor answer. When I started, I couldn't bring myself to read all that
was required to post a proper patch. Fortunately for me, Ian had a lot
of patience to mentor me and some folks were so kind to teach me how
to submit a proper patch. However, I don't think that is the typical
Another recent example: http://gcc.gnu.org/ml/gcc/2007-07/msg00456.html
(Not a single answer).
Summing up, I am not sure whether a separate list would help but in my
opinion there are a few things that will:
* Mentors: I think it has worked great for the Google Summer of Code.
Why not make it something more common? I will propose that if someone
wants to fix a bug or work on something, the maintainers on this area
should try to find a willing and suitable mentor. However, don't wait
until someone steps up. The maintainer knows who is knowledgeable in
the area, so ask those people until someone agrees. Perhaps what we
need is gcc-mentors@
* Documentation to learn. GCC has a lot of documentation. But it is
mostly for reference, that is, if you forget some detail or it is
under discussion, there is plenty of documentation. However, there is
little aimed to teach (with examples) the steps of how to contribute.
It is like telling people to learn programming by reading the ISO C
standard. The wiki is slowly changing this, but it still needs a lot
of work. Regarding this, there is a curious effect that I experienced
myself. When I started one year ago I noticed the lack of simple
howtos describing the basic things like "how to submit a patch", "how
to prepare a testcase", etc. However, as soon as I learnt how to do
it, the task of describing them for newbies felt extremely tedious.
* Be careful with the answers and be explicit in what the next step
should be. For example, for someone that does not follow gcc-patches
it can be discouraging to get her patch rejected just because it lacks
a changelog or some coding style issues. It is good to convey that
this is not nit-picking, that the patch is welcome and that we want
that person to please send the patch again.
Rober Dewar says that "in my impression beginner *developers*
get good/polite answers and indeed I think people usually go out of
their way to help". I would say that this is true for people that have
been able to commit their first patch. That kind of beginners know
what it takes to submit and commit a patch, understand what a review
is, understand what is worth discussing and how the decision-making
procedure works. However, I don't think the situation is as good for
people that are struggling to figure out how to commit that first
OK, I think this is far enough.