This is the mail archive of the
mailing list for the GCC project.
Re: Why not contribute? (to GCC)
Thank You, Manual and Joel
I'll try to choose smth appropriate to start.
I am a little confused by the term:
"3. AND at least one free software project you are a contributor of. "
I have accepted patches (well, very small and very obvious) into
llvm/clang, pcsclite. And how this may be applied to gcc-devel? I.e.,
how i may answer to Q.3? I have no patches to gcc yet.
Looks as "egg -- chicken" problem?
Sorry for waste Your time with trivial questions.
2010/4/23 Joel Sherrill <email@example.com>:
> On 04/23/2010 02:39 PM, Manuel LÃpez-IbÃÃez wrote:
>> On 23 April 2010 21:24, ÐÐÐÑÑÐÐ ÐÑÑÑÐÐÐÐ<firstname.lastname@example.org> Âwrote:
>>> I have no hardware to test patches, small free time to work and my
>>> english is bad.
>> I always test patches in the
>> In fact, I only do development in the CompileFarm. I have a not very
>> powerful laptop that is already overworked.
>> I only use linux x86 machines but they have plenty of esoteric
>> hardware and setups for testers.
> I am the maintainer of RTEMS (http://www.rtems.org). ÂWe
> do all development cross and run all automated tests on
> simulators. ÂThere is a wide variety of free simulators for
> the esoteric hardware and all can run on Linux x86. ÂWe
> have scripts to help run a lot of the simulators.
> I think we have scripts to drive about 20 different simulator
>> I don't have a good answer to the lack of time. I also have very
>> little free time and the most interesting work is time-consuming.
>> However, just checking whether an unconfirmed PR is still valid takes
>> 5 minutes. When you get proficient writing patches, the most consuming
>> task of fixing a bug may be writing the Changelog. (ok ok, for some
>> very very simple bugs, but they exist!).
> This is a very important task.
> Also helping ensure the PR is decent to start with is important.
> Reminding people to submit preprocessed source that
> can be used to reproduce the problem. ÂGetting them to try
> different optimization flags and CPU model settings. ÂSometimes
> a maintainer will hone right in on the problem if you just give them
> enough details up front.
> Checking if it worked on a previous major branch. ÂSay broken
> in 4.4.2 but worked in 4.3.3. ÂThen a binary search can find it.
> Personally I don't fix any code generation problems. ÂBut I
> try to narrow things down so that someone else can use their
> time effectively fixing it, not narrowing the problem space.
>> If you read up to here your English is good enough. We do not need
>> Shakespeare writing code. We need good programmers. Good patches talk
>> by themselves.
> And don't be afraid when someone finds a simple mistake
> in your patch. ÂI get caught on this all the time. ÂForgetting
> to update the copyright year, etc.
>>> But sometimes i submit bug reports :)
>> Good! Thanks! Maybe the next step could be checking whether bug
>> reports are valid or not. ;-)
> Indeed. :)
> Joel Sherrill, Ph.D. Â Â Â Â Â Â Director of Research& ÂDevelopment
> joel.sherrill@OARcorp.com Â Â Â ÂOn-Line Applications Research
> Ask me about RTEMS: a free RTOS ÂHuntsville AL 35805
> Â Support Available Â Â Â Â Â Â (256) 722-9985