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.sherr...@oarcorp.com>:
> On 04/23/2010 02:39 PM, Manuel López-Ibáñez wrote:
>>
>> On 23 April 2010 21:24, Дмитрий Дьяченко<dim...@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.sherr...@oarcorp.com        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>   Support Available             (256) 722-9985
>
>
>

Reply via email to