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