On Thu, 2012-03-22 at 09:15 +1100, Russell Sim wrote: > Carlos Martín Nieto <car...@cmartin.tk> writes: > > > Thanks for taking the time to do this. One reason I haven't advanced too > > much on this (other than a version I have locally) is the issue of the > > clay script, which I wasn't too sure was DFSG compatible (though > > re-reading the rules, it looks like I was mixing them with the GPL's > > requirement that software be in its preferred editable form), though I > > guess the FTP admin team would have the last say. > Yes I can see how having the generated Clay/Clar executable is less > that desirable if you wanted to extend Clar. But the source is > included, as a compressed string in the clar executable so it's not really > obfuscated, just hidden away.
I guess you could argue that it's not too different from having a tarball in it, just that it takes a bit more work. > > > > Another reason is that I don't know how much sense it makes to package > > the released version, as we've made a lot of bugfixes and added > > features since then, and during the pre-1.0 stage, there won't be any > > bugfix releases, so it might make more sense to create snapshot > > packages. > Yes I think that snapshot releases are probably a better way, since the > symbols are changing anyway it's probably better to imply it's an > unstable API. Since the testing is improving in the library it should > also be easier to determine a working version. I can look at enhancing > my packaging to cover the execution of the clar tests and the write a > script to automate updating from the master? Sounds good. If the tests pass, package it, otherwise wait for the fixes to arrive. No sense in packaging the library if it's broken. > > > > A thing I do take issue with is the short description, which claims > > libgit2 implements the "Git DVCS", but that's not what it does. It's an > > implementation of the core git functions and it doesn't try to replicate > > everything git does, but provide the functionality so you can write your > > own tools on top of it. > How about, "library to access and manipulate Git repositories" or > perhaps back to the origional "Git core methods library"? I don't > really like the "git core methods library" one because it kinda implies > that git is currently using it. Fair point. What "core methods" is trying to say it that its goal is to implement the git plumbing functionality, rather than focus on the porcelain commands. BTW, I noticed that in debian/copyright you missed deps/zlib/* which is under its own license. cmn
signature.asc
Description: This is a digitally signed message part
