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. 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. It would also dis-incentivize us to submit patches upstream. 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.
