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


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]