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: 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:
http://gcc.gnu.org/wiki/CompileFarm#How_to_Get_Involved.3F
"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.

Thank You.
Dmitry

2010/4/23 Joel Sherrill <joel.sherrill@oarcorp.com>:
> On 04/23/2010 02:39 PM, Manuel LÃpez-IbÃÃez wrote:
>>
>> On 23 April 2010 21:24, ÐÐÐÑÑÐÐ ÐÑÑÑÐÐÐÐ<dimhen@gmail.com> Âwrote:
>>
>>>
>>> I have no hardware to test patches, small free time to work and my
>>> english is bad.
>>>
>>
>> I always test patches in the
>> CompileFarm.http://gcc.gnu.org/wiki/CompileFarm
>> 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
> configurations.
>
>> 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. :)
>>
>> Manuel.
>>
>
>
> --
> 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
>
>
>


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