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 > > >
