This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


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: ct-ng -> git repos instead of single patches


Arnaud, All,

On Tuesday 03 August 2010 19:41:58 Arnaud Lacombe wrote:
> On Tue, Aug 3, 2010 at 12:59 PM, Yann E. MORIN
> <yann.morin.1998@anciens.enib.fr> wrote:
> > I do not have my copyright assigned to the FSF, so I can not contribute
> > to the FSF-managed projects, such as:
> you don't need copyright assignment for trivial patch.

Granted, but some of those patches are not what I'd call trivial. :-)

> >> As a quick example of my point, most of the patch of uClibc 0.9.30.2
> >> have been copied in a single shot from buildroot. Buildroot commit log
> >> is "Everything on the 0_9_30 branch since the release (0.9.30.3 to
> >> be)". So that why currently someone building a toolchain based on
> >> uClibc 0.9.30.2 really has 0.9.30.3. I'd suspect that currently, Yann
> >> does not provide uClibc 0.9.30.3 because "ct-ng" 0.9.30.2 is already
> >> 0.9.30.3.
> > There are known bugs in uClibc-0.9.30.2, let's fix those.
> that's uclibc's people charge, not "ours".

"Our" goal is to build toolchain, yes. But those toolchain should be
functional, to a certain extent. If we know that there are bugs, and
that we can fix them without too much trouble, then I think we should
fix them.

A toolchain that does not build is an issue we have to fix. As well,
if it bad generating code is definitely not something we want.

> > 120: Ah! the rm-whitespace issue! Did you even read what the patch does?
> > The way the macros are used is incorrect. There shall be *no* space
> > between the macros name and the openning parenthesis. The patch fixes
> > that. Reading the patch makes this obvious.
> then why is it not upstream ? btw, I cannot find this requirement in
> the C99 spec...

Yes, indeed. I misread that for the part where it says there shall be no
space after the macro name in the _definition_ of the macro. My bad.

OK, I'm not commenting again on the others. If you do not like the
patchsets that come with crosstool-NG, you're free not to use it, or even
use your own. :-)

> > Oh, by the way, I did all the above analysis in about 1 hour. On my free
> > time, which would have been best spent in my real life.
> What's your point ? You were free to ignore my mail and do something
> better.

No, I can't ignore your mail. After all, there were valid points in there.
Just a more civil way to express your view would have made me do the exact
same digging work, and I would not have complained.

> How many time did I spent yesterday trying to get each patch 
> history ? Do I complain about it ?

If you do that on your paid time, I don't care that it takes you time
to investigate all the issue; after all, it's part of the job. I'd do
the same at work if I had to. And I do.

And if you do that on your free time, then I don't understand why you're
being so aggressive in your comments.

> Let's get my point of view, our job is to provide toolchains, not to
> fix included software because it misbehaves functionally-wise or
> because a patch add a fancy flower. That's the job of the upstream
> project. If there is a fault, it should be reported to upstream and
> fixed there,

Yes, agreed, it should be fixed upstream. I don't have time to properly
submit the patches and follow on them for *all* the components.

In the meantime, we have to build functional toolchains, and all those
package that make up a toolchain have to be fixed _at the time we need
them_, not only in a potentially-distant future.

And some upstreams are not happy with those patches, and will not want
to fix it in their 'better' way, although they did acknowledge the issue.
I say so, as there have been a 'few' cases were it was impossible to fix
gcc because our fix was a hack (yes it was), and they wanted to fix it
better; and there was no follow up to subsequent inquiries about the
'better fix'.

Also, as another example, pushing ARM- or MIPS-related fixes to glibc is
guaranteed to get you burned...

> not in ct-ng only.

Ah! I think we're at last coming to the point, here. :-)
Reading this, I understand that "having a fix in CT-NG is OK, but it should
be pushed upstream". That's a commendable intention, but it requires
dedication, and in some cases a good will to put up with upstream...

Anyway, I like the idea behind all your criticism [*], and I'm happy to
read (and apply) any properly justified cleanup patchset that'd get us
rid of some of the "horrible pile of junk we've been gathering together
as time was passing"... :-]

[*] I always eye criticism with a positive stance, as I know for certain
that I don't know everything, and that there are many a person more
clever than I am that can enlighten my day in a civil way! :-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'



--
For unsubscribe information see http://sourceware.org/lists.html#faq


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