Hi Tony, Thank you for the review.
I used the SVN repository for this package because the other Apache Commons packages are there, that was just a matter of consistency. Likewise I used Git for the tomcat8 package since tomcat7 is already Git based. Regarding the ease of use I'd argue that SVN has one less step, because debcheckout brings the source tarball automatically once the package is in the archive. This doesn't happen with Git based packages, I have to run git-buildpackage first to generate the tarball. I can't run debuild out of the box. The one thing I appreciate with the Git based packages is the ability to clean quickly the working directory when debian/rules clean doesn't work as expected. git stash or git checkout and I'm done. With SVN packages I have to delete everything but the debian directory, extract the upstream tarball and move the files up one directory. For packages that don't clean properly that's really annoying. Emmanuel Bourg Le 17/09/2013 07:12, tony mancill a écrit : > Hi Emmanuel, > > I'll sponsor this package. Everything looks fine. > > However, before I upload, is there any way I could convince you to let > me use the git repo on alioth for packaging? SVN is kind of a pain with > packages that use m-d-h because the upstream source has to be unpacked > (so the pom is accessible) before you can run targets in debian/rules, > so svn-buildpackage doesn't work so well "out-of-the-box." > > If you're okay with that, I'll update the Vcs fields and git-import-dsc > the package I built locally before uploading, and then push that alioth. > If you'd prefer the package remain in SVN, that's fine too. I just > find git a little easier because there's one less manual step. > > Cheers, > tony -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52380f37.6020...@apache.org
