gregor herrmann wrote: > 1) You list tools you don't like and that are required by some teams > and then state: ".. even teams like the perl team are getting sticky to > be on." Could you explain what bothers you in the pkg-perl team, > so that we can maybe "fix it" together? Well, we have 15 packages using dpatch, 50 using cdbs, and 76 using quilt. I didn't check for duplicates, but that's probably close to 141 packages that I prefer not to work on (22%). IIRC there's some pushing for us to move toward using quilt more. If that means less packages using dpatch, that's a small improvement (dpatch sucks more than quilt). If it means more packages that didn't use any of these using quilt, that's even more packages I will prefer not to work on in the future. > 2) You say that you "dislike quilt encrufting Debian source > packages"; may I ask why and what method you prefer to patch > upstream code? Is it the .git.tar.gz concept or something else? I think/hope I explained the why in the blog post. I like to use the awesome power of a modern version control system, be it svn or git, to manage my patches. They're both pretty good, and tools like svn-upgrade make it easy to merge my changes forward to a new upstream release. svn is less good than git at handling things like feature or bugfix branches. If I have a lot of branches, I'm happier working with git these days. I've never found myself in that position with a CPAN package though. CPAN packages tend to need very few modifications. The diff.gz I distribute to debian is a regular diff.gz, with all patches applied. That format is showing its age, and so I like the Vcs- fields that allow other developers to easily check out my package's repository, and access all my branches and history. Support .git.tar.gz is not yet available in dpkg-dev, so it can't be used to distribute patches yet -- if it were available, git feature branches could be shipped in debian source packages. -- see shy jo
Attachment:
signature.asc
Description: Digital signature