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)


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]