Bootstrapped snapshots

Sun Mar 24 21:46:14 UTC 2013

Hi Dr. Sherrill,

Perhaps two snapshots: yesterday, and the day before, as a user who REALLY wants an old snapshot could probably reconstruct one from an old git commit number? These aren't releases, after all.

Could it just be the core of rtems, like 

git clone git://git.rtems.org/rtems.git
cd rtems
./bootstrap
cd ..
tar -acf tar -acf rtems-snapshot-YYYYMMDD.tar.xz rtems

(lzma might be yield a smaller file, but I don't know how to do that)

Could we not tag the snapshots in git, but rather make sure the git information needed for someone to run git diff from them?

Would it be possible to set it up so someone could get other people's changes from the snapshot, maybe like running git pull? Maybe even having the snapshot check if it's more than a week old, refusing to run git pull and telling the user to get a new snapshot.

Would it be desirable/feasible to throttle how quickly the snapshot gets downloaded?

Could we make it difficult/pointless to run rsync on this file?

Would it help to put them on the http://www.rtems.org/ftp/pub/rtems/SOURCES/4.11/ 

Thanks,
Cynthia Rempel
________________________________________
From: Joel Sherrill [joel.sherrill at oarcorp.com]
Sent: Sunday, March 24, 2013 11:29 AM
To: Rempel, Cynthia
Cc: Ralf Corsepius; rtems-devel at rtems.org
Subject: Re: Building and Testing a Canadian Cross-Compiler

On 3/24/2013 1:06 PM, Rempel, Cynthia wrote:
> Hi Ralf Corsepius,
>
> We could propose a compromise of daily (or weekly) snapshots of the git repository, pre-bootstrapped...
I actually have a script that did this for the CVS tree.

I did it to support Jennifer while was at a customer site
with nothing but http Internet access.
> Could you determine if it's feasible to do a daily (or weekly) snapshot of a pre-bootstrapped git repository, and how to set-up git to ignore the autogenerated files when generating a .diff?
That is easy. It is a .gitignore file. There is one at the top of the
tree that
already does this:

$ cat .gitignore
aclocal.m4
autom4te.cache
configure
config.h.in
Makefile.in

> If the pre-bootstrapped snapshot method is feasible, acceptable, and you wanted to commit from the snapshot, you could then run configure without bootstrap...
 From my perspective, the biggest issue would be policy on cutting and
retention.

How long do we keep them on the disk?
   - The issue is a combination of disk space and and people mirroring
the snapshots.
     This sucks the bandwidth badly. Periodically some *&^R% does an
rsync mirror from
     the top when they really only want a file or two.  This is a
problem as the site grows.
     It is now about 500GB.
Do they get tagged in git when cut?
What are they named?
Is it a full clone? tar cJf results in a 68 MB tar file.

It is trivial technically but I would recommend we only keep a few.
> Thanks,
> Cynthia Rempel
> ________________________________________
> From: rtems-devel-bounces at rtems.org [rtems-devel-bounces at rtems.org] on behalf of Ralf Corsepius [ralf.corsepius at rtems.org]
> Sent: Sunday, March 24, 2013 9:41 AM
> To: rtems-devel at rtems.org
> Subject: Re: Building and Testing a Canadian Cross-Compiler
>
> On 03/23/2013 07:12 PM, Rempel, Cynthia wrote:
>> Thanks Sebastian Huber for finding that tutorial for a building a Canadian cross-compiler.
>> http://sourceforge.net/apps/trac/mingw-w64/wiki/Cross%20Win32%20and%20Win64%20compiler
>>
>> I found a rather out-dated tutorial for testing Canadian cross-compilers
>> http://kegel.com/crosstool/current/doc/crosstest-howto.html
>>
>> It's possible that there might be additional testing resources in
>> http://git.rtems.org/rtems-testing
>>
>> I found gcc/do_one rather interesting...
>>
>> I am curious now, if neither minGW nor Cygwin are needed for RTEMS except for the auto-tools, would it be feasible to automatically generate daily (or weekly) snap-shots that are already boot-strapped?
> Yes, definitely ... The autotool generated sources (e.g. Makefile.in,
> config.h etc.) definitely belong into git.
>
> However, when having done so, the patches were immediately reverted and
> was virtually shot down - These incidents actually are the reason for my
> current deep dissatisfation with certain people around here.
>
>> And if so, what else would be required to get the RTEMS tool-set working for Windows users without Cygwin or minGW?
> This would be very hard if not impossible. You basically need a
> POSIX-shell environment and a POSIX compliant native C-compiler.
>
> Providing these essentially are the core of MingGW and Cygwin.
>
> Ralf
>
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
>
>
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel

--
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985