Op dinsdag 15 januari 2013 17:01:09 UTC+1 schreef Burcin Erocal het volgende: > > On Tue, 15 Jan 2013 10:27:38 -0500 > > Keshav, Jordi and many others have pointed these out before, but > our main problem seems to be: > > - we are not really using a DVCS > - the build system is showing its limits due to the rapid growth of > Sage > > > I don't think "switching to GIT" will solve either of these problems > directly.
I agree. > Why don't we discuss the solutions to these problems > separately and put them into action? > > - Development model: > > I like the idea of keeping a branch for each issue on Trac. > > With a student, I even set up a patched roundup install with this > feature. I can enable it on the lmonade issue tracker if anybody is > interested in testing this out. Though I believe using gitlab and > not reinventing the wheel is far better. > You may have seen that I set up a testing server for gitlab with a couple of branches imported into git from trac. (see http://vps805.directvps.nl) Unfortunately, the issue management in Gitlab is rather primitive and they don't really want to make that any better. From my perspective, the most viable option is to keep on using trac, and set up a Gitlab server specifically for managing access to the git repository and for discussing pull requests. I'm not sure what advantages a Gitlab server will have over just using Github in that case, though. > > - Build system > > This actually has two items: > > - integrating the repositories > > Why? > > AFAICT, the only reason is to allow us to specify the dependencies > of the Sage library better. ATM, when a patch goes into Sage, the > corresponding patch to update the spkg is in a separate > repository. Putting these together would help coordinate the two. > > Do we really need to coordinate these? Why is Sage any different > from any other large software package out there? > > The standard solution to this problem is to add a "configure" > script to the library which checks if the dependencies are > satisfied and sets various options for the compilation process > accordingly. > > The initial design of Sage separated the mathematics library from > the distribution system, then further separated the user interface > (notebook) from the mathematics library. Why are we now trying to > reconcile a bunch of shell scripts with a Python/Cython library > for mathematics? > I think the main reason is that Sage currently tries to be both a package manager and a mathematics library. I guess in a way, it would make sense to have 2 repositories: * the sage library * the package manager The 4 that we have now is too much, though. But it is pretty clear that the package manager will depend so much on the sage library, that it would have to have it as a submodule in the source tree at the very least. In that case, since we manage both projects and since submodules are a hassle, it makes sense to confine it all to a single repository. But I think it would be nice for the two parts to be at least separable enough that it is possible to release a tarball for just the sage library. > - rewriting the build system > > I agree that things can be done much better, but I don't > understand why there is talk of rewriting. There are plenty of > excellent package managers around. Why not just use one of > them? > I looked into this, seeing whether we could use portage, pkgsrc, apt or macports for this. Unfortunately, they all either require root privileges and/or a dedicated user added to the system (portage, apt), require you to have the entire dependency tree (pkgsrc), or rely on mac-specific libraries (macports). Technically, the macports system is actually really nice: each 'portfile' contains a list of dependencies, a url for the tarball, and can optionally specify/override configure/make/install steps. It may be possible to isolate the right Tcl scripts from the macports package to turn it into a compatible package manager for us. -- 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.
