On Thu, 24 Jan 2008 15:15:08 -0500, Joey Hess wrote: Thanks for your quick and detailed reply (and sorry for my late response). > > 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%). Which is a pity IMO, but I have to accpt it of course. > 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). Agreed, and I'm in favour of converting all remaining dpatch-using packages to 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. Hm. I don't share and still can't really understand these aversions against splitting out patches. > > 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. You did but I like to check if I got it right :) > 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. Well, I _tended_ to agree on the powers of svn. But just today I hit 2 packages which left me with conflicts after svn-upgrading, so I had to check the old .diff.gz and the new upstream source and resolve the conflicts manually and everything before I could event commit the new upstream release. Further fun arised from a package using quilt but not for all changes :/ (Yes, I'm a bit grumpy at the moment.) Maybe I'm missing something fundamental but it least for my workflow it's easier if upstream code is plain upstream code and changes to that are kept in e.g. debian/patches. (And I've seen quite some "interesting" changes to upstream code in pkg-perl maintained packages; maybe it's my workflow but I always used to always look at debian/patches and have only later learned to inspect the .diff.gz after having found some "surprises".) > 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. My knowledge about git is not much above zero but if a feature branch is logically roughly equivalent to a diff in debian/patches I think a can grok the concept :) and I'd be fine with changing from svn to git as long as I get some help; but still IMO it's logical to keep patches separated from the pristine upstream code. Cheers, gregor -- .''`. http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4 : :' : debian: the universal operating system - http://www.debian.org/ `. `' member of https://www.vibe.at/ | how to reply: http://got.to/quote/ `- NP: The Doors: Five To One
Attachment:
signature.asc
Description: Digital signature