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] |
All, On Thursday 12 August 2010 23:37:38 Allan Clark wrote: > On Wed, Aug 11, 2010 at 09:22, Enrico Weigelt <weigelt@metux.de> wrote: > > I completely disagree here. These local changes still have to be > > extracted to patches, and these patches have to be put into the > > proper places. If ct-ng would take it's sources from git, all one > > needs to do is to change the ref name. OK, just a quick jump-in, now... When I build a toolchain, what I *do* want is for the toolchain to be based on _upstream_, and know what changes _I_ am doing to these. Usually, upstream make their releases available as tarballs [*]. The only way to know the delta between upstream and what I have to use, is to use patches. Patches are much more manageable than a VCS (whatever be it), because I can very easily list all individual changes, without convoluted command lines, without access to the repos, all on my HDD. And if I am not pleased with the patchset, I can drop it, or even switch to my very own local one. Using a central repository where random people, from random projects, can push random stuff which I may not even be remotely interested in, is simply not an option. Plus, that smells like, hmmm... <whisper>fork</whisper>. You could argue to that that I do not even remotely know even the most important committers of gcc/glibc/whatever. No, I don't. But those projects are doing _releases_. The biggest of those projects (Linux, gcc, glibc, binutils) even have at least a basic Q&A plan before a release is cut. And for the last major project (uClibc), those are people I _trust_. So, basically, we're down to that: _trust_. The only option I would look at to use a VCS is to use the _upstream_ VCS, so I could test my fixes, and push that upstream (if I had time to pursue that goal...). Regards, Yann E. MORIN. [*] glibc is the _one_ exception to the rule, as the only official distribution is via their git tree. Even so, there are non-approved tarballs that smell like official, being served from the historically official ftp. And old versions are available as official tarballs. YEM. -- .-----------------.--------------------.------------------.--------------------. | 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] |