On 2013-01-17, Keshav Kini <keshav.k...@gmail.com> wrote: > Dima Pasechnik <dimp...@gmail.com> writes: > >> 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. > > `git clone --depth 1` is pretty useless, because your new clone can now > not interact sensibly with the upstream repo at all. You might just as > well copy the files into your repository and `git add` them...
but a new clone only needs to interact with the upstream if you want to change it. No interaction is needed if you just build vanilla (or patched) upstream. > >>> 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). > > Because we'd need to make the patches solely for the purpose of > submitting them upstream. Patches? Sometimes we would only need to submit pull requestes... Well, even if these must be patches, "git format patch" is not something that really can dis-incentivize one from submitting a patch... > Right now we need to make the patch files in > order to get the program to run in Sage in the first place; submitting > them upstream involves just writing a short email and attaching the > already-existing patch. > > -Keshav > -- 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.
