Carlos Martín Nieto <car...@cmartin.tk> writes: > On Thu, 2012-03-22 at 09:15 +1100, Russell Sim wrote: >> Carlos Martín Nieto <car...@cmartin.tk> writes: >> > 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.
Ok I have added the clar test to the build and I have also turned on the normal test, even though they are on by default I thought it would be better to have something fail rather than risk packing a broken package. I have also tested inducing an error and to confirm that the build fails. >> > 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 original "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. I have adjusted it to "low-level Git library" to try and reinforce the idea that the library implements the plumbing functionality. > BTW, I noticed that in debian/copyright you missed deps/zlib/* which is > under its own license. Yes I must admit that this was a lack of foresight, I naively removed it when I added zlib to the build-deps. I have added it back now, and I corrected some minor issues with the dep5 compatibility. I have pushed the package to my github account [1] in case need it. 1. https://github.com/russell/libgit2 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/873990byhi....@sparky.home
