This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)


On 16 April 2010 13:21, Grigori Fursin <gfursin@gmail.com> wrote:
>
> I think, the main problem for students and researchers is that they
> see lots of stuff going on with GCC and on mailing lists but they may
> be shy/scared/not sure where to start if they want to contribute
> or even if they will be welcome to contribute. The reason is that
> some of their ideas/work may not be necessarily immediately useful to the community
> and they may be concerned that they can get lots of aggressive, negative feedback

That is why mentoring could be helpful. Technical discussions by email
sometimes appear harsh and dry to newcomers. Moreover, negative
opinions are more vocal than positive ones. So something that most
people think is a good idea or they are indifferent may only get
negative feedback from a few.

> no matter how useful they are in the future. However, such feedback can immediately
> drive away young and motivated students who can otherwise become really active
> contributors (look at the GRAPHITE and students contributing to GCC now, for example).
>
> So, what I think could be useful, is to try to agree on what can be
> some general common suggestions/recommendations to students/researchers

A short list out of the top of my head for proposing ideas in gcc mailing lists:

* If you do not have the time/resources/people to implement your own
idea, do not expect GCC developers dropping what they are doing to
help you. Volunteers have very very limited time and paid developers
are paid to do something else. In fact, asking GCC developers to do
anything for you, no matter how trivial it seems to you, will likely
result in negative feedback. Probably it is no trivial at all.

* if your idea may potentially slow down the compiler, increase memory
consumption, increase complexity, remove features, or change defaults,
it will receive negative feedback. Guaranteed. If you are sure that
this is not the case or that  the benefits outweigh the drawbacks, but
GCC developers disagree, discussion is not going to solve it. The only
way is to implement your idea (or a working prototype) and give
substantial experimental evidence in many scenarios/targets that you
are right.

* If you have a great idea implemented and provide a substantial
patch, expect negative feedback. There are many ongoing projects in
GCC. A patch that comes out of the blue and breaks those projects will
not be welcome by the people working on those projects.

* Your email/patch may not receive much feedback. This may happen if
you provide your idea in an old thread (people stop reading long
threads after a while), your subject line was not
interesting/descriptive enough (I do not read all emails from the
list), the main audience of your email just missed/overlooked it by
chance (bad luck, busy period, vacations), your email was too long
(people stopped reading before reaching the interesting part), ... The
only feasible choice is to try again sometime later with an improved
message.

* There is also the IRC channels (http://gcc.gnu.org/wiki), which are
more interactive, but the same rules apply to them. Specially being
ignored despite people talking to each other. That is because people
are working, and sometimes they have deadlines, urgent stuff to do,
they want to go home early...

* Read the gcc and the gcc-patches lists for a while to get to know
how things work and who is who.

I am sure there are many more little rules-of-thumb I can come up with.

> who may want to contribute but not sure how to approach GCC community.
> Maybe we can make a page on GCC Wiki with such recommendations or even

Anyone can edit the wiki, so be my guest.

> maybe make a separate pre-processing mailing list for novel/crazy/future/unclassified
> ideas so that only those of you who are interested in that can follow/discuss them
> and from time to time approach this mailing list with already mature ideas
> to avoid bothering others who are distracted by such discussions on this mailing list?

An example of how *not* to get things done is this "maybe we"
attitude. It is likely to get no feedback, negative feedback, or
positive feedback that sounds a bit negative (like my "be my guest"
above for the wiki page):

* It does not specify who is "we". It could be understood as asking
the reader to do something that takes time and effort. Everybody is
busy already, so bad strategy. It can also be understood as only you
or people that you know already that are going to do it. So the reader
understands that he/she does not need to do anything and just wait for
you. Hence, if you were expecting feedback/action, you will be
disappointed.

* "maybe" is vague. Vague ideas are ignored or criticized because
either there are not enough details to have an opinion or it is easy
to misunderstand them.

For example, a better way to move the above idea forward would be:

1) Send a new email with a descriptive subject "A new gcc mailing list
for experimenting with gcc"

2) Say: "I would like to create a new mailing list gcc-experimental
for this and that. I know so many people that are already interested
to join. I would like to create it in the gcc servers. Who is
responsible for creating a new mailing list? (If overwhelming negative
feedback from the responsible then a further email) "OK, no problem. I
created the mailing list in google groups, this is a patch to add a
link to it in the GCC webpages." (let's assume that you still get very
negative feedback from the responsible of the webpages) "Oh, I see. I
understand your concerns, I will add a link to it from the wiki page.
Anyone interested is welcome to join. Thanks! :-D"

3) Expect some negative feedback, some bike-shedding "I prefer the
name gcc-crazy-ideas". And bear in mind that you only need to make the
changes that are asked by the decision makers for your problem, in
this case, the people with the power to create the mailing list,
approve patches to the webpages. If those people are in favour, it
doesn't matter who is against it (Of course, it many people are
against it, then the responsible may change their mind, but it also
work the other way around, so pleasing people may help to change the
opinion of the responsibles.)

> By the way, Manuel, do you mind, if I will forward you email to the HiPEAC
> mailing list?

You may forward it, quote parts or edit it for your purposes, with or
without attribution. I hereby donate it to the public domain ;-)

Cheers,

Manuel.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]