Re: Why not contribute? (to GCC)

["Manuel López-Ibáñez" <lopezibanez@gmail.com>]

On 23 April 2010 21:45, Marc Glisse <marc.glisse@inria.fr> wrote:
> On Fri, 23 Apr 2010, Manuel López-Ibáñez wrote:
>
>> This seems to be the question running around the blogosphere for
>> several projects. And I would like to ask all people that read this
>> list but hardly say or do anything.
>>
>> What reasons keep you from contributing to GCC?
>
> Not sure we should spam this list even more with such non-technical
> discussions, but since you are asking:

I think this is an important question for GCC's future, and this is
the main gcc list. If we cannot discuss this here, then where? Please,
keep sending your answers.

> legal reasons. The default disclaimer is nonsense, it is hard to find an
> employer willing to sign a sensible disclaimer, and even when you have a
> nice employer it can still take months (years?) to get things through the
> FSF.

OK. the default disclaimer is totally nonsense. But in my previous
university, I drafted the disclaimer together with the legal
department, and the FSF just accepted it. The FSF took a few months
yes, but I also took me a few months to get to the point of committing
my first patch, so no big deal. Nowadays, there are SVN and GIT where
you can keep your patches until you get the OK. Hey, you can even get
patches approved without the disclaimer yet!  If you are in a hurry,
you can always insist politely. They will either say they are busy but
aware of it or they will say: Oh, I forgot to send it, it is done!

> Note that I am not proposing any change. Assignment to the FSF has
> drawbacks, but it also has some advantages. And if things are slow there, I
> am sure they wouldn't mind extra money to hire more people.

In any case, I think GCC is an important project for the FSF and if it
is hurting our future, we should ask for some improvements on this
area, and perhaps someone would decide to act. Steering committee?

Anyway, you do not need a disclaimer for contributing documentation,
helping with bugs, analysing where and why GCC is slow and even
programming helper tools. You can even suggest changes that someone
else may implement!

Cheers,

Manuel.