Re: crosstool-NG's dependency on version control systems

[Arnaud Lacombe <lacombar at gmail dot com>]

Hi,

On Sun, Dec 19, 2010 at 2:30 PM, Enrico Weigelt <weigelt@metux.de> wrote:
> * Bryan Hundven <bryanhundven@gmail.com> wrote:
>
>> You could, but some people like to work in the official repository if
>> they are going to contribute change back to that software project.
>
> That's not a big deal. Git can export patches or directly push
> into other VCS'es.
>
> For our case here, it wouldn't make much difference at all as patches
> are currently maintained separately. So if somebody wants to contribute
> back, he will have to grab the right patch file and send it to the
> upstream maintainers nevertheless.
>
>> In my honest and personal opinion (as crosstool-ng is not my project,
>> it is Yann's), if you really want to download
>> gcc/binutils/(e)glibc/etc... from a git mirror, why not make it
>> optional. Or write your own wrapper script around crosstool-ng that
>> downloads the source code and touches the .pkg-version.extracted and
>> .pkg-version.patched files before running crosstool-ng.
>
> That would add additional complexity that would have to be maintained
> and doesn't really serve the purpose: my idea is to completely get rid
> of patches and instead directly work within the VCS (and so use it's
> sophisticated operations, eg. rebase, remote synchronization, etc).
> It's a completely different workflow, a different way of thinking.
>
>> At least provide a menu configuration that allows you to choose
>> svn/cvs/bzr/etc... or git to download gcc, etc...
>> But leave the original and official source repository as the default.
>
> What's your goal in conserving the old tarball download or old VCS'es ?
> The git repo will contain exactly the upstream trees, and additionally
> crosstool-ng patched ones
only if the repo come from the upstream project. You cannot trust anything else.

 - Arnaud

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