On 2013-01-17, Robert Bradshaw <rober...@math.washington.edu> wrote: > On Wed, Jan 16, 2013 at 11:17 PM, Dima Pasechnik <dimp...@gmail.com> wrote: >> On 2013-01-17, Robert Bradshaw <rober...@gmail.com> wrote: >>> On Wed, Jan 16, 2013 at 6:13 PM, Dima Pasechnik <dimp...@gmail.com> wrote: >>>> On 2013-01-16, Volker Braun <vbraun.n...@gmail.com> wrote: >>>>> ------=_Part_588_6290856.1358340327889 >>>>> Content-Type: text/plain; charset=ISO-8859-1 >>>>> >>>>> I guess there are at least two different meanings of "the Sage tarball" in >>>>> this context. I was talking about the sum of all code checked into the >>>>> Sage >>>>> repositories, which is what one would usually call the release. And the >>>>> third party code is not going to be part of the git repo under the current >>>>> proposal. >>>> >>>> I don't see how this would be an improvement as far as 3rd party code spkgs >>>> maintainance/updating is concerned. Are you saying it stays under the >>>> same ugly patchquilt model? >>>> Or everyone rolls his/her own spkg repos on bitbucket or github or >>>> whatever (as you do for libGAP)? >>>> >>>> Mind you, when I worked on the latest Maxima update (#13364), I had to do >>>> git >>>> bisect on *Maxima* repo to debug *Sage*, and then apply the results of this >>>> investigation to stripped of .git/ Maxima source tree, for which I did not >>>> have an exact mapping back to Maxima repo. >>>> It goes without saying that this is rather ad hoc, error-prone, etc etc. >>>> And then, when Sage patches (which are often experimental upstream's >>>> patches) >>>> for the spkg are merged upstream, a similar >>>> error-prone manual labour toil, sweat, and tears will be needed... >>> >>> Expanding on http://wiki.sagemath.org/WorkflowSEP one would have >>> >>> sage_root/ >>> sage # the binary >>> Makefile # top level Makefile >>> (configure) # perhaps, eventually >>> ... # other standard top level files (README, etc.) >>> build/ >>> core/ # sage's build system/bootstrapping >>> pkgs/ # install, patch, and metadata from spkgs >>> maxima/ >>> pacakge_manager_file # emerge or whatever, would point >>> to some upstream source, patch1.diff, etc. >>> patch1.diff >>> ... >>> ... >>> >>> A single commit would remove create patch1.diff and modify >>> pacakge_manager_file to use it, when patch1.diff is merged upstream, >>> we would do another commit to point pacakge_manager_file to the newer >>> upstream and remove patch1.diff. Here "upstream" is ideally an >>> upstream-provided src tarball (though we might distribute it >>> ourselves) and relating that to whatever revision control system they >>> use is out of scope. >> >> This still looks like an ugly hack. Shouldn't we rather use something like >> [git-subtree] (https://github.com/apenwarr/git-subtree/) >> to deal with upstream source? > > That would only work for upstream projects in git, and it requires > importing the entire upstream into our repository.
No, not really. You can do git clone --depth 1 (well, assuming this works with git-subtree) for spkgs you only build, but not hack on. Perhaps we should rather switch to darcs, with its "lazy checkouts" ;-) > I think it might make more sense for something like sagenb than maxima > too. It does have its advantages, and would be possible in the new > model, but would yield an absolutely enormous repository. as I said, in git you can control how much history you get. > It would also dis-incentivize > us to submit patches upstream. Why? It would make it super-easy, actually (as far as my limited understanding of git-subtree goes). > In any case, the first pass would be getting git to work without > integrating the spkgs. > > - Robert > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
