From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10012 invoked by alias); 27 Apr 2010 12:27:53 -0000 Received: (qmail 9987 invoked by uid 22791); 27 Apr 2010 12:27:49 -0000 X-SWARE-Spam-Status: No, hits=0.7 required=5.0 tests=BAYES_50,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM X-Spam-Check-By: sourceware.org Received: from mail-wy0-f175.google.com (HELO mail-wy0-f175.google.com) (74.125.82.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Apr 2010 12:27:36 +0000 Received: by wyb33 with SMTP id 33so886838wyb.20 for ; Tue, 27 Apr 2010 05:27:34 -0700 (PDT) Received: by 10.216.161.14 with SMTP id v14mr7169296wek.179.1272371252175; Tue, 27 Apr 2010 05:27:32 -0700 (PDT) Received: from fgglaptop5 (cyclades.prism.uvsq.fr [193.51.25.227]) by mx.google.com with ESMTPS id g66sm794085wej.1.2010.04.27.05.27.29 (version=SSLv3 cipher=RC4-MD5); Tue, 27 Apr 2010 05:27:30 -0700 (PDT) From: "Grigori Fursin" To: =?iso-8859-1?Q?'Manuel_L=F3pez-Ib=E1=F1ez'?= Cc: "'Dorit Nuzman'" , , , "'David Edelsohn'" References: <003b01cadbde$21913eb0$64b3bc10$@com> <007401cadd57$04023ff0$0c06bfd0$@com> In-Reply-To: Subject: RE: Notes from the GROW'10 workshop panel (GCC research opportunities workshop) Date: Tue, 27 Apr 2010 12:40:00 -0000 Message-ID: <01ee01cae604$ff356ef0$fda04cd0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2010-04/txt/msg00877.txt.bz2 Hi all, I created the page on GCC Wiki with this info: http://gcc.gnu.org/wiki/GCC_Research Please, feel free to update or rewrite completely=20 (if you feel that something is wrong, etc)... Hope it will be of any use ;) ... Cheers, Grigori -----Original Message----- From: Manuel L=F3pez-Ib=E1=F1ez [mailto:lopezibanez@gmail.com]=20 Sent: Friday, April 16, 2010 6:51 PM To: Grigori Fursin Cc: Dorit Nuzman; gcc@gcc.gnu.org; erven.rohou@inria.fr; David Edelsohn Subject: Re: Notes from the GROW'10 workshop panel (GCC research opportunit= ies workshop) On 16 April 2010 13:21, Grigori Fursin 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 i= mmediately > drive away young and motivated students who can otherwise become really a= ctive > 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 l= ists: * 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/dis= cuss 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.